Skip to content
Lenny's PodcastLenny's Podcast

Farhan Thawar: Why Shopify always picks the harder path

By favoring pair programming, code deletion, and the harder option; Shopify compresses more craft per minute, not more hours from each engineer.

Farhan ThawarguestLenny Rachitskyhost
Dec 19, 20241h 40mWatch on YouTube ↗

EVERY SPOKEN WORD

  1. 0:005:38

    Farhan’s background

    1. FT

      If you do the hard path and it doesn't work, actually you still kind of win because you've now done something hard, you've probably worked with smart people, you've learned something along the way that is like valuable. I meet lots of job seekers. I go, "What are you doing to try to find a job? Are you really learning anything from sending out 10 resumes a day? Why don't you look at the API docs and build something? Even if you don't get a job at Shopify, you've learned something."

    2. LR

      First I want to talk about another theme, creating intensity in your organization.

    3. FT

      Everyone says, "Oh yeah, like work hard and like, do more hours when you're young," whatever. I'm like, "What if you just did more per minute?"

    4. LR

      The more I dig into the Shopify way of working, the more fun stuff I never expected emerges. There's been a drive to delete code and simplify.

    5. FT

      We have a delete code club. We can always almost find a million plus lines of code to delete, which is insane.

    6. LR

      I found this great quote from you. "Not everyone can look stupid in public over and over, but I believe it's my superpower."

    7. FT

      I have been in many situations with many sharp people who have said to me, "That's the stupidest (censored) question I've ever heard." My goal there is not to annoy the person, but it's to understand the content.

    8. LR

      I was looking at your LinkedIn and your career history and I noticed that you worked for a different billionaire every decade of your life.

    9. FT

      They're mostly different people, but they're similar in one thing is that they have an-

    10. LR

      (instrumental music) Today my guest is Farhan Thawer. Farhan is Vice President and Head of Engineering at Shopify. Shopify is an incredibly interesting company because they have over 10,000 employees, are fully remote, and even though they were founded almost 20 years ago, they continue to operate with urgency, velocity, and a very first principles ways of thinking, which translates into them seeing record usage, blowing away their earnings calls just recently, and building a beloved product. A lot of this is thanks to Farhan, who in our conversation shares very specifically what he's done to maintain intensity and urgency within the engineering team, including their meeting cadences, the counterintuitive power of pair programming, how they run meetings, how they cancel meetings constantly, and so much more. He also shares his experience with indexing towards choosing the harder option when you have multiple options to choose from and why that ends up making your life easier. He also shares a bunch of great hiring advice and a bunch of hiring stories which are going to blow your mind. He also talks about their engineering intern program where they're going to hire over 1,000 engineers just for their intern program in 2025. I've had a lot of people on this podcast from Shopify, but that is for a very good reason, because this company and its leaders have a lot to teach us about how to run an incredible business and build an incredible product. If you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube. It's the best way to avoid missing future episodes and it helps the podcast tremendously. With that, I bring you Farhan Thawer. Farhan, thank you so much for being here and welcome to the podcast.

    11. FT

      Thanks for having me.

    12. LR

      As I was preparing for our conversation, I talked to a bunch of people that you've worked with over the years, and there's basically three themes that kept coming up over and over and over. One is hiring, two is creating intensity in your organization, and three is choosing the hard path. First of all, does that resonate? Second of all, does it sound good to talk about these three themes in our time together?

    13. FT

      Yeah. I think, I mean, all, I have ideas on all, like where all three of those things (laughs) came from. Um, and I think that it is, uh, something that if you look back on my career, I've like hit points on each of those things. But I, I don't think at the onset I knew that that's what I was doing, but it turns out in retrospect that's what I ended up doing.

    14. LR

      Perfect. So this is like the Steve Jobs everything looking backwards, it all connects.

    15. FT

      Yes.

    16. LR

      (instrumental music) Today's episode is brought to you by Dx. If you're an engineering leader or on a platform team, at some point your CEO will inevitably ask you for productivity metrics. But measuring engineering organizations is hard, and we can all agree that simple metrics like the number of PRs or commits doesn't tell the full story. That's where Dx comes in. Dx is an engineering intelligence solution designed by leading researchers, including those behind the Dora and SPACE frameworks. It combines quantitative data from developer tools with qualitative feedback from developers to give you a complete view of engineering productivity and the factors affecting it. Learn why some of the world's most iconic companies like Etsy, Dropbox, Twilio, Vercel, and Webflow rely on Dx. Visit Dx's website at getdx.com/lenny. This episode is brought to you by Persona, the adaptable identity platform that helps businesses fight fraud, meet compliance requirements, and build trust. While you're listening to this right now, how do you know that you're really listening to me, Lenny? These days it's easier than ever for fraudsters to steal PII, faces, and identities. That's where Persona comes in. Persona helps leading companies like LinkedIn, Etsy, and Twilio securely verify individuals and businesses across the world. What sets Persona apart is its configurability. Every company has different needs depending on its industry, use cases, risk tolerance, and user demographics. That's why Persona offers flexible building blocks that allow you to build tailored collection and verification flows that maximize conversion while minimizing risk. Plus, Persona's orchestration tools automate your identity process so that you can fight rapidly shifting fraud and meet new waves of regulation. Whether you're a startup or an enterprise business, Persona has a plan for you. Learn more at withpersona.com/lenny. Again, that's withp-e-r-s-o-n-a.com/lenny.

  2. 5:389:37

    Choosing the hard path

    1. LR

      Okay. So let's start by talking about the hard path.

    2. FT

      Okay.

    3. LR

      Advice that I've heard you share with people often is, when they're trying to decide amongst a bunch of options, is to choose the harder path because that makes life easier down the road.Share this advice, why it's so important, where you learned... where you kind of, like, developed that this is the right approach.

    4. FT

      But the short version is that if you have a choice and you choose the easy thing, and it, and it works, great. (laughs) If you choose the hard thing and it works, great, like you kind of did more work. But if it doesn't work and you chose the easy thing, you've actually not learned anything, because you kind of chose the e-... like, you haven't done a lot of work, you haven't probably worked with the smartest people 'cause they don't usually... or they're not usually around in the easy path. And what happens is, you've gone through this exercise and now you're like, "I- I've kind of lost. I lost the choice," and, or, "I- I- I- I was trying to do something I didn't have. It didn't work out for me." But if you do the hard path and it doesn't work, actually you still kind of win, because you've now done something hard, you've probably worked with smart people, you've learned something along the way that is, like, valuable. And I can give you, like, a quick example. So I meet lots of, like, job seekers, and they're like... I go, "What are you doing to try to find a job?" And like, "Uh, um, s- I'm sending out 10 resumes a day." I'm like, "Okay. That sounds like kind of easy, and like, are you really learning anything from sending out 10 resumes a day?" Versus, I would say to them, "Hey, you know all these companies you're interested in? Shopify might be one of them. Why don't you look at the API docs and build something? Build a Shopify app, build an ed- admin extension. Like, build something on top of Shopify." Even if you don't get a job at Shopify, right, which is maybe your goal, you've learned something. You've built something, you have things in your GitHub, uh, repo now and you can show people. You're learning about the product. That might translate to a job you might get somewhere else. But so I think that even though it's harder, right? Of course, you can't every day build an app on a different platform. Maybe you can, once a day. You will learn something in the hard path. And the same thing happened to me in taking hard courses. I would get worse marks, but I ended up meeting smarter people in those courses 'cause they were there for the same reason I was, because the content was hard. So tha- that's something that I've, I've g- I've just realized in my life, that if I do the hard thing... and I- I- I just naturally tend towards doing that. Like I ended up doing... I went to Waterloo and I did a minor in electrical engineering o- on top of computer science, and when I did my MBA I did a minor in financial engineering (laughs) because the smarter people were in that path, and they're still my friends today.

    5. LR

      So on that, building on the last point you just made, people could hear this and think, "Okay, if it's harder, that's gonna be the right path." Sometimes harder is still, like, a bad idea. Like, for example, joining a terrible company that's extremely frustrating to work at, or, uh, building, uh, I don't know, a house in a really dumb way but it's just really hard. What else do you find is important to think about when you're thinking, "It's not just harder, but also X, Y, Z should probably be true?"

    6. FT

      Yeah. One, one real one is, of course, the people, because I find that my path has always focused on trying to pick the best learning journey, like, where can I learn the most? And for me, everyone's different. Like, some people might learn better from, like, books or the domain they're in. But for me, I learn a lot from people, and so I try to put myself in those harder rooms on purpose. There was a time when I was doing my MBA in financial engineering, by the way, and I- I'm in... I was... I'm a tech guy. I'm still a tech guy, and all these people were going into, like, finance jobs. There was a point where somebody said to me, "Why are you in this class?" (laughs) because they knew that I was doing it for fun, right? And so it was because I w- it was the learning journey, and so I would say a big part of it for me is, yes, there is the how do you win even if you lose, because if it goes poorly, you can still c- come out of it with skills, but if you actually take the hard path, you'll have these, like, intense, um, working relationships with smart people that, again, will continue on in your life, and that also just forces you to be in this constant state of uncomfort by going into these rooms and saying, "I don't know anything," and it's harder. And I agree with you, you don't want to do dumb things, like, "Oh, let's just do this thing in a dumb way." That's not what I mean. I mean, let's do the... let's- let's try to do the hard thing that we can learn a- learn from. And by the way, it happens to be on the path, it's just as a, is a... it might take more manual work or it might not be the way most people do it, but we think we can learn more from

  3. 9:3713:20

    Getting comfortable with looking dumb

    1. FT

      that path.

    2. LR

      Speaking of that, uh, I found this great quote from you. "Not everyone can look stupid in public over and over, but I believe it's my superpower and I try to make it my whole team's superpower too."

    3. FT

      Yeah. And I think... I mean, it's... it sounds funny, but again, I'm the one who's always trying, like, super dumb things, and, um, sometimes they work. (laughs) And, uh, you know, like, even, like, my wife hates that I try these things even at home, right? I'll just like, you know, uh... What's an example? Like, you know, maybe, like a ne- a new washing machine, and I might try some weird mode with some clothes and I'm like, "Oh, y- you ruined the clothes." I'm like, "Okay, but now I know that this mode should not be used," but maybe I would have uncovered that there's some super fast quick wash that I can do in 20 minutes that now saves us, you know, 40 minutes of wash time every single time we use the washing machine. So there's things like that, but I will ruin lots of clothes trying to do that. Um, but same at work. We'll try things, and sometimes, um, it can lead to disaster. Hopefully not. But you can imagine thing... people trying to like, "Oh, let me try this new configuration of, uh, GCP and, like, maybe we'll get some, uh, benefit, but maybe we'll take Shopify down." (laughs) Like, we don't, we don't want to do that, so you wanna h- you wanna have some sort of guard rails. But there is something around trying dumb things and saying dumb things, right? Half the time, by the way, when I say something dumb, people will go, "I had the same question." Right? They just were scared to say it.

    4. LR

      So for folks that may wanna... 'cause I feel like this skill is so hard but so important, being okay with failing, being okay with looking dumb. Is there something you help pe- you tell people to help them build this other than just, like, "I'm genetically good at this stuff"? Like, what helped you become comfortable with being wrong and failing before you were, like, a big shot exec where it's like, "Oh, he's fine. He knows what he's doing"?

    5. FT

      I don't know. I- I mean, I kind of grew up, uh, working in retail.

    6. LR

      Mm-hmm.

    7. FT

      And like, people come into the store (laughs) and then they would say, "Hey," and you're like, th- and, and you're on- working on commission, and they're not always buying stuff, and if they don't buy it, you don't make any money. And so maybe just the, the fact of, like, going up and forcing myself to talk to people and then, you know, trying to get them to s- And y- maybe you spend an hour with a client and then they don't buy anything, but you're getting that, like, that reaction of, like, a bunch of negatives, and all you have to do is say, "Okay," and just go to the next customer. Like, you can't really dwell on it and be like, "Oh my God," like, y- um, "This is gonna..." like, "My whole day is ruined," but instead, you have to learn from that and say, "Okay, let me try this, let me try that." And it's not easy, but, uh, it was a way to kind of build up some, some confidence. And people say this, like, telemarketing or, you know, like, there's a bunch of things you can do to get a lot of rejection. (laughs) Um, cold calling is another one, and that's... that can, uh, lead you to actually building up resistance. I don't know if I'm genetically better at it or not, I just think that I literally don't care if I look dumb. Like, I've always said, like, the dumb thing.I'm not doing things on purpose to get nos, which by the way is part of, like, some sales training, which is like, "Go and get 10 nos," and, you know, like, like, that's... But I don't... I haven't done that. But I have been in many situations with many sharp people, businesspeople, successful people, who have said to me, like, turned around and said, "That's the stupidest fucking question I've ever heard." I've definitely had that happen to me, and I'm like, "All right. Let's move on to the next question."

    8. LR

      I love that attitude, and I think that's key to it. It's just, like, bounce off of it and not be crumble. And I think it's empowering for folks to hear from someone like you that has done so well, that people tell you, "That is the dumbest question I've ever heard." Like-

    9. FT

      Oh, yeah. Still.

    10. LR

      Still. (laughs)

    11. FT

      Still. Yeah. That... So how about this? That I heard, uh, "That's the dumbest fucking question," and then recently I heard, "I've already explained this to you three times." Like, because I kept asking, and I didn't, I didn't understand. And literally, I got this message back saying, "I've already explained this to you three times." I'm like, "Okay." Like, "I still don't get it." So like, my goal there is not to annoy the person but is to understand the content, right? And actually, by the way, I sa- these were like messag- I saved them. (laughs) Like, I literally screenshotted because I'm like, "Re- remember this? Like, it doesn't matter. I'm trying to learn."

  4. 13:2019:19

    Lessons from working with visionaries

    1. FT

    2. LR

      One more question along these lines. I was looking at your LinkedIn and your career history, and I noticed that you worked for a different billionaire every decade of your life. So there's a guy named Joe LeMond in your 20s, then Chamath in your 30s, and Toby this decade, maybe yourself next decade if things go well. (laughs) Other than what you've shared, or maybe it is what you've shared, is there a thread across these three folks that have been really successful that you've learned from that maybe is consistent across them all, or even just, like, specific to each one?

    3. FT

      It's interesting because I didn't... Yeah, again, this is like looking back. You're like, "Wait a sec, I didn't plan it this way." Like, there's no way you could plan it, right? "I'm gonna work for a different billionaire every decade." Like, that, that's not how it works. But they're very s- they're similar. They're mostly dif- different people. But they're similar in one thing, is that they have an irrational view of what the world should look like over the next decade or so. They're very long-term thinkers. They're irrational in that they'll look and say, "Hey, 10, 15, 20, 25 years, this is what the world is gonna look like," and I'm not good at seeing that vision, but I'm good at trying to move towards that vision 1% a week. And so the melding of the two... I know where I'm good, and I'm, I'm good at, like, kind of pushing the ball forward. And if they're good at the long-term vision, we can both align to say like, "You're good at this thing. I'm good at this thing. How do we... Why don't we merge forces?" And so that is something that has, uh, resonated with me, is like how do I find these irrational, like, you know, all progress depends on the unreasonable man, right? Like, how do I pair with these people because I'm altogether too reasonable, and there's no way to, for me to become unreasonable? And so I have to kind of merge with these people. And so that is, again, something that I specifically have sought out, and even, um, when I was starting my own company in 2015, I actually sat down and wrote a list of all the unreasonable people that I knew in Toronto. And I went down the list and met every single one of these entrepreneurs to figure out, are we API-compatible (laughs) and could I work with them? And I ended up picking one of them and starting a company.

    4. LR

      That is an amazing story. So first of all, I just love this insight that being aware of I am not... this is not a superpower of mine, and I'm not gonna try to build it. I'm gonna find someone to merge with (laughs) , connect your APIs together, and be the person that builds it, not the person that envisions what to build. I think that's awesome 'cause a lot of people... I'm gonna... I need to get good at all these things. I need to become the best at vision and strategy and execution and collaboration and all these things. And so I think along these lines, an really interesting insight, is just recognize your strengths and weaknesses and double down on your strengths.

    5. FT

      Yeah. It sounds funny, but like, me and you, you, you talked about it, that, that framework I wrote down, which I tweet out, like, me writing that down changed how I p- picked jobs forever, right? Because I kind of had this lull after my first job in between, where I was trying to figure out why nothing felt as exciting as my first job. And it turns out that it took me to sit down and be like, "What do I actually care about?" And you get... Uh, people can get confused. I get confused all the time, by the way, by things that are not on my framework. So for example, a good one, title, company, um, money. All these things can confuse you because you could have somebody, say, a recruiter messages you and says, "Hey, by the way, here's a new job, and here's the compensation." You're like, "Oh my God," like, "this is exciting." And if you don't have an, a written-down framework of the things you actually care about, it's very hard to be distracted, right? So very hard not to be distracted. You get distracted by that. So instead, I look at the framework and go, "Does this, uh, align with my framework?" Right? Actually, to the point of like, I actually sent my framework to a recruiter one time, and I said, "Hey, this thing..." 'Cause they kept going back and forth with me, and I go, "Hey, this doesn't align with my framework." Right? So it really, um, saves me time from not being distracted, but it also forced me to think about kind of every year I can reevaluate what I'm doing and look at the framework and say, "Is this true to my values?" Now, my wife will say this, that I'm like a robot. When I realize that my framework is being violated, I will resign, like instantly. And I'd, and I've done that before. (laughs) So without even having another job or anything, I just go like, "Oh, my framework is being violated," and then resign. So there's this thing where I just... I know what I enjoy working on, and that framework helps me find it. And so I encourage everyone, anybody looking for a job, I always say, "Write down a framework. You can use mine as inspiration, right?" Um, but figure out what you care about and, uh, make sure that what you're working on lines up with that. (laughs)

    6. LR

      And this framework is the questions to ask about where to go work.

    7. FT

      Yes.

    8. LR

      That's your framework. Okay, cool. We'll link to that so folks can check it out.

    9. FT

      Yeah.

    10. LR

      The example of you resigning when it didn't meet your framework, is that a story you're up for sharing? Is there, is there something to learn from that?

    11. FT

      Yeah, sure. So I mean, like... So this happened when I was at, uh, my previous... Uh, a few companies ago, we were running a mobile company called Extreme Labs. That was the one that Chamath was, uh, the major investor in, and so we worked with him directly. And what I realized was... And so we, we got to... The company was amazing. We worked on it for many years. It was a, uh, mobile app development company. We got to work on mobile apps for like the biggest brands in the world, Facebook, Twitter, Instagram, Vine, NFL, NBA, Bloomberg, Slack. Like, you name it, we worked on those mobile apps, and this is right when the iPhone and Android were really gaining steam in like '09 to 2013 era.And then we eventually got acquired by Pivotal. And over time, my role at Pivotal, Pivotal and Pivotal Labs, changed from, hey, I was running the biggest office in the world, I was running the biggest pair programming office, I'm a big fan of pair programming, to one in which we were really trying to attach consulting to, like, the product. And I ended up being, like, a field CTO, um, which really, you know, was... I mean- I mean, it was fun to learn about that world, but it was different than what I was doing. And so if I looked across my framework, it kind of was violating all the things that I was trying to wo- I wasn't working with the smartest people any more, I was in IC, I wasn't learning as much as I could be learning, and I wasn't... So I wasn't on this, and it wasn't having a lot of impact. And I was like, "Oh, wait a sec. This is completely, um, uh, you know, not aligned." And then I just told the team, "Hey, I plan on resigning," and, and, uh, that, by the way, led to great other things, because I'm an in- investor in new companies that have spun off from there, and, like, it was a great experience. I'm just saying, like, it, at the time, lended me to, um, say, "Hey, you're not, you're not actually focused

  5. 19:1922:06

    Creating intensity in organizations

    1. FT

      on the right things."

    2. LR

      I want to come back to Extreme Labs. There are- I know there's other stories there that are interesting. But first, I want to talk about another theme, like, of things that people often con- uh, raised when I asked them about you, and, uh, this one is intensity. And it's specifically creating intensity in your organization, the value of that, the power of that. I've seen that y- the way you describe this and I love is, how do you expend more kilojoules per hour versus spend more hours on work? So talk about just why intensity, first of all, is so important for sure to an organization.

    3. FT

      Yeah. So I think there's a, th- there's a few things. One, I have this fundamental belief that, like, one hour is one hour. Like, it's the same hour, right? If you spend an hour, I spend an hour, it's the same time that goes by. And if I just expend more calories in that hour, right? Like, we both are, you know, let's say we both nu- work nine to five. If I can just get more done in the nine to five, we have both ex- the time has elapsed the same for us, but I just got more done. And that allows me, of course, then to be like, "Hey, I'm going to take my kid to soccer and do other stuff." Like, we can still do the same things out of work, but during work, I just want to try to get as much done as possible during the time, versus expanding the time. And I can give you an example, right? I, I used to work at a company where, you know, it was like, I worked 12 hours a day, but I was playing foosball in the middle of the day, and then we'd go for a coffee break, and, like, you kind of do these things. And of course, the time expanded to 12 hours. Versus, you know, um, trying to compress into that eight-hour day, and pair programming is a great example because, so it's such an intense activity, two people on one machine. You can get so much done when two people are working together, not being distracted by the internet and distractions, and just focus on writing, like, the solution to the problem at hand. And it's so tiring that usually when people switch on to pair programming, um, they sleep like, you know, 10, 12 hours a night the first few nights, because it's so intense, you're working so hard. But for me, that intensity actually leads to, like, extraordinary outcomes, even if you don't have to put in more hours. Like, I think most people, I, you probably hear this all the time, everyone says, "Oh, yeah, like, work hard and, like, do more hours when you're young," whatever. I'm like, what if you just did more per minute, right? Like, quickly get through things. I think there's another unintuitive fact is that people who are really good can actually output high-quality collateral quickly. So, like, take a person who's good and extremely good. The extremely good person can actually get a lot of output in a short amount of time, and the person who's good might take longer. Like, I think there's a, there's a time variance there that people don't think about. So you can kind of, like, not drop the quality too much, but get the time down by, like, 2X, 3X, right? Like Parkinson's Law at scale. Instead of, you know, if I give you an hour to do something, a good per- a really good person can get a high-quality

  6. 22:0629:18

    The power of pair programming

    1. FT

      output in one hour.

    2. LR

      I want to talk about how you create an org that operates this way. But specifically, you just mentioned pair programming, and I know that's one of your favorite, uh, tools. Talk about w- why this is so powerful, when you recommend it. I think as an, like, outside observer, it's, like, two engineers on the same code, why wouldn't, (laughs) why wouldn't we do things half as, half as fast? Talk about just why you're a big fan of pair programming specifically.

    3. FT

      It is the most underutilized management tool in engineering, bar none. Like, it is just not used as much as it could be. So pair programming's, you know, for those who don't know, it's two people on one computer, right? So two keyboards, two mice, two monitors, but one computer. They work together. And if it's remote, they use a- you can use a tool like Tuple, like which we use, and you can just remotely be on one computer. And you're totally right. The, the famous tweet about, uh, pair programming is, "Wait a sec, we have two engineers on one computer. Won't they write half as much code?" And the answer is, oh no, no, they'll write even less than that.

    4. LR

      (laughs)

    5. FT

      (laughs) Because, because it's not about lines of code, right? The throughput limiter is not hands on keyboard. It's not like we're both sitting there and the limiter is, like, us trying to get through the key- like, the keystrokes onto the screen. The limiter is, where is the good, elegant solution? How do we think through the problem and build the right solution for the problem at hand? Um, you know, Tobi famously built a lot of Shopify pair programming. And what he would do is he would actually set a timer, and him and his- the CTO, Cody, would pair program for one hour, and if they did not finish the problem in one hour, they would delete all the code, and they would keep the tests, and they would start over. And then th- what they're thinking was, "If we were not able to articulate and write the code for this feature in one hour, we must be on the wrong design. We must be building the wrong thing." And so they'd delete all the code, kept the tests, and then wrote it again. And sometimes it'd be over by one minute and he would still delete the code and start over. Because his thinking was, "The right, elegant solution should be able to be written in one hour." And so pair programming, I mean, that's an extreme version of it. But even at, like, Pivotal Labs, if your pair was sick that day and you wrote a bunch of code, the strong version is, like, your pair would come in the next day, delete all the code that you wrote, and then you'd write it again the next day. And again, like, what better time to rewrite code than, like, right after you've written it? (laughs) Because you now know the problem domain, and it's... By the way, it sounds like a waste of time, right? Like, it sounds like, "I'm just deleting code." But the reason is, is that code lives a long time, code is a liability, and-... the, like, the right solution, the sh- usually shorter lines, more elegant solution tends to appear after you've done a bunch of pathfinding. And the only way to do that pathfinding is kind of start, and then delete, and then start, and be like, "Oh, no, now I know." Delete. And it's super hard to delete, by the way, because, you know, we're humans, and we have this sunk cost fallacy, so it's hard to delete. But if you can do that, you will actually land upon, like, a much, much better solution. And of course, pair programming has high, high rates of learning, because you're just, like, sitting beside... Like, you're not only, you know, whether it's Tuple or rem- like, or directly, you'll, you'll learn keystrokes, and you learn how somebody thinks about a problem, you go back and forth on the talking. And yes, you will write, like, probably less code, but you will move faster along the path of, like, delivering value for your customers than you would, um, if you did it on your own. And there's all these studies that show happiness is higher, knowledge transfer is higher, less silos, intensity's higher, all the things, and at a price of like, you know, 20% or something of, like, what you would normally do. The analogy I have is, um, the underhanded free throw in basketball, right? Statistically known to sink more baskets, um, but looks dumb and nobody does it. Like, literally, Shaquille O'Neal, I'm not that big a basketball fan, but I read this about Shaquille O'Neal, who was a Hall of Famer, and, uh, they said, "Why don't you throw underhand?" 'Cause, like, he was notoriously bad at free throws. And he goes, "It looks dumb." Even though he's paid millions of dollars a year to do this thing, it looks dumb, doesn't want to do it.

    6. LR

      I remember those Shaquille O'Neal years, (laughs) when he was-

    7. FT

      Yeah.

    8. LR

      ... he had a special free throw coach, and I remember them talking about this, and he's like, "No, I'm n- never again gonna do that." (laughs)

    9. FT

      "I'm never gonna do it 'cause it looks dumb."

    10. LR

      Yeah.

    11. FT

      "And by the way," go back to the beginning of the po- of the interview, "I don't care what looks dumb or looking stupid. We're gonna do this." And so actually, I ran the biggest pair programming shop in the world.

    12. LR

      So on that note, so h- what percentage of shop, like, Shopify do this? Is this how you all operate?

    13. FT

      Yeah, so Shopify, I mentioned, like, Tobi and Cody did this at the beginning of Shopify. And the cool thing about, uh, pair programming is, and in my old world at Extreme Labs, is that we knew exactly what to build, 'cause we were building, like, mobile apps that were almost like contract manufacturing. They're like, "We have an iOS version. Can we build an Android version?" So we kind of quickly were able to say, "Here's the spec. Go quick." Shopify is such a different company, right? We are a pathfinding company. We are trying to find the right thing to build. And so pair programming may or may not make sense all the time. Like, Pivotal and Extreme, we were doing 40 hours a week. Shopify is much more of like a four to eight hour a week pair programming culture, where you're gathering together on a problem and saying, "Hey, let's pair for half a day," or, "Let's pair every Wednesday." And we use that tool in our arsenal to move quickly down a path. But a lot of other time is spent pathfinding and trying to figure out what to build, and trying to convince people, be like, "Hey, we're gonna go down this path." "Oh, now I know exactly..." And sometimes, by the way, 18 months later, we've now figured out all the things, and we should, that's the time we should delete everything and start over. And that's something that we will do at that point. And so you don't want to be pair programming for 18 months. You want to be like way finding and path finding, and then go, "I see the matrix, let me just lead everything and now build it." 'Cause the learning is what you're going for. "We have all the learning, now let's write the code."

    14. LR

      Got it. So it's basically when the code is really, you're pretty sure this is, uh, correct, and it's really important, uh, segments of the code base pair program.

    15. FT

      Yeah, and then also we do a lot of, um, pairing during, like, an incident or a way to, like-

    16. LR

      Mm-hmm.

    17. FT

      ... figure out together, work with somebody and say, "Hey, I'm not really sure. Let's, let's jump on a call together or jump on a Tuple and, like, go down the path and say, 'Let's figure out together what's going on.'"

    18. LR

      I can't help but ask, uh, AI, how does that impact this way of working?

    19. FT

      So, AI is super interesting. What's happening right now with an AI co-pilot, like GitHub Co-Pilot, is it is your pair programmer. So you now can feel like you're pairing actually without another human. You can pair with the AI. And so what's happening too is that you're seeing people use like, like Whisper, like they're talking to Cursor, and they're talking through Whisper to say, "Okay, let's build a new React component that does this," and they're talking, and then it's building, it goes, "Oh no, that's not what I meant. I meant doing this." So you can actually not even have to type, just using voice, go back and forth with your pair programmer. I would say that's amazing. I would still contend take that experience and add two humans together. So you've got like an AI co-pilot and humans, because what's happening is generating code, and the two humans can look and say, "Oh, I know what it's trying to do," and either delete the code, 'cause you have inspiration and write it yourself, or just take the suggestion and move it forward. But I love today's world of AI co-pilots, because you're now... You never have to code alone on your own, right? You never have to code alone. You can try a different language now, because the API and the syntax is much easier to, to pull forward. And so all of those things are, um, are, are like a win for, for engineering and a win for everybody who wants to build any sort of software.

    20. LR

      That makes a lot of sense. Basically everyone's going to be a pair programmer-

    21. FT

      Yes, exactly.

  7. 29:1837:18

    Shopify’s culture of intensity

    1. FT

    2. LR

      ... in the future. Okay, I want to come back to what else you have done at Shopify to create intensity. And I think, again, it's important to highlight the intensity is meant to how do we get more done in the time we have and then go home, not-

    3. FT

      Yeah.

    4. LR

      ... just work all day every day, weekends kind of intensity.

    5. FT

      Yeah. So we have a few things that we have going for us, right? So one, we have this tool called GSD, which stands for Get Shit Done, which you probably heard from maybe talking to other Shopper folk, which is this notion of, like, weekly updates to the whole company on what's happening. Again, Parkinson's law at scale. If you ask people every week, they want to show progress every single week. So that's one way. I talked about pair programming as well. The other thing we do as a company is we used to have like twice a year was our cadence. We'd have like a Black Friday, Cyber Monday, or, like, we had, like, an event in the summer, and now we do six-week reviews. So teams have this notion of, like, every six weeks, actually coming together and walking through the roadmap, the resourcing, and what they're working on with their immediate leadership, but then also with Tobi. And so what's cool about that... And by the way, it's a huge time investment, right? We all get into a room. It's happening tomorrow, so Tuesday, Wednesday, Thursday, we're going, uh, all, you know, a- a bunch of us will be in the office together, and we're gonna go through every project in the company, and we're gonna talk about the project, the resourcing, how it's going, and we're gonna make changes. And again, that creates intensity, because you want to show what has been done, what have you learned since the last six-week review.And we find six weeks is a very good cadence because it's short enough that you can remember the context, and it's long enough... Six weeks is long enough, especially if you have, you know, let's say a team is a dozen engineers, you can do a lot. And not only that, you can do a lot in a day, but this is, like, kind of like a check-in point. And what I've noticed too with intensity is, let's say we get a review and there's some feedback we get in that review, we don't wait till the next six-week review, right? Like, the next day, we are building things, we are iterating, we are tagging people. And then by the next six weeks we're like, "Here's, here's the trajectory." Right? Like, I actually... I want to get that, uh, Elon shirt made, like, "What have you done this week?"

    6. LR

      (laughs)

    7. NA

      (laughs)

    8. FT

      Because Parkinson's law is real. It sounds funny, but like we... Like, you know, I keep bringing this up, but whatever time you allot to something will be the time it takes, right? So if you're doing something monumental, like... I don't know, you're doing, like, a reorg or something, right? You can do it the slow way, "Let's, like, sit down and plan and roll it out," or... And it's probably like six months in most companies. Shopify, this is like a week or two. You sit down and you're like, "Hey, this is kind of the bones of it. Let's bring some more people in the thing." Then you know it's going to start, like, leaking, so we just, like, launch it, right? And we do the same thing with lots of, uh, things at Shopify. We just try to move more quickly and get out of the change... We don't do change management. We kind of just, like, land it and then go, "Hey everyone, it's kind of like a volatile company and this is what's happening, but this is h- how we get things done quickly and then move on with our lives."

    9. LR

      Wow, there's so much there. Uh, I've been through, through those six-month reorgs and, uh, I'm trying to... (laughs) Like, I think that context you just shared of we're at a volatile company, uh, we're changing things, it's not going to be smooth, but here's... We think this is for the best. Uh, it's just the culture of Shopify. It sounds like we want to keep moving fast. We know this isn't going to be the smoothest thing, but we just know this is better to make the change at this point versus wait (inaudible)

    10. FT

      It's how Tobi increased the resiliency in the company.

    11. LR

      Mm-hmm.

    12. FT

      He would walk around in the old days when we had a data center, just unplug machines.

    13. LR

      (laughs)

    14. FT

      Right? Like-

    15. LR

      Or the... Yeah, chaos monkey.

    16. FT

      Yeah, chaos monkey.

    17. LR

      (inaudible) .

    18. FT

      Right. And then... But, but that, but that actually works because it just says, "Hey, by the way, shit's going to break and so let's be resilient to that." And so same thing here, "Hey, by the way, someone's going to move your cheese. It's fine. We are here to create more entrepreneurs in the world. We are not here to have a six-month change management roadmap. And that will just actually hurt the speed at which we can deliver value to merchants."

    19. LR

      So kind of on those, on the... All the things you shared. So there's weekly updates. So the weekly updates are each person shares what they're working on for the week. Is that the idea?

    20. FT

      Each, each project.

    21. LR

      Each project.

    22. FT

      So each project can get... Like, it has an update, it can... It might have a video of a, of here's the experience. It, it'll have a bunch, obviously a bunch of writing on, like, what's changed since last time. We have a process called OK1 and OK2, which is like OK1 is typically at the director level where they're like, "Okay, this is like... I'm aligned with the direction that this is going at," or, "I'm not aligned," and then they can make changes. And then when it goes to OK2, it's typically the VP level of the area who's now looking to say, "Okay, what you're working on actually aligns with the overall architecture. But by the way, have you looked at h- at this context? Maybe you haven't seen this. This is happening more in the industry." And so you're trying to align at that level. And then again, like I mentioned, every six weeks we go through with Tobi and, like, he's an intense guy himself and so a lot of it is like, "Hey, why is this taking so long? Are we th- overthinking it? Are we not trying to move forward, um, on this thing because we're blocked on something? Is there some piece of infra?" Actually, I'll give you a good example. In one of the reviews from last time, there was an interesting AI problem we were trying to solve with LLMs that required us to have a very large output context window. And most of the LLMs today have a very small output context window. But in the review, right, I actually met... We have a shared Slack channel with all the LLM folks, right? I messaged in the OpenAI channel, I messaged in the Gemini channel, whatever. And within an hour I had, I had... We had increased the output context on, like, a mo- a bunch of major models, and we were able to kind of move forward through the thing just because, like, I asked. And so that's an exam-... Like, it didn't, it didn't take another six-week review but it increased the intensity 'cause the team is like, "Oh, we were blocked because we thought we had to now chunk up this data and do this thing because we had m- smaller output context and we thought we could do a big input context but, like, we'd have to do this caching," and it was like this whole thing and I'm like, "Well, did we just ask them if we get bigger..." And then they were like, "Oh, we don't have... This is undocumented but, like, we'll just enable it right now for Shopify." And so that kind of created the intensity with the team to be like, "Oh, we can now quickly get unblocked." So that's a kind of example of just, like, moving quick and trying to, like, just ask a... A- again, ask a dumb question. I'm like, "This is probably not possible, but..."

    23. LR

      (laughs)

    24. FT

      And then they came back and said, "Oh yeah, we can do that."

    25. LR

      That's a great example. And as you're describing the ways that you create intensity and velocity within Shopify, it's interesting that what... Like, what you're listing is a bunch of, like, meetings and check-ins which to most people would feel like, "Why do we need so many... There's all this, like... Less meetings." And I know you guys famously cancel all your meetings and-

    26. FT

      Yes.

    27. LR

      ... uh, that's a whole thing we could talk about.

    28. FT

      Once a year. Yeah.

    29. LR

      (laughs) But it's interesting that more check-ins and regular check-ins allow you to move faster. I imagine it's partly because it just makes you're not working on things that are unnecessary and dumb and not going to be used and it just continues to refine, these are actually the most important.

    30. FT

      I mean, it's a combination of, like, trust but verify, right? Because don't forget, the goal of the check-in is not for you to be like, "Ha ha, I caught you not doing your work." Like that... It's not like the Dilbert boss, like, "Hey, did you do your thing," right? It is... Like, even when I look at the Elon texts which is like, "Hey, what did you get done this week?" It wasn't to try to catch Parag in a, "You didn't do anything or you did a bunch of useless stuff." It was hopefully to pair on the problem, right? Meaning like when I ask somebody, "Hey, like, did you... You know, did we move forward on this LLM project because we now have this larger context window?" And then they came back and said, "Oh, here's what we learned," it... So then I can then look at the answer and say, "Oh. So now are we going to try... Like, have you thought of this? Have you thought..." Like, it's a way to pair on the problem. So it's, it's not like, um... You know, we, we talk... We, we have this word, like, everybody talks about micromanagement as a word and, like, we don't actually think it's a dirty word at Shopify. But the reason we don't think it's a dirty word is because it's not just, again, Dilbert boss saying, "Where did you do the thing?" It's like, "Hey, can I work on this problem with you? And if I work on this problem with you, I kind of got to see where you are pretty often and then give you advice or you're going to share context with me," because I don't... I'm not in the wor- every day, "to then come back and say-"... oh, based on what I know and what you know, can we move this in this direction? Maybe that's better for merchants. It's like, it's really like, I don't want to overuse the pairing paradigm, but it is really much like, can I pair with you? And I learned this actually very early in my Shopify tenure because Toby would have these one-on-ones with me and I'd be like, "Toby, you don't have to waste your time, man, like you hired me, I got this." I'm like, where he goes, "Oh, you misunderstand why you're here. I'm, we are here to work on problems together." And I was like, oh, like I didn't even think, I didn't, I thought he hired me to take problems away.

  8. 37:1839:46

    Meeting Armageddon: revolutionizing company meetings

    1. LR

      I love that. Okay. One thing you mentioned is meeting thing. For pe- people that don't know what y'all did with meetings, I think it might be worth just sharing that b- briefly 'cause it's awesome and something a lot of companies can learn from.

    2. FT

      Yeah, sure. Actually, the funny story about the Meeting Armageddon is that, um, I was messaging Toby prior to me starting at Shopify about Meeting Armageddon. And so I actually think I had a little hand in him, like doing this before I got to Shopify because I was like, "Hey, have you seen..." I think it was Dropbox. "Have you seen what Dropbox is doing and Meetingageddon?" And, uh, and so he was like, "This is super interesting." This is years before I started. So I think it's funny that it ended up being a real thing. But h- here's what we do. Once a year, at a random time, we will delete all recurring meetings that have more than two people, so not one-on-ones, and are internal people only. So not interviews or external partner meetings. And then we have a two-week moratorium where you're not allowed to add a reoccurring meeting. You can add a regular meeting, but not a reoccurring meeting. And the idea is that there's a lot of, um, inertia behind a reoccurring meeting. It just always is there and you know it's coming up and like it's hard to delete 'cause you're like, oh yeah, we talk about this thing every week. And so what we do is we kind of just do a meeting reset and, uh, I, I think, yeah, it's just called Chaos Monkey and some, you know, the admins go in and just delete everything. Now what's cool about it is, it forces you to rethink, do we need a reoccurring meeting or do we just need one meeting or do we need a different cadence? That's one thing.

    3. LR

      Mm-hmm.

    4. FT

      The other thing is it frees up so much crafter time, right? Like one of the stats I track across engineering is how many hours are individual contributors in meetings per week. And we noticed that after we did... We did two things, by the way, and this is, I have a spicy second one for this, but the first one was we deleted meetings and the second thing we did was we moved a lot of our Slack into Workplace, Facebook Workplace, which I'll talk about. Those are the only two things we did. And we saw a huge decrease in the amount of time crafters were in meetings, and then we saw all kinds of other productivity enhancements because they were able to have that flow time and work on things. So we're at something like three hours of meetings per week for an individual contributor at Shopify, which is phenomenal. Three hours a week is amazing. I think managers is not that bad. I think it's, I think I tweeted this, I think it's six or seven hours per week. That's not bad at all in order to get aligned and then all the rest of the time is work time.

    5. LR

      And how much, how many hours was it before, uh, Meetinggeddon and, and Workplace were part of it?

    6. FT

      I have to... Yeah, you're asking me now a good question. I have to go look and see.

    7. LR

      It's all good.

    8. FT

      But it, it, it came down by something like 50 or 60%.

    9. LR

      Wow.

    10. FT

      Like it was like something like five or six hours for individual contributors and came down to three, and<|a|>...

  9. 41:1049:05

    Deleting 1M+ lines of code

    1. FT

      in 2020, 2021, the heyday of, like, pandemic, obviously there was a crypto summer again and crypto was going nuts. And we were sitting back and saying, "Wow, a lot of our merchants are now asking for NFT gating." Remember NFT gating? Which is like, if you have the token, you can now go into the storefront and see my products, you can see my prices, and you can check out, but only if you have the token. And we were getting a lot of demand from merchants to be like, "We want to do this. We want to sell an NFT, and we want our, our buyers to have to have the NFT to have this great experience." And we're like, "We agree. You want to be able to do... We want you to be able to do whatever you want. And, uh, so we want to build this for you too." And sitting with Tobi, he's like, "You guys are thinking about it wrong." 'Cause he goes, "How long would it take to build NFT gating?" I'm like, "I don't know. Two, three weeks?" He goes, "Now how long would it take to build, like, a, a platform layer which exposes APIs so anyone could build NFT gating in one hour?" I'm like, "I don't know. Like two, three months?" He goes, "Do that." He goes, "'Cause you don't know what they are going to build on top of the platform." NFT gating is one thing, one use case. But if you spend the time to build out the infrastructure layer, he calls it putting gas in the tank. If you put the gas in the tank, people could drive on that gas for a long time going forward. And so he goes, "I always want you to think about..." And he had... The key part was, "What can you build so anyone could build this in one hour?" Right? So, like, he does this thing to us all the time where he goes, "Oh, this should only be..." He'll say it and people get the wrong thing. He'll say, "Oh, you could write this in a day." And what he means is, what has to be true so that you could write this in a day? What infrastructure do you need? And he actually develops this way. He will always, like... He will write code against an API that doesn't exist, 'cause he's like, "You know what should exist here? This API." He'll write the code, he'll go back and forth and refine the client and the server, and then he'll go, "This is correct, the correct client code. Now let me go implement the server code." And, like, there's this notion of, like, building things as infrastructure that sounds slower today because it's going to take two, three months instead of two, three weeks. But after that, the things that people built on top, right, were so easy to build. There were so many more scenarios that were emerged. It's just a different way of thinking about software. And, um, it really, again, allows its intensity in a different way, its intensity around building this infrastructure layer, which we want to build quickly but takes two or three months in this case, but then can get everyone building on top of our infra in a much, much quicker way. And of course, you know, who knows what can flourish from there?

    2. LR

      It's interesting and it makes sense that so much of the way you all think is about building the best possible platform, versus the necessarily best possible, like, s- point solution for someone. And it also explains why you spend so much time in crafting really great code and pair programming, because again, it's a platform for other people to build stuff on. So I think it all... A lot of this is very useful, especially for platform businesses.

    3. FT

      No, exactly. And actually, you're making me think of a, of a, of a stat. So, last year I tweeted out, uh, you know, maybe a tangent, but I tweeted out that GitHub Copilot has written over one million lines of code for Shopify. And people were like, "Oh my God." And it got, like, picked up and everyone's talking about it and I go, "I don't know why everybody's getting so crazy," because what I want to see is GitHub Copilot deleting one million lines of code. Like, that's when you know we're actually at this point where this is close to an engineer, right? And so we famously have, um, deleted millions of lines of code this year because we're trying to focus on the, again, the sunk cost and, like, rebuilding things elegantly or you don't need this anymore and rebuilding. And I even tweeted out, I think someone said, "Oh, Shopify, uh, is in the top 10 Ruby code bases in the world." And I said, "I never want to see us on this, on this list again." Like, (laughs) it's not, it's not like... We shouldn't be gunning for number one, we should be gunning for number 100, right? Like, we want to be not on this list, right? Someone else can take the crown.

    4. LR

      This episode is brought to you by Vanta. When it comes to ensuring your company has top-notch security practices, things get complicated fast. Now you can assess risk, secure the trust of your customers, and automate compliance for SOC 2, ISO 27001, HIPAA, and more with a single platform, Vanta. Vanta's market leading trust management platform helps you continuously monitor compliance alongside reporting and tracking risks. Plus, you can save hours by completing security questionnaires with Vanta AI. Join thousands of global companies that use Vanta to automate evidence collection, unify risk management, and streamline security reviews. Get $1,000 off Vanta when you go to vanta.com/lenny. That's V-A-N-T-A .com/lenny. Wait, talk about more about this. So there's been a drive to delete code and simplify. What's kind of that... What's, what's behind that? What's going on there?

    5. FT

      Yeah. So there's a few things, right? One is, the more context you can fit in your head around a code base... And you can never really fit all of Shopify in your head because it's big, complica- complicated set of tools we give to merchants. But the more you can simplify, the much easier everything becomes. Resiliency, performance, reliability, maintainability, all the ilities become much, much more, much easier when the code base is simple. Now, all you need really is, like, the mandate, right? Of like, "Oh, well, let's look at this code, and if I could start this today, would I really build this thing? Or do I now have enough domain expertise to say, 'Oh no, this is the right solution.' So can I delete, start over, and build this, uh, more easily?" And now everything else becomes, uh, like, easy to build on top of. And so we routinely... We have like a, uh, we have a delete code club. We have hack days which happens two or three times a year where there's always one team that is focused on deleting code. They even have, like, a manual. "Here's how to find things to delete." And it's amazing. We almost always delete... I don't know if this is good or bad. We can always almost find million, a million plus lines of code to delete-

    6. LR

      Wow.

    7. FT

      ... um, which is insane. But, at the same time, I applaud the teams for going after, like, the cruft in the code base. And everything gets easier, right? Code lets, loads faster, it's easier to understand. This is why when I look at GitHub stats, you shouldn't really look at... You know, I think Google put out and said, "Oh, 25% of all code is now written by AI." I'm like, "Where's the delete? Where is the 25% of all code as deleted by AI?"... right? Like, this is where we have to start thinking about it because the right code is never the voluminous, like, lines of code metric. It's always something else. It's always, like, elegance. And that's where we have to think about. So, it is something that we, um, as part of us being long-term infrastructure thinking, um, we really do care about

  10. 49:0557:45

    Three buckets of building

    1. FT

      that.

    2. LR

      I love this in part be- because it connects to the topic we're talking about, which is speed, velocity, intensity. Smaller code base, cleaner, better code base allows you-

    3. FT

      Yeah.

    4. LR

      ... to move faster. I used to be an engineer actually, but both my engineering brain and my PM brain, like, I love the idea of we're, you know, killing stuff that's useless, fixing, making code cleaner and better and more durable. Uh, in reality, very hard for companies to prioritize this kind of thing. Is there anything you found that helps you do that? You mentioned hack- hack days and weeks are one part of that. Probably helps that Tobi's an engineer and he understands the value of this kind of stuff. But I guess for folks that want to do this more, any advice?

    5. FT

      Yeah. So we, I mean, we actually think about, when we're building something, we think of it in, uh, one of three buckets. We're like, "Are you building an experiment, a feature or infrastructure?" And once you bucket things, you can say, "Oh, it's an experiment." You're like, "Cool. This is not infra. This is like we're trying something to learn." And it might turn... By the way, that might turn into an experiment or infra, but it starts off as an experiment. Now, if you're building a feature, a feature is basically you're taking advantage of an existing piece of infra, right? So token gating is the example I gave. If you could now build that in one hour, you, you would probably say, "Oh, we have the right infra below it." But if you did what Tobi does, which is, he's like, "Here's the infra I wish existed. Here's the feature. The feature might be quick to build, but now I have to go and build the infra." You're now slotting yourself into infra land, which is like, that could take longer, but you're now enabling it for a bunch of use cases you, you, you don't have to think about all at once 'cause you may have people using your API in a different way. So, I think you kind of have to slot yourself. Now, how do people get into this mode? It is super, super hard. And I would say, like, Tobi is the secret sauce here because he, he pushes us to think about things as infra almost all the time. I mean, one of the things that annoys me the most probably is that I'll always come to him and say, "Hey, we can do A or B." And he looks, he looks at me and he goes, "You know what I'm going to say, right?" I'm like, "You're gonna say, 'Go back and generate more options.'" Because he doesn't like those. "I don't like A or B. Come back when you have something else." Right? He has, he actually... And maybe I'll tell you a little anecdote. He has a story where he says, "There are unlimited amount of wrong options for any problem. There's probably 10,000 right options, but everybody stops at the first right one." Instead, what you should be spending all your time on... Because th- the options that don't work, you d- you're not gonna spend time on. But you have to figure out which of the 10,000 options is the right one, and spend time in that, what are the, all these right options. Don't just stop at the first one. And so when I come to him and say, "A or B, I'm picking two of the 10,000," and, like, he's like, "That's not what I... Go back and generate more options, because those are not the optimal ones." So, he, he is, like, quite, you know, the philosopher on these things. And it does really change the way the company works, because he'll push you on these things, and then we, we over time learn to spot the same patterns. And I learned to push my team on infra and deleting code and making things simple. Because by the way, who doesn't want to get free stuff, right? Like, free performance, free easy to navigate code base, free maintainability, free resiliency, because now we went and did the hard work of deleting. It is hard. But that goes back to the beginning, right? Like, choose the hard thing. Don't just build the feature.

    6. LR

      Mm-hmm.

    7. FT

      Go make the feature easy to build.

    8. LR

      I feel like there's just more and more good stuff. What else, what else is there that might be helpful to folks? Uh, while you're thinking about it, uh, and interesting, I was reading your tweet where you shared a lot of this advice. And I f- you mentioned this briefly, but I think it's important. With pair programming, one of the benefits is there's no multitasking. You're not, like, checking Twitter, Slack while you're working, 'cause you're there watch- being watched. (laughs) And I could see why that is more productive, just innately.

    9. FT

      Oh, no, for sure. People... And P- again, like, uh, underhanded free throws, not only looks dumb, it feels dumb. People don't... Like, they feel like they're wasting time sitting beside somebody and being like, "Well, I could be on my computer doing this thing." Like, but together they are building a, like a machine, right? Like, do you ever read, um, The Undoing Project-

    10. LR

      Mm-hmm.

    11. FT

      ... which is about Amos Tversky and, uh, Danny Kahneman-

    12. LR

      Mm.

    13. FT

      ... the famous, you know, philosopher-

    14. LR

      Yes.

    15. FT

      ... uh, you know-

    16. LR

      By, uh, Michael Lewis, I think.

    17. FT

      ... behavioral, behavioral economics. Michael Lewis, exactly. And he said, um, the famous line was, uh, "T- uh, you know, alone we're okay, but together we're a genius." Right? Like, that's a pair programmer. That's like two people. You're like, "Ah, we're o- we're okay, but like together we're a genius." And that's exactly what pair programming is. And hopefully me plus like an LLM is a genius, right, as well. But that's like the, that's the genesis of that, of, of that thinking. So, I would say another thing that helps us, uh, create intensity is demo culture. So as part of the GSD updates, we ho- we, we encourage people to share, like, high fidelity updates, which is not just imagery, but actually a demo. One of the things that can go wrong if you just share screenshots is you don't really get the full experience. Like, you can't tell how slow things are or whatever. But with a demo... So, you can put a link. We have this tool called Spin, which is like an internal, uh, development environment, like a cloud dev environment, where you can say, "Hey, c- click here to try this on Spin." And then you can try it, and you can see how it works. Or you can t- or they say, "Turn on a beta flag in your own store and then try it." And so this short circuits a lot of misunderstandings 'cause you're like, "I'm gonna try it," and you're not waiting till the end, right? Especially with a beta flag. You're like, "Hey, it's in my store. I just realized that I went in and now the- that, this page takes like 20 seconds to load. Is that what you expect?" And you're like, "Oh, we didn't find this use case." Like, you're gonna learn that much more quickly. And that creates, again, intensity on the fidelity of the feedback you're getting, because you know, famously some of our PM team will create a friction log. They'll be like, "I am walking..." They'll just create a, s- create a screen share, create a video and go, "I'm walking through. I turned on the beta flag. I'm walking through this experience. Here's my feedback on the experience." And you're getting this high fidelity throughput coming back to you, that you're like, "Okay, let's fix these things for next week's iteration," and then share another beta flag and say, "Okay, try it now. Try it now. Try it now." And so you're not, um, debating about status reports, you're kind of debating about the experience.

    18. LR

      So I'm trying to think like, uh, broadly all the things you've shared, kind of how they fit together that allow you to move this fast. And I, I just looked up a few stats. ... to give people a sense of just the size of the company today and how successful it has been as we, as they hear the stuff we're talking about. So you guys are about like 11,000 employees, something like that according to the Googles, and you're hitting not necessarily all-time highs on market cap 'cause COVID gave you guys a big boost for a while, but you're kind of like coming back to this insane valuation that you all had during COVID. So it's essentially all-time highs at a 10,000 plus person company, moving really fast, shipping constantly. People love the product. And it feels like one key of what you're describing is essentially this operating rhythm that creates these check-ins that keep people moving and focused on the right sorts of tools and getting them quick feedback if they're moving in the wrong direction.

    19. FT

      And having the leaders pair with those people on those problems, not just checking in but actually pairing with them on the problems that they're facing so you get both, like, the pe- the crafters who are working on the stuff and the leaders who may have broader context working together to kind of unblock.

    20. LR

      And it's so interesting that it's like, again, people are often like, "We don't need meetings. Get rid of all the meetings." Like you guys do that, but also just there's a lot of power in strategic meetings and check-ins. Another kind of bucket is just like the engineering environment, engineers working with engineers, pair programming, um, things like that. There's a tool you mentioned for pair programming, Twople I think.

    21. FT

      Yes. Twople, yeah. I mean, it's funny because like we use it exclusively, but, um, we actually have this no- we have this line internally, we call it like Shopify should be a crafter's paradise. It should be the place where crafters come to practice their craft and get better at their craft. Obviously like resonates from a lot of the engineering crafters, but it's not only engineering, it's UX and PM and like ML, like all the pla- all the places where you'd, you'd want those people to actually have a great experience. We want them to come to Shopify because we believe this is the best place for that.

    22. LR

      I love it. There's also, I just wrote a note down of just how you set up your teams for succ- oh, just avoid distractions. So I think the pair programming helps, the work space-

    23. FT

      Yep.

    24. LR

      ... workplace shift from-

    25. FT

      Yep.

    26. LR

      ... Slack helps. Uh, I think you're also like very firm on, on like their working hours. You like-

    27. FT

      Um.

    28. LR

      ... basically don't let... No? Okay.

    29. FT

      No, not really.

    30. LR

      I'll check that. (laughs)

  11. 57:451:00:29

    Remote work and trust battery

    1. LR

      first as a company-

    2. FT

      Yes.

    3. LR

      ... which I think is especially cool now. A lot of companies are going back to not remote, you guys are staying remote. What do you, why do you guys decide to do that? What's, what have you seen as a big benefit of that?

    4. FT

      Yeah. So we have this, uh, remote, so I like to call it like 90% remote or 95% remote because we have these intentionals, intentional IRL experiences. So every summer, we just started last year, like sorry, this year, we're doing this thing called Shopify Summit where we bring the whole company together, get together and we like, it's a combination of talks plus hack days and we, you know, it's a coming together experience, like food and like parties and like, you know, bands and like, it's a super fun way to kind of re-energize and rebuild your trust battery over time. And then we have this thing called bursts, which is, hey, you want to work on a problem? You want to, uh, you need to prototype, you need to hack? People can just say, "Hey, I'm starting a burst. We're going to have five people, we're all going to go to Ottawa or Toronto or Montreal or somewhere else, and we're going to talk about this problem and get together." And so a combination of those two things mean like throughout the year you can recharge. We have the trust battery notion which is like how much, uh, you know, how much trust can you have, uh, between people and it can deplete over time if you're remote. So, and then we have offices which are like, come in if you want. Right? Like I mentioned, I come in like once a week and now Tobi moved to Toronto so now I'm in like three days a week. But it's like, if you want to come in, you can. You don't have to. Right? Today I work from home, um, but tomorrow I'm going in. And that allows you again to have those random interactions and allow you to feel like, yeah, we're like 90 plus percent remote but, um, the, I would say the main reason is we want to hire the best people in the world and those people can be anywhere, and, um, just happens to be that they're, not all of them are near an office. And so, but again, with the bursting, like here's a good example. For Black Friday, Cyber Monday, I encouraged all of engineer- engineering leadership to come to Toronto. We're all going to be in the office like, you know, watching the graphs. And then, um, you know, for hack days, I tr- I try to get people to go to the ports, right, which we have, you know, four of them, Toronto, Montreal, Ottawa, and New York, which again, are come in if you want, but then get that IRL. And so it's kind of a little bit of a combo. I wouldn't call it hybrid though 'cause like we don't really have like every Friday you come in or don't come in. It's more like come in if you want.

    5. LR

      There's so many things to talk about. Uh, this trust battery metaphor by the way is awesome.

    6. FT

      Yeah.

    7. LR

      I've learned to use it also and again, it's just basically everyone, your trust with someone is like think of it as a battery that can deplete and grow and y- you should try to, uh, charge it up as and when you can-

    8. FT

      Yeah.

    9. LR

      ... and then use that charge over time. (laughs)

    10. FT

      And it can be strategic by the way. I've seen people use it as a, like I'm pretty sure Tobi says he starts everyone at 50% and then he gets to know you, and then I've seen people use it as the opposite saying, "Hey, look, this team is hard charging, I'm going to start you at 100." Assume that you already have high trust, do the things, and only if you are doing things that are off, uh, off alignment does your trust battery deplete. So I've seen people use it, the terminology in a, as a shortcut way to figure out how to

  12. 1:00:291:03:14

    Finding stability in uncomfortable times

    1. FT

      work with somebody.

    2. LR

      I love just how first principles you all are and how so many things are so unique to how you operate and clearly it's working, and so I feel like we just keep going on and on. I want to talk about hiring. I know you have some pretty unique perspectives on how to hire people that are awesome but also hire them quickly. But before we get there, is there anything else that you think might be really valuable to share in terms of intensity, velocity, moving fast?

    3. FT

      I think the personality of the leadership team is quite intense. (laughs) Um, we have a lot of like, we have a lot of founders on the exec team.... which are impatient, intense people by design. But even some of the non-founders are just accomplished people who, um, tend to be pretty, like, they have, we all have this attitude of impatience. And so maybe that's, I don't even know if that's a, like a learned skill you can learn or if it just comes, like, you know, c- it comes along with your personality, like genetics. But we typically, even at the leadership team for example, we try to do, like, my, here's my weekly thread of all the things that are going on so that we can not only share, but also show progress on things. And then someone can jump in and say, "Oh, this thing you're doing that h- it relates to my thing that I'm doing over here." But it creates this notion of, like, there's a lot going all the time and we want to keep the, keep the vibes, keep the energy high. There's a lot of high energy, intense people.

    4. LR

      It reminds me, while I was at Airbnb, it felt like no matter how well things are going, it always felt like the fou- Brian especially, is just pedal to the metal. No (laughs) matter how well things are going, there's always this not going well enough. How do we go faster? How do we do more?

    5. FT

      Well, I'll show you, I'll actually go farther. I think if you don't have, like, two or three big projects that are on fire, you're probably not pushing hard enough because you're not really trying things that are outside of your, like, if everything's going well, are you really trying, are you really taking the risks you need to be taking? So I think you kind of have to over-rotate a bit and have a, there should be a few things on fire at all times. Not because, it, like, you should create that, but it should just happen because you're stretching into new things that potentially, or you're going faster than you should have, or there's a new leader you've counted on early. Because all these things that should create this thing of like, it, it might work. And so, um, you want to have a little bit of chaos at the edge.

    6. LR

      I, I love that. And it may sound stressful and why would I want that? Why would I want to work with chaos and fires everywhere? But in reality, if you don't, your business is unlikely to become incredibly successful, and that is even more stressful and painful.

    7. FT

      Correct. Yeah, it's like the opposite, right? It's like this idea of, like, people feel like the comfort gives you, like, stability, and really the uncomfort gives you stability, because now you're con- you're in a con- you're constantly learning, and that makes you more robust against things that could come across.

    8. LR

      Choosing the harder path, some might say.

  13. 1:03:141:11:41

    Hiring philosophy

    1. LR

      Okay, let's talk about hiring. You have some really interesting takes on hiring. One that I've heard about is that you, you kind of don't like the interview process. You kind of liked to prefer not to interview and do something instead. Talk about that.

    2. FT

      Yeah. Yeah, so throughout my career, what I've noticed is that, and I'm sure everybody, this is a dirty little secret, right, interviews are not a good predictor of performance. We know this, we know this from studies, we know this, everyone at their company knows this, where, like, somebody interviewed well, wasn't as good in the job, or the opposite, didn't interview well and then came in and was phenomenal. One example I have from my l- from my startup, where, right before, you know, we came to Shopify was, I hired two people for machine learning. One was, like, a PhD, taught at the university, was like, oh my god, no-brainer. Was also recommended by an employee. We're like, "Oh my god, this person's gonna be great." The other person was, like, a dude I met at the coffee shop who had never (laughs) had a software job, but was, like, just so interested in machine learning. And, um, person A we let go within a few weeks 'cause, like, not a fit for our culture. And person B is still, when... Was at our startup and is still at Shopify today, and is a phenomenal machine learning engineer who literally at our Christmas party was like, "You know this is my first software job, right?" We're like, "How?" But was just so cur- like, and we gave them both a shot. Like, the key was, I didn't use their resume in either way to bias. We brought them both in. We said, "Here's the environment." We had, it was all pair programming at my startup. And so they pair programmed and, uh, you know, actually, as an aside, you know I care, I, I, I really believe in pair programming when I made, with my, I made people work in pair programming with my own money. Like, I-

    3. LR

      Mm-hmm.

    4. FT

      ... I paid people to have, I paid for two people to be on one computer. So that's how you know <|agent|><|en|>

    5. LR

      Write less than half the code.

    6. FT

      ... how much... Yeah, exactly, right? Less than half the code. But anyway, so pairing, and they, um, and it was pretty clear after just a, you know, few weeks. I'd say, let's, let's say up to three months is, like, the amount of time I give people. Um, that person A wasn't going to work out and person B was. So what I really like to do is use this, like, race car analogy. If I told you, "Hey, I want to go hire the best race car driver," there's not really that many questions you could ask them except for, like, put them in the car. (laughs) And so the same thing happens with us, is that of course we have to do interviews, but we do really spend time in the 30, 60, 90 days to make sure that the thing that they br- are bringing actually lines up with what we need at Shopify. And you should also be transparent with people, because if it's not a fit, it's actually good for them and you to figure that out as quickly as possible, 'cause they could be amazing somewhere else, right? Like, we mentioned, like, the chaotic environment and fast-moving environment at Shopify is. That's not for everyone, but that's okay, right? We're not looking for, right? We've talked about like, we want to be as, you know, the best 10,000-person company in the world. We're not looking for, like, millions of people. We just need the best 10,000. And so if it's not a fit, like, it's in your interest and our interest to figure that out quickly so that you can go somewhere where you will be amazing, and for us to have the people who will be amazing at Shopify. And so job trials, I'm a huge fan of, which leads me to, like, intern programs. What a great interview process, because you now have real work product from somebody for four months. They get to see what it's like to be at Shopify for four months. We get to see what it's like for them to be at Shopify for four months, and that can turn into, um, a full-time gig. And that's a great interview process because you literally know exactly, you don't have to... I'll give you a funny example. I think I've heard a company where like, "Oh, we have an intern process, and then afterwards we interview them for full-time." I'm like, "What are you gonna learn from, like, let's say even eight hours of interviews that you're not gonna have learned from four months of real work experience?" Like, and so there's just things like that you just, you just got to look at the work product. And so I'm a big fan of, like, job trials and in my previous companies, I almost, like you mentioned, I almost didn't interview anybody. I almost just said, "Come in and work." And it allowed us... We had a much higher, like, in the first 90 days, like, 20% attrition before 90 days because it just didn't work out. But those after 90 days, we had less than 1% attrition because you, they knew exactly what they were getting into and we knew exactly how they were gonna fit.

    7. LR

      So in terms of the hiring process, you're still at Shop... You're interviewing people, they do technical evaluations, things like that. But it sounds like there's a very strong setting of expectations, "We will hire you, but if... We'll actually clarify if this is a good fit in the first 30, 60, 90 days, and we're gonna do, like, act- we may let you go, and there's a good chance we may let you go." Is that just the way you set things up?

Episode duration: 1:40:02

Install uListen for AI-powered chat & search across the full episode — Get Full Transcript

Transcript of episode C_lhMOjG7PE

Get more out of YouTube videos.

High quality summaries for YouTube videos. Accurate transcripts to search & find moments. Powered by ChatGPT & Claude AI.

Add to Chrome