How Shopify builds a high-intensity culture | Farhan Thawar (VP and Head of Eng)

22:48And you can just remotely be on one computer. And you're totally right. The famous tweet about 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're right even less than that. Because it's not about lines of code, right? The throughput limit is not hands on keyboards. It's not like we're both sitting there and the limit is like us trying to get through the key, like the keystrokes on the screen. The limit is where is the good, elegant solution? How do we think through the problem and build the right solution for the problem at hand?

23:21Toby 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 their 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 deleted all the code, kept the tests, and then wrote it again. And sometimes it'd be over by one minute.

23:54And 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? Because you now know the problem domain. And it's, by the way, it sounds like it's the time, right?

24:26Like it sounds like I'm just deleting code. But the reason is that code lives a long time, code is a liability. And the like the right solution, the 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, no, no, delete. And it's super hard to delete, by the way, because we're humans, and we have this sun 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 remote, like or directly, you're learning key strokes, and you learn how somebody thinks about a problem, you go back and forth on the talking.

25:12And 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 if you did it on your own. And there's all these studies that show happiness is higher, knowledge transfers higher, less silos, intensities 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 the underhanded, free throw and basketball, right? Statistically known to sink more baskets, but looks dumb and nobody does it. Like literally Shaquille and Neil, I'm not that big a basketball fan, but I read this about Shaquille and Neil, who is a Hall of Famer, and they said, why don't you throw underhand?

25:49Cause 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. I remember those Shaquille and Neil years, when he was hit a special free throw coach, and I remember them talking about this and he's like, no, I'm never gonna do that. I'm never gonna do it, because it looks dumb. And by the way, go back to the beginning 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. So on that note, so what percentage of shop, like Shopify do this?

26:19Is this how you all operate? Yeah, so Shopify, I mentioned that Toby and Cody did this at the beginning of Shopify. And the cool thing about pair programming is, and in my old world that extreme lab, is that we knew exactly what to build, cause we were building like mobile apps that were almost like contract manufacturing, 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 path -finding 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.

26:54Shopify 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 path -finding and trying to figure out what to build. And trying to convince people to 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.

27:25And that's something that we will do at that point. And so you don't wanna be pair programming for 18 months, you wanna be like way finding and path -finding and then go, I see the matrix. Let me just lead everything and now build it because the learning is what you're going for. We have all the learning, now let's write the code. Got it. So it's basically when the code is really, you're pretty sure this is correct and it's really important segments of the code base, pair program. Yeah, and then also we do a lot of pairing during like an incident or a way to like figure out together, work with somebody and say, hey, I'm not really sure.

27:56And 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. I can't help but ask, AI, how does that impact this way of working? So, AI is super interesting. What's happening right now with an AI copilot, like GitHub copilot 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 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 us, oh, no, that's not what I meant.

28:30I meant doing this. So you can actually not even have to type just using voice, go back and forth through 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 copilot 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 because you have inspiration and write it yourself or just take the suggestion and move it forward. But I love today's world of AI copilots because you're now, you never have to code along on your own, right?

28:59You never have to code alone. You can try different language now because the API and the syntax is much easier to pull forward. And so all of those things are like a win for engineering and a win for everybody who wants to build any sort of software. That makes a lot of sense. Basically everyone's gonna be a pair programmer. Yes, exactly. 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 get more done in the time we have and then go home. Not just work all day, every day we have this kind of intensity.

29:34Yeah, so we have a few things that we have going for us, right? So one, we have this tool called GST, which stands for Get Shit Done, which you probably heard from maybe talking to other shop of 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 like a Black Friday, Sabra Monday, or like we had like an event in the summer.

30:04And 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 Toby. 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 all, you know, a bunch of us will be in the office together and we're going to go through every project in the company. And we're going to talk about the project, the resourcing, how it's going, and we're going to make changes.

30:36And 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, let's say a team as 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?

31:06Like 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 the trajectory, right? Like I actually, I want to get that Elon shirt made, like what have you done this week? Because Parkinson's law is real, it sounds funny, but like I keep bringing this up, but whatever time you allow 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 re -orc or something, right? You can do it the slow way, let's sit down and plan and roll it out over, and it's probably like six months in most companies.

31:37Jobify, this is like a week or two. You sit down, you're like, hey, this is kind of the bones of it, let's bring some more people in thing. But 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 things to shop, but we just try to move more quickly and get out of the chain, 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, this is what's happening, but this is how we get things done quickly and then move on with our lives. Wow, there's so much there. I've been through those six month re -orgs and I'm trying to, like I think that context, you just shared of, we're at a volatile company, we're changing things, it's not going to be smooth, but here's, we think this is for the best.

32:15It's just a culture of Shopify, it sounds like we, we want to keep moving fast. We know this isn't going to be the smoothest thing, but we just know this better to make the change at this point versus weight. It's how Toby increased the resiliency in the company. He would walk around in the old days when we had a data center, just unplugged machines, right? Like the chaos monkey. Yeah, chaos monkey, right? 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.

32:43We are here to create more entrepreneurs in the world. We are not here to have a six month change management road map. And that will just actually hurt the speed at which we can deliver value to merchants. So kind of on those, 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. Each project. Each project. Each project can get, like it has an update, it can make up a video of, here's the experience, it'll have a bunch, obviously, a bunch of writing on like what's changed this last time. We have a process called OK1 and OK2, which is like, OK1 is typically at the director level where they're like, OK, this is like, I'm aligned with the direction that this is going at or I'm not aligned and they can make changes.

33:21Then when it goes to OK2, it's typically like a VP level of the area, who's now looking to say, OK, what you're working on actually aligns with the overall architecture. But by the way, have you looked at this context, maybe you haven't seen this, this is happening or the industry, so you're trying to align at that level. And then again, like I mentioned, every six weeks we go through with Toby and like, he's an intense guy at himself. And so a lot of it is like, hey, why is this taking so long? Are we overthinking it? Are we not trying to move forward on this thing because we're blocked on something?

33:51Is 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, we have shared Slack channel with all the LLMs folks, right? I messaged in the OpenAI channel, I messaged in the Gemini channel, whatever. And within an hour, we had increased the output context on a bunch of major models. And we were able to kind of move forward through the thing just because I asked.

34:29And so that's an example. It didn't take another six -week review, but it increased the intensity because the team was like, oh, we were blocked because we thought we had to now chunk up this data and do this thing because we had smaller output context and we thought we could do a big input context, but we'd have to do this casheting. 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 will this enable it right now for Shopify? And so that kind of created the intensity of the team, we're like, oh, we can now quickly get them blocked.

34:53So that's a kind of example of just like moving quick and trying to like just ask again, ask a dumb question. I'm like, this is probably not possible, but. And then they came back and said, yeah, we can do that. 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 you're listing is a bunch of meetings and check -ins, which to most people would feel like, why do we need so many, there's all this less meetings. And I know you guys famously cancel all your meetings and that's the whole thing we can talk about. Yeah.

35:24But it's interesting that more check -ins and regular check -ins allow you to move faster. Imagine it's partly because they just make sure you're not working on things that are unnecessary and dumb and not gonna be used. And it's just continuing to refine. These are actually the most important. I mean, it's a combination of trust but verify. 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. It's not like the Dilbert boss, did you do your thing, right? It is, even when I look at the Elon text, which is like, hey, what did you get done this week?

35:54It 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 asked somebody, like, 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's so then I can then look at the answer and say, oh, so now are we gonna try, like, how do you start of this? Have you tried, it's a way to pair on the problem. So it's not like, you know, 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 bossing, where did you do the thing?

36:31It's like, hey, can I work on this problem with you? And if I work on this problem with you, I kinda gotta see where you are pretty often and then give you advice or you're gonna share a context with me because I don't, I'm not gonna work 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 wanna 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 animals with me and I'd be like, Toby, you don't have to waste your time, man.

37:00Like, you hired me and I got this. I'm like, where he goes, oh, you misunderstand while you're here. I'm, we're here to work on problems together. And I was like, oh, I didn't even think, I thought he hired me to take problems away. He hired me to work on problems with me. Like, that's completely different than what I thought. I love that. Okay, one thing you mentioned is meeting thing for people that don't know what you all did with meetings. I think it might be worth just sharing that briefly because it's awesome and something a lot of companies can learn from. Yeah, sure. Actually, the funny story about the meeting Armageddon is that I was messaging Toby prior to me starting a Shopify about meeting Armageddon.

37:36And so I actually think I had a little hand in him like doing this before I got to Shopify because I was like, hey, I think it was Dropbox. I think my Dropbox is doing and meeting again. 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 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 our 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.

38:09You get a regular meeting, but not a reoccurring meeting. And the idea is that there's a lot of inertia behind a recurring meeting. It just always is there and you know what's coming up and it's hard to delete because you're like, well, yeah, we talk about this thing every week. And so what we do is we kind of just do a meeting reset. And I think it's just called Chaos Monkey and some, the admins go in and just delete everything. Now what's cool about it is it forces you to rethink. Do we need a recurring meeting or do we just need one meeting or do we need a different cadence? That's one thing.

38:37The 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.

39:12So 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 it 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. And how many hours was it before a meeting get in and work? Yeah, you're asking me not a good question. I have to go look and see, but it came down by something like 50 or 60%. Like it was like something like five or six hours for individual contributors and came down to three.

39:42And then the manager was, I think it was like 10 and came down to six, something like that. But it was a huge difference. And the only two things were like I mentioned were like one was the meeting get in. The other one was like this. And I can talk about this. This is like a, yes, let's talk about this. Yeah, so I mean, I love slack. It's like the I M tool everybody uses it, but it can for sure cause distraction. And so what we did was we moved all announcement information. So like anytime you're setting a status update or large group announcement, we moved all of that to like face meta workplace, like Facebook for work basically, which is now being deprecated.

40:13So I'll have to figure that out. But it just moved all this stuff to like a ML feed that you can kind of consume differently than you would slack. A slack is like a message to you. And you see an alert and all this stuff versus workplaces like, oh, I want to go and consume content from the company and get updates and share updates. And so that reduced the lot of distraction as well. And so I'd love to figure out what the next tool for us is, but it is, it's probably something more like a river of information that I can dip my toe into versus like I am and chat everywhere. That is super interesting.

40:45So it's specifically things that are just updates where you don't need a discussion. You almost want to discourage a discussion. Yeah, I mean, I have the commenting, but it's not the same as like, you know, it's not it's not the same tool. Like slack. By the way, slack is amazing. We use it. It's just that for this thing, it wasn't working for us. And so we wanted to move that somewhere else. I feel like the more I dig into the Shopify way, working the more fun stuff I never expected emerges, I'm curious what else is gonna emerge. So we've been talking about ways that you all and use specifically have created intensity, especially in the engineering work.

41:17And then you've also shared just broadly Shopify. What else is on that list? What else have you found helps create more killer jewels per hour? Yeah, so I think again, I think there's nothing, I would say again, start from the beginning, there's nothing more than paraprogramming because literally you can't do anything else, but be on your computer. So like paraprogram is the number one. I will say that weekly cadence helps a lot, right? Which we mentioned, which again, which is part of GSD, which is sharing the updates and then the six week reviews. That does a lot. On the other side, we also have a lot of metrics and alerts that help us see when potentially things might be happening in the system that can allow us to be like, hey, wait a sec, there's too many things going on of this type.

41:53We probably have to sit back and reset and figure out what's going on. So one thing that happened, for example, was, we started seeing that it was taking a lot of time to develop in our admin, like engineers at Shopify developing in the admin. So we called it what's called like a Codiello, which is before Code Red. The Codiello is this idea of like, hey, we're gonna call it Codiello on the admin. We wanna make sure that the developer experience inside Shopify is really good. It should be easy to start up the repo, it should be easy to make changes, it should be easy to see the changes. And so those are the kinds of things that again, we can create intensity because this Codiello allows the champion to tap anyone in the shoulder and say, stop what you're doing and come help this thing, which is an infrastructure layer thing.

42:32And by building out this infrastructure, it allows you to go fast, it takes longer to build the infrastructure, but it makes you go fast forever afterwards, right? Actually, I'll give you an example of one of these. So we, 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, number 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 it, but only if you have the token.

43:04And 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 buyers to have to have the NFT to have this great experience. And we're like, we agree, you wanna be able to do, we want you to be able to do whatever you want. And so we wanna build this for you too. And, saying with Toby, he's like, you guys are thinking about it wrong. Because 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 platform layer, which exposes APIs, so anyone could build NFT gating in one hour?

43:33I'm like, I don't know, like two, three months, he goes, do that. He goes, because 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 at the key part was, what can you build so anyone could build this in one hour? 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.

44:05He'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. Because 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 this is notion of like building things as infrastructure that sounds slower today because it's going to take, it's two, three months, so that it's two, three weeks.

44:38But after that, the things that people built on top, right? We're so easy to build, there were so many more scenarios that were emerged. It's just a different way of thinking about software. And it really, again, allows, it's intensity to different way. It's 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 over Infra in a much, much quicker way. And of course, who knows what can flourish from there? 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 point solution for someone.

45:16And 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. No, exactly. And actually, you're making me think of a stat. So last year, I tweeted out maybe a tangent, but I tweeted out that GitHub Co -Pilot has written over 1 million lines of code for Shopify. And people are like, oh my god, and they got picked up, and everyone's talking better. And I go, I don't know why I was getting so crazy because what I want to see is GitHub Co -Pilot deleting 1 million lines of code.

45:50That's when you know we're actually at this point where this is close to an engineer, right? And so we famously have deleted millions of lines of code this year because we're trying to focus on, again, the sunk cost and rebuilding things elegantly or you don't need this anymore and rebuilding. And I even tweeted out, I think someone said, oh, Shopify is in the top 10 Ruby code basis in the world. And I said, I never want to see on this list again. Like, it's not like, we shouldn't be gunning for number one. And we should be gunning for number 100, right? Like, we want to be not on this list, right?

46:19Someone else can take the crown. 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 risks, 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.

47:04Get $1 ,000 off Vanta when you go to vanta .com slash plenty. That's V -A -M -T -A dot com slash 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 behind that, what's going on there. Yeah, so there's a few things, right? One is the more context you can fit in your head around a code basis, and you can never really fit all Shopify in your head because it's the complicated, complicated set of tools where you give to merchants. But the more you can simplify, the much easier everything becomes. Resiliency, performance, reliability, maintainability, all the illities become much, much more, much easier when the code base is simple.

47:45Now, all you need really is 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 more easily? And now everything else becomes like easy to build on top of. And so we routinely, we have like a, 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.

48:16And it's amazing. We almost always delete, I don't know, this is good or bad. We can always almost find a million plus lines to code to delete, which is insane. But at the same time, I applaud the teams for going after like the cruffed 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 is deleted by AI? Right? Like, this is where we have to start thinking about it because the right code is never the volumous, like lines of code metric.

48:54It's always something else. It's always like elegance. And that's where we have to think about it. So it is something that we, as part of us being long -term infrastructure thinking, we really do care about that. I love this in part because it connects to the topic we're talking about, which is speed of velocity intensity, smaller code base, cleaner, better code base, allows you 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, you know, killing stuff that's useless, fixing, making code cleaner, and better, and more durable.

49:26In reality, very hard for companies to prioritize this kind of thing. Is there anything you've found that helps you do that? You mentioned hack days and weeks, or one part of that probably helps that Toby's an engineer and he understands the value of this kind of stuff, but I guess for folks that wanted to do this more in the advice. Yeah, so we actually think about when we're building something, we think of it in 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, it's 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.

50:01Now, if you're building a feature, a feature is basically you're taking advantage of an existing piece of infra, right? So token getting is the example I gave. If you could now build that in one hour, you would probably say, oh, we have the right infra below it. But if you did what Toby 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 don't have to think about it at once because you may have people using your API in a different way.

50:32So 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, Toby is the secret sauce here because 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 all I 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 gonna say, right? I'm like, they'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?

50:59He actually, 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 the options that don't work, 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 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 he's like, that's not what I go back and generate more options, because those are not the optimal ones.

51:31So he is quite 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 over time learn to spot the same patterns, and I learn to push my team on Infra and Deleting Code, and making things simple. Because by the way, who doesn't wanna get free stuff? 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, go make the feature easy to build.

52:06I feel like there's just more and more good stuff. What else is there that might be helpful to folks? While you're thinking about it, and interesting I was reading your tweet where you shared a lot of this advice, and you mentioned this briefly, but I think it's supported with paraprogramming one of the benefits is there's no multitasking. You're not like checking Twitter, Slack, while you're working, because you're there watching, being watched, and I could see why that is more productive, just innately. Oh no, for sure. And again, like Underhander Feathoriz, not only looks dumb, it feels dumb.

52:37People don't, like they feel like they're wasting time sitting beside somebody and be like, well, I could be on my computer doing this thing. But together they are building a machine, right? Do you ever read The Undoing Project, which is about Amos Versky and Danny Conneman, the famous philosopher, Michael Lewis, I think. Behavioral economics, Michael Lewis, exactly. And he said, the famous line was to, alone we're okay, but together we're a genius. That's a paraprogrammer. That's like two people, you're like, oh, we're okay, but together we're a genius. And that's exactly what paraprogramming is.

53:13And hopefully, me plus like an LLM is a genius, right? As well, but that's like the, that's the genesis of that, of that thinking. So I would say another thing that helps us create intensity is demo culture. So as part of the GSD updates, 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, even just their 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 development environment, like a cloud dev environment where you could say, hey, click here to try this on Spin.

53:49And then you can try it and you can see how it works. Or they say, turn on a beta flag in your own store and then try it. And so this short circuit's a lot of misunderstandings because 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? You're like, oh, we didn't find the same 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.

54:19They'll be like, I am walking, they'll just create a screen share, create a video and go, I'm walking through, I turn on the beta flag, 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 debating about status reports, you're kind of debating about the experience. So I'm trying to think like broadly, all the things you've shared kind of how they fit together that allow you to move this fast.

54:53And 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 for talking about. So you guys are about like 11 ,000 employees, something like that according to the Google's and you're hitting not necessarily all -time highs on market cap because COVID give you guys a big boost for awhile, 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.

55:30And 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. 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 crafters who are working on the stuff and the leaders who may have broader context working together to kind of unblock. And it's so interesting that it's like, again, people often like we don't need meetings, give it to all of the meetings, like you guys do that, but also just there's a lot of power in strategic meetings and check ins.

56:06Another kind of bucket is just like the engineering environment, engineers working with engineers, pair programming, things like that. There's a tool you mentioned for pair programming, two pull I think. Two pull, yeah. I mean, it's funny because we use it exclusively, but we actually have this, we have this line internally, we call it like Shopify should be a crafters pair of this. 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 places where you'd want those people to actually have a great experience.

56:41We want them to come to Shopify because we believe this is the best place for that. I love it. There's also, I just wrote a note down, I've just how you set up your team's risks, oh, just avoid distractions. So I think the pair programming helps, the workspace workplace, the shift from Slack helps. I think you're also like very firm on like their working hours. You like, basically don't let, no, okay. No, no, no, I mean, yeah, not, I mean, we're not super firm on working hours from that perspective, but we do have, like we have a lot of people on East Coast time zones, a lot of stuff happens then, but we do have people all over the world.

57:13But I did mention we do have like the check -ins on the six week reviews on the cadence, so that's six week cycle does give you a little bit of like what did you get done and are you blocked mentality? And you can expect like a couple, coming in a couple of times and being like, hey, we didn't get a lot done, being a block for you to change your approach to go, okay, I don't want to go to another review where we didn't get a lot done. So what am I doing this time to make sure we unlock a lot of progress and that check -in can give you that ammo to be like, let's go, let's do this this time. And you're also remote first as a company, which I think is especially cool now.

57:47A 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 have you seen as a big benefit that? Yeah, so we have this remote, so I like to call it like 90 % remote or 95 % remote because we have these 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.

58:23And then we have this thing called bursts, which is, hey, you want to work on a problem? You want to, you need to prototype, you need to hack. People can just say, hey, I'm starting a burst, we're gonna have five people, we're all gonna go to Ottawa or Toronto or Montreal or somewhere else and we're gonna talk about this problem and get together. And so a combination of those two things mean like throughout the year, you can recharge that we have the trust battery notion, which is like how much, you know, how much trust can you have between people and it can deplete over time if remote. So, and then we have offices which are like coming if you want, right?

58:54Like I mentioned, I come in like once a week and now, Toby 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, 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 I would say the main reason is we want to hire the best people in the world. And those people can be anywhere and just happens to be that they're not all of a mirror in office. And so, but again, with the bursting, like here's a good example for Black Friday, Cyber Monday, I encouraged all of engineering leadership to come to Toronto.

59:26We're all going to be in the office, like, you know, watching the graphs. And then, you know, for HAC days, 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 coming 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, because like you don't really have like every Friday you come in or don't come in, it's more like coming if you want. There's so many things to talk about. This trust battery metaphor, by the way, it's awesome. I've learned to use it also.

59:53And again, it's just basically everyone, you trust what someone is like, think of it as a battery that can deplete and grow. And you should try to charge it up when you can and then use that charge over time. And it can be strategic, by the way. I've seen people use it as, like I'm pretty sure, Toby 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 alignment, does your trust battery deplete.

1:00:24So I've seen people use it, the terminology and it as a shortcut way to figure out how to work with somebody. I love just how first principles you all are. And there are so many things are so unique to high 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? I think the personality of the leadership team is quite intense.

1:00:58We have a lot of like, we have a lot of founders on the exact team which are impatient, intense people by design. But even some of the non -founders are just accomplished people who tend to be pretty, like we all have this attitude of impatience. And so maybe that's, I don't even know if that's like a learned skill you can learn or if it just 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 relates to my thing that I'm doing over here.

1:01:35But it creates this notion of like, there's a lot going all the time and we want to keep the vibes, keep the energy high. So a lot of high energy intense people. Reminds me, while I was at Airbnb, it felt like no matter how well things are going, it always felt like the brain especially is just peddled to the metal. No matter how well things are going, there's always, that's not going well enough. How do we go faster? How do we do more? Well, I would 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 you.

1:02:11Like if everything's going well, are you really trying, are you taking the risks you need to be taking? So I think you kind of have to over rotate a bit and have, there should be a few things on fire at all times. Not because 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. Like all these things that should create this thing of like it might work. And so you want to have a little bit of chaos at the edge. I love that. And it may sound stressful and why would I want that?

1:02:44Why 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. 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 uncomfortable gives you stability because now you're constantly learning and that makes you more robust against things that could come across. Choosing the harder path, some might say. 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.

1:03:23You kind of like to prefer not to interview and do something instead. Talk about that. Yeah, so through 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 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 startup, right before we came to Shopify was, I heard two people for machine learning. One was like a PhD, taught at the university, was like, oh my God, no brainer.

1:03:57It 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 had a software job, but was like just so interested in machine learning. And person A, we let go within a few weeks because not a fit for a culture. And person B is still, was that 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? Well, it was just so cute. And we gave them both a shot.

1:04:27Like the key was, I didn't use the resume in either way to bias. We brought them both in. We said here's the environment. It was all pair programming, it might start up. And so they pair program. And you know, actually, as a side, you know, I really believe in pair programming when I made people work in pair program with my own money. Like I paid people to have, I paid for two people to be on one computer. So that's how I left them half the code. Yeah, exactly, right, less than half the code. But anyway, so pairing and they, and it was pretty clear after just a few weeks. So I'd say let's say up to three months is like the amount of time I give people that person A wasn't gonna work out in person B was.

1:05:05So what I really like to do is use this like race car analogy. If I told you, hey, I want to go higher the best race car driver, there's not really that many questions you could ask them except for like put them in the car. 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 are bringing actually lines up with what we need to 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 because they could be amazing somewhere else, right?

1:05:38Like we mentioned like the chaotic environment and fast moving environment Shopify is, that's not for everyone, but that's okay. Right, we're not looking for, right? We've talked about that 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.

1:06:13They get to see what it's like to be a Shopify for four months. We get to see what it's like for them to be a Shopify for four months. And that can turn into 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.

1:06:41You just gotta 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 % of tuition before 90 days because it just didn't work out. But those after 90 days, we had less than 1 % of tuition because they knew exactly what they're getting into and we knew exactly how they were gonna fit. So in terms of the hiring process, you're still at job fight. You're interviewing people, they're doing technical evaluations, things like that.

1:07:10But it sounds like there's a very strong setting of expectations. We will hire you, but we'll actually clarify, if this is a good fit in the first 30, 60, 90 days, and we're gonna do like actually, 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? Yeah, I think the way to think about is more like, we want to make the interview process as close to the real job as possible because by doing that, we can likely assess the skills that you have in your interview closer to what's happening in the job, right? So that's one, two, we have this interview step called the life story where we try to figure out if all the experiences you've had up until now, actually gonna be like, does it show that you are a curious person with range?

1:07:57Because if it does, that's likely more of someone who's gonna be a fit. I had this famous line from somebody who said, you know what I don't like about resumes? I'm like, what, they go, it tells you what you did, but it doesn't tell you why you did those things. And it's such an interesting insight, right? Your resume should be a why. Why did you go from this company to this? That's the interesting part, not that you are a PM and Microsoft and the PM at Stripe. It's like, why did you switch from Stripe to Microsoft like what's, there's something interesting there. And so the life story is trying to pull that out.

1:08:26It's like, why did you make decisions? What did you do in your past that was like interesting? Are you curious? Like, do you have, like I always fought, I read this great book range, my David Epstein. That book was maybe one of the hardest books for me to read in my life because every page, I was like, I don't believe it. I kept thinking I was a specialist, I kept turning the page going, I don't like this data that keeps showing that generalists are better. And then by the end, I realized that I'm a generalist. It just was like, it took me so long to realize and funny for me because I ended up redesigning the compensation system to Shopify even though I'm an engineer.

1:08:56So I still thought of myself as an engineer through and through even though I work on recruiting in HR and all these other things. So, but I think that that's what we're trying to tease. And then yes, in that first period, we actually have a survey that goes over Slack that says, hey, how happy are you with the person that you hired? And that should, in conversation with the person, you should give them the feedback to figure out, hey, are there things you need to adjust to kind of better fit in and make sure that the expectations are set up? But then also together with the person figure out, hey, if you're not, if you're not feeling this, let's find you either a different role in the company or somewhere else because we want the people here to have high impact, but that person should have high impact somewhere.

1:09:35Could be a Shopify, could be the same role, could be a different role, could be a different company. But that's like a good thing for everybody. And then do you actually do work trials with new engineering hires or is it like something you aspire to do? Yeah, I would love to do. It's hard to do with the volume of resumes we get, but we do do it at scale with the internship program, right? So like 2025, we're gonna hire a thousand interns and like that is gonna give me a thousand job trials to pick like the top, you know, X percent of those to come to Shopify full time. Yeah, so just to double click on that.

1:10:04So you're hiring a thousand interns. Yes. Over the course of the year, that's a lot. And the idea there is these folks are actually useful building useful things and it's an interview process for you. Yeah, I mean, I think it's two things. One is, is some people look at an internship program as like community service, like let's give back to the community and let's hire early talent. And I'm like, well, on a sec, are you telling me I could hire a thousand people over the year and they will come to work with an LLM and a brain because they are growing up in the age of AI. They will be useful to us because they come from a different generation and they have like, in our case in commerce, they have a different experience about shopping and AI and bots and chat and voice and like all these things, they'll be useful to us.

1:10:47We'll teach them some stuff as well. And then together we can decide if they, you know, they might end up going somewhere else in which case we have to Shopify imprint on them going to whatever other company, which is I think a positive or they might say a Shopify and be useful over a longer period. It seems like win, win, win. The other thing that was cool is after I did that tweet, a bunch of other CTOs messaged me and said, hey, we're gonna hire a thousand one interns to beat you guys and I'm like, great. Like if we can, just from that one tweet, if I can get like the early talent ecosystem restarted here after, you know, a really tough last few years and layoffs.

1:11:22It's great for everybody because now they're realizing that they also realize that these people are super valuable and they bring together a complete different set of skills. And by the way, here's a secret in pair programming, interns will always be more intense than the full time. And so that also helps the fly away a little intensity go. Go for it. It all just keeps coming back. Did the internship programming merge out of this co -op system that Canadian schools have in a waterloo has a big co -op program? Yeah, I went to Waterloo. And so yeah, it hinted. So I went to Waterloo and I did co -op and I did intern programs there.

1:11:57It was amazing what a great experience because what ends up happening is you leave Waterloo with your degree but also with two years of experience because I did six four month work terms, 24 month. And you end up walking, I mean, I think one of the big parts of it is just interview skills because I interviewed for 10 plus jobs every four months and I did that six times. And so you come out having done lots, you have a lot of interview experience but you also have work experience. And so just taking that to the next level, Shopify has always had interns and what I felt like we need to do is again, restart this notion of early talent in the ecosystem.

1:12:32There is one, I would say one or two big differences with our intern program. One is we're making them come in three days a week versus full remote. And the reason for that is, and we're doing it just in three offices right now, Montreal, Toronto and Ottawa. And the reason for that is because we want them to have a cohort because early talent is different than, you know, you and I who've been in the industry. We worked in the office, we worked out of office, we're more comfortable with navigating like partnership discussions and like talking to people in different companies. But these people have not, they maybe have never worked anywhere.

1:13:01And so to not have the IRL component would do them a disservice. And so we specifically made it in those ports. And then people are traveling by the way, like they're like moving to Montreal to do the internship. It's great. And then if you're a mentor or manager for one of the interns, you have to at least see them like IRL once a month. So we're kind of making these experiences. And of course they'll have a cohort of business of people that will be with them along the way. And so we think that'll just make their experience better. And of course, nothing like typing someone on the shoulder. And we're like, have you seen this error before?

1:13:30And so it's easier in an early talent situation. And then of course, over time, if they become full time, they can still come to the office, right? It's come if you want. But they can also go full remote. That is amazing. For folks that don't know anything about these co -op programs, briefly, it's just basically wallier in school before you graduated during the summer. You go work at a company or it's during the year, okay? Yeah, it's during year. So what happens at Waterloo is what I did was I did eight months of school at the beginning. So two terms. My first co -op term was summer. But then it was work, a work school, work school alternating for the whole rest of my time at Waterloo.

1:14:02It's like semester is alternating. Exactly. So every four months, I did either school term or work term. So I was doing work in January sometimes and September sometimes. And it was super good because again, it also allowed me to be super intense at school for four months and then go to super intense work, experience for four months. But yeah, it's a model that, like I mean, I was just that Waterloo this week doing a talk. So I just like, I love that, that symbiotic relationship between Waterloo and the employers. And by the way, not just Waterloo, right? Lots of schools do a summer program, U of T and others, lots of schools in the States.

1:14:32Fun fact, so total tangent. I had a startup called LocalMind started in Montreal of all places. I'm not Canadian, but moved there for various reasons. It was awesome. And our first hire was actually from the co -op program. I don't know if it was Waterloo, his name is Nick Adams. And he applied just, he saw our job posting, you think, and really, what is a co -op? And he came to work and then he went back to school and then we hired him. And then he ended up at Airbnb when we got a court. So there you go. And so for us, actually, what my first, when I did my startup, helpful, we hired, I had one or two engineers.

1:15:07And then I actually literally just hired four interns because you hire them in February for May. And because I was doing pair of broguing, I had to make sure I had four full times by then. So I hired the interns in anticipation of having the full times. And I literally had, I think it was, I was off by one week. So one intern had no pair for a week, but then after that in May, I had four full times, four interns in May, they paired the whole time. What a journey. Okay, I wanna talk about just one other topic real quick and then we'll wrap this up and it's around extreme labs. Okay. So there's a bunch of stuff here.

1:15:41It feels like it's just like this tech mafia of Canada that a lot of incredible people emerged out of. And there's a whole bunch of stuff we can talk about. One fact I heard while you were there is you had a hundred reports, direct reports that reported to you. 120, 120 direct reports feels like a complete nightmare to me. Tell me why you decided to do that if you'd recommend that for other people. Yeah, so what ended up happening there was, we started off small, right? It was 10 people when I joked to extreme labs. I wasn't the founder, but I was very early on. And I just had a phone report to me.

1:16:15And then as we grew, I just kept having those people report to me and I was trying to figure out, like, you know, we talked about like crafters and crafters paradise. This idea of like, people don't really, there's managers are useful. But I was trying to figure out, could I solve the problems that they were, they needed their manager for in other ways? So for example, what should I be working on? I was like, okay, well, we have product backlogs or I'm blocked on something or I need feedback on the product I'm building or I'm stuck on this technical problem. Like I tried to figure out ways to like, not have managers with the answers to those questions.

1:16:47I'm like, there should be another answer. And so pair programming really helps you get unblocked quickly because you have another person that you can bounce technical ideas off of. Having a product backlog can tell you what to work on. We had demos every week. Demos internally and we had demos with the clients every week because we were, you know, contract manufacturing from mobile. That gave them feedback on whether they were going in the right direction, right? We had set working hours which made things like super intense in the office. This is again, like 2009 to 2013. So all these things didn't really need a manager.

1:17:15And what I realized was what the unblocking thing needed the manager, unblocked on this. Well, I said, okay, if I did had all these directors, I did two things famously. One, I had a lot of direct reports and two, I did not do any scheduled one -on -ones because you can't have 120 direct reports into schedule one -on -ones because you're never doing anything but one -on -ones. So I said, I'm going to be around a lot because I don't have a lot of one -on -ones. So we can do unscheduled one -on -ones. And what that means is if you are blocked, actually there's a famous picture around it. I had this weird, like, cube desk where it was like a circle almost in the middle of the whole floor of engineers.

1:17:46And I was always there because I wasn't in a lot of meetings. And people kept there a block to just come up to me, right? The cool, actually, one cool thing about peer programming IRL is you can kind of look across and just see if it's working or not because if two people are intensely on the computer, it's working if one person's laying back or you're like, it's not working. So you could just walk up to them and be like, what's happening? But they would come and ask me questions and I could unlock them. Like, hey, we're blocked on this. We don't have this API. We need money for this machine, like, whatever.

1:18:12And so the unscheduled one -on -ones ended up being like a real clarifying thing for me because I did scheduled one -on -ones my whole career. And I realized after leaving Microsoft for three years, I'm like, we're all those one -on -ones useful, right? Once a week for three years, right? 151 -on -ones. So the unscheduled ones were though. I was like, when I knocked on my manager's door and said, I have this problem, those were important. So that's where I created an extreme. And the 120 direct just grew over time. I just didn't think I needed managers. I was like, let me unblock these people in another way.

1:18:40And we came up with other things to systems to unblock them that didn't require a manager. I just also had a good memory. I knew exactly everyone's skills and compensation. You all that off the top of my head. So that helps. The other thing that the thing that I broke was, actually, this is Jamath. He came in and became our biggest investors. And he actually, he's obviously a smart guy. But he said the right thing, which is not, this can never work because then I would go into defense mode and explain to him why it would work. He just said to me, I'm not gonna debate with you whether this works or not, but will it work at 400 people?

1:19:13And I said, probably not. He said, okay, so let's change it. And so we did then end up putting a little bit more of a structure, but I went to, I made a few people directors and I forced them to have 40 direct reports each. Like I said, we're just gonna make it still pretty flat. And then that did end up working because it still allowed them to be, use the system to unblock people versus like having to do a one -on -one every week or having to talk about things that potentially a system could unblock. And so I tried to figure out ways to system it as things. I love just another example of doing things differently, not necessarily just, here's how it's done.

1:19:50And I'm gonna do it that way and experimenting with it, even if you knew, like, okay, maybe long term this isn't the way it's gonna operate. Imagine it, Shopify, you're not, you know, 120 reports. No, we have the F14 or something, right? Like we do have like these guardrails where I think we say, hey, like an engineering, you should have between eight and like 20. There are definitely people who have more and people who have less. But we do try to keep things as flat as possible because we do believe that, like it doesn't make sense to have like three people and then it's somebody and then only have three people.

1:20:19So like it just make a very deep hierarchy. We actually do see, by the way, the farther you are from Toby, the like we can see things in like the survey results, like the alignment gets out of whack. And so you do actually see that you wanna be closer, you wanna have a flatter org in general. And that can be achieved by just having more direct reports per level. Make sense. Okay, final question before we get to our very exciting lightning round, we have this recurring segment that I call fail corner where generally people come on these podcasts to share all their successes. Here's all the things that I've done right.

1:20:54Here's all the big wins and everyone feels like, oh man, I wish I was always successful. Like these people went in reality. Everyone that comes on has failed many times. Is there a story of a failure in your career that you could share that helps people see that, even folks like you fail and maybe what you learned from that experience? I have a few. I'll say one thing by the way, because I think I read this in Tim Ferriss's book or in the podcast where he said, create a failure resume and write everything down. And I would not recommend doing this because I did this and I got super, I'm like a high energy happy guy.

1:21:22I wrote down, I have a note on my phone called Failure Resume and I wrote down all the times I failed and it is depressing. So I would not encourage people to do that. But I'm happy to tell you about a few instances. So, well one is actually I've been laid off twice and people would not expect like, oh, I'm doing this thing and I've been laid off twice and I think in both times it was the right thing. It was the right thing for the company, the right thing for me and I kind of use that experience as like a way to reevaluate and eventually came up with my framework of how I want to spend time. But that's maybe a different story.

1:21:53I'll tell you about one at Shopify. The first week that I started 2019, we were rebuilding our point of sale system, which now does like billions of dollars of GMB. But back then we were like, we're just rebuilding it with a new UX and a new technology platform. And it was my first week and I'm the mobile guy coming from Extreme Labs. They're like, should we build this in React Native? Or should we build this natively on mobile platforms? And so I went through this evaluation, it's got a lot of time, blah, blah, blah. And I came back with a hedged solution, which is kind of dumb. I said, let's do iOS and Swift and let's do Android and React Native.

1:22:30And the reason I said that was I said, I want to learn about React Native and I think Android's the harder platform. So let's build that in React Native. But iOS on Swift because that guarantees us a product in market and we didn't have any React Native apps in market at the time. A year later, we launched the iOS version and it was a huge success. And we then spent like another six months building the React Native version for Android and everything else. And we realized pretty quickly that React Native was the platform for the future. Like we're like, oh my God, this will allow us to have one platform.

1:23:01You could run it on the web as well and we could use the React engineers from the web to work on it. Like it was like a clear winner. And by then we had also lost a shot, launched a shot app which is React Native and so we learned a lot about this. And I went back and I said, hey everybody, I made a huge mistake. We just spent a year building this thing. It's in market, but we're gonna have to rewrite, we're gonna have to rebase back onto this iOS version. I think I burned 18 months of time with like a hundred engineers. Like literally from the decision I made in the first week would you want to Shopify?

1:23:31And Toby, when I went to Toby and I told him, I go, hey man, I think I made this mistake and we have to do this and it's gonna cost us like, you know, a hundred engineers and other six, whatever. And he looked at me and he goes, you should tell everyone this story. That's all he said. Not like, hey bad, good, like he goes, did you learn something? It was like a, it was an epiphany for me but he was like, this is a learning org. And I totally failed. I told everyone I failed and my mistake and everything else but he goes, just tell everyone because he goes, do you know what mistake you made? And first I was like, I don't think I, like what mistake he's like, you didn't take, he goes, I will always come down harshly on people who do not take risks and you did not take a risk in this case.

1:24:07But if you make a, if you take a risk and you, and it doesn't work out, you'll never get in trouble because you took the risk and it was the right risk to take but he goes, but you didn't take the risk. And so what I should have done, and by the way, even now thinking back it would be super hard to do. Firstly, it gives you a bite, right? Is like, take a risk on a platform that we have not launched in production app on but he was correct in that we should have because we were to save ourselves so much more time. And so, yeah, total failure. Sorry, the product is like super successful now and like we're all on React Native and even the shop green app is on React Native and everything's React Native and we're like core contributors, like it's all good.

1:24:42But I literally burned I think 18 months of time for 100 engineers as my first decision in the company. This might be the best example of failure corner we've had yet. This is a great example. Both of them actually are, although I'm wondering like, okay, that felt like a really good decision to me. And it's, it sounds like it, right? But it wouldn't have been his. But it's like, obviously you don't want to just take risks. There's like a limit of like a risk, but like, you know, informed, I guess is there anything you missed there that would told you this was the right path? Because you know, in hindsight, of course, we should have done this, but I looking back, what do you think you should have done other than we should have done the risky path?

1:25:19Yeah, I mean, one thing about my career as well, I don't really do anything halfway. And when I started looking into React Native, it was never just that I'm like, oh, let me look at the docs and like read and like build a thing. It's like, I flew to meta and met with the native, the React team. I became a core contributor. I ran the React Native working group. Like, we became release captains for React Native. Like, I knew that I was going to do all the things. So I'm like, and of course in React Native, you can also drop down to native and do things there that are not possible. So like, I think I hedged in correctly because I knew I was going to do all these things and I should have looked at my own thought process and say if I do all the things, can I fail?

1:25:55And I didn't take that into account because again, I did like five or six, like I literally, I put all of them together, I was running the group, I was like, release captain, like I would hang out with like the React team in meta, like I would be doing all the things. We became core contributors in React Native before we became core contributors in React because of all the things I was doing. And so I think just like knowing that I was going to go all out, I should have said, you know what, this is not going to fail. And I didn't have the confidence in that path. So I hedged, right? Hedging is the worst.

1:26:25And I remember the CTO at the time said, I'm wondering if I should force you to go react native. Like he literally said that. And I said, I will do, if you say that, I will do it. But they would have been his decision. And so he didn't do it. He didn't tell me to do it. Okay, that makes a lot more sense. It's so funny that Facebook had a similar mistake early on in their career. In team or five. Yeah, exactly. And I know, I don't know if you were at Zuck's interview at the Chase Center that acquired podcasted and he talked about this, where like their market cap dropped 80%, they were about to go public, they went to the SAP, no one thought they could do mobile ads.

1:26:58And he's like, that's that is back a year and a half, but he's like, but like based on all the pain he's gone through back, like since then, he's like, that was not too bad. Yeah, that's true. Actually, maybe what people don't know is, I was at Facebook. The like we were, Extreme Labs worked on the Facebook app and we worked on that app. I was in the office when we submitted the iOS app every single day that week because it kept crashing. And we had obviously direct access to people at Apple, but like we should put a new app on Monday and it crashed, should be not just us, but us Facebook together, it would just, and so I remember that whole HTML5 the asko from the inside.

1:27:35So I thought you would say you also told Facebook to decide on HTML5 and set them back a year. I did not. We just happened to be, we happened to be there when they were doing it. That's so funny. Amazing. Thank you for sharing that. Before we get to our very exciting lightener, is there anything else that you think would be valuable to leave listeners with, maybe you better touch on something you mentioned the last piece of negative wisdom or we just go straight to the round. Yeah, I mean, I'll say something maybe embarrassing for you. I've been, I've been using your performance management framework from, from your first round review article, not knowing by the way that it was you.

1:28:13Like I actually found it like you being like a famous Lenny podcaster, but the old days maybe the Lenny the PM. And I remember reading this a long time ago and just copying, there's a Google link in there to a Google doc link with a template for a performance review framework that I've been using for years. Literally every review I've done at Shopify uses that framework. And I was writing a post to my admin about how we can use LLMs to make it easier for me to write these reviews, even though obviously you have to read it all and go through it. But I was like, how can I generate some of this with an LLM?

1:28:48And so I wanted to center the original article. So I'm back to the first round review and found the article and said, oh my god, it's Lenny. Like the same guy. So I will say one thing that's interesting about that framework is I've used it now for, you know, like I said six years here, is that, and I don't think it's me. I think it's actually the framework pulls out good information. I've had multiple people in a review process tell me that when I deliver the feedback in the, of course, the format, they would say, wow, I've been an issue a long time. This is the best performance review I've ever had.

1:29:17And it's because the framework pulls out good information. So congrats to you. But I think it was funny that randomly I was coming up as podcasts and I just wrote that article to my, that doc to my admin like two, three weeks ago and realized the same person. Well, how about that? I love that. I will also give credit to a forebred guest on this podcast, Vlad Loktev, who was my manager at Airbnb and that's where I was inspired to write about that framework. So it trickles down to him. And I don't know where he learned this. He probably invented it. So credit to Vlad also for that. Another fun fact, along these lines, I have another first round repost about the W framework, which is a framework for planning.

1:29:55I'll do annual planning. And that's one that I've slowly discovered many, many companies use and they don't know where it came from. They just call it, oh, we have this W framework. Someone flip it and call it the M framework. But that's another one that is trickled into the ether of tech companies, which is awesome. Amazing. With that forehand, we have reached our very exciting lightning round. Okay, ready. I'm ready. Let's do this. What are two or three books that you have recommended most to other people? There's one. So Toby has an annoyingly long set of books that he recommends and they're all, like, not all.

1:30:29They're usually good. It depends because we're not in totally in sync on fiction, for example. But he recommended one to me that I think everyone should read right now called Mana. M -A -N -N -A from Marshall Brain. It is a book about, it's a book about AI. And I think the most interesting thing about it, though, is about a future in which the AI tells the humans what to do. So it's this idea of, like, imagine in the future you came into work and the AI would tell you what emails to pay attention to or what dashboard to look at because something weird is going on. It takes that to an interesting level, so I would recommend reading that book.

1:31:03It's not long. That's fun. I think another book that I recommend to people, and it's kind of a weird one to recommend, but it's business adventures from John Brooks, like the famous, if you ask, I think it's Bill Gates, what his famous book of all time is, it's this book. And the cool thing about the book is that it is not easy to digest for anyone with focus problems. Like, you know, Paul Graham wrote the post, how to do great work, and it's super long. The best part about that post is that you have to be able to read the whole thing. And so this thing with business adventures, I think each chapter is, it's 12 chapters, 12 stories, no breaks in between, it's just, each one is super long, but it just goes into a problem at such depth that if you can maintain your focus to get through the depths of each problem, you will just learn something, just like that post by Paul Graham.

1:31:50Like, I loved that it was so long, because I sent it to people and I said, the test here is, can you read it? Can you just get to the end? And not in a purge orative way, like if you can get to the end, like you will extract the alpha from this post if you can read it all. So I love, so those are, Mona is like the opposite. It's very, very easy and easy read. I'm excited to read these. Next question, do you have a favorite recent movie or TV show you really enjoyed? I read, a recent one was Challengers, the tennis movie with Zendai. I just randomly I was at home and I put it on and the cool thing about it was more the cinematography and music.

1:32:28They had this weird style, art house style where they would be talking and music would get like super loud, like it was very strange, but a very, very good movie. And then you saw you said movies and, or TV show. TV show. Like that. Yeah, one of my whole time favorites is probably Halt and Catch Fire. I don't know if you've watched that. Yeah, but the early tech. Early tech. Yeah, and like if you, I think there was an Andreessen podcast where he said, this is the closest thing to what a real startup looks like. So Halt and Catch Fire is like an all time like recommend, like everybody has to watch it.

1:32:59Yeah, a favorite product that you recently discovered that you really love. I don't know if I want to be like in the, in the zeitgeist right now, but like the meta -ray bands are amazing. And the biggest thing about the meta -ray bands was just that I think I never got into it. And I saw people around me wearing it, but I only got into it when somebody said, I'd never take my AirPods with me anymore. And I was like, oh, I can swap two devices for one device because I always have sunglasses and AirPods because you know, I'd go for a walk or a listen to a podcast. And now I can just have one device.

1:33:25And this happened to me. I was at a, you know, in the summer, I was at a pool party and someone called me. And I just took it from my sunglasses and people were confused. It's like where I was taking this call from. But they are the right amount of tech. Like they're in uninterusive, you can't tell. They don't look like any tech. And then I also, I was playing soccer with my kids. I had three kids. I just turned the video on. And I was the goalie and they were taking shots and I was watching them. They had no idea that I was just recording. And it was such a cool moment because I was in playing soccer with them.

1:33:50I wasn't with my phone. And they, I got to get this amazing set of video that I would never have gotten. So I really liked meta -ray bands. We had Baws on the podcast who leads a lot of that work and he's got a lot to teach us. And I put on Ray Bands while we were doing the interview. Just for fun, he could see my setup. I think I could. Two more questions. Do you have a favorite life motto that you find useful in work or in life? Okay, I do. And it's on like a lot of my profile, like Bios. And it is everything you know is wrong. And the reason I like that one, and people always like, what would you put on a billboard?

1:34:29Or like, and people always come back to me and say that's like, they know that as my motto. And the reason for that is, it's this notion of if all the knowledge you knew was incorrect, could you from first principles build up like a view of the world? And that's kind of how I like to think of things is that anything could be incorrect, even things that you think are correct, which is why again, back to the, I like to experiment, I like to look stupid because I'm always trying to shit because I'm like, I don't know if, even though you say this is correct, that this is gonna work, right? Actually, one example of my wife hates this is I have a Tesla and I routinely will switch gears without fully stopping the car, which you cannot do in a regular car, but like I'll be in drive and then I'll slow down to drive back up into my driveway.

1:35:11And while it's moving, I switch it into reverse. And like, you never would know that that's possible, except for trying it. Sometimes it goes, BBB because you're going too fast, but like, and she hates it. But I'm like, I'm always trying weird things. And so that's why I say everything you know is wrong. Like, who knows what's possible? Just try different things. I do the same thing with my Tesla. I used to do it with a non -electric car in my wife. I was always like, don't do that screwing it up. Yes, exactly. I love that I'm an electric car. There's no gear or braking. It's just software. Exactly.

1:35:41The school reminds me of that you shared of everything you know is wrong. The founders of Airbnb always talked about just this point that everything around you was designed by somebody, another human. There's not necessarily that much smarter or insightful. It doesn't mean what they did was correct. Somebody else went some better potentially. I think Steve Jobs had a similar thing. Like, hey, you can design anything. Like, everything's designed by people. I love that one too. Yeah. Final question. So you told me the story of this PhD you hired at versus just a guy who met in college, sorry, in a coffee shop.

1:36:11I read another similar story where you hired a waitress. Yes. Is that real? Okay. Tell me the story. Yeah, so again, this is another, this long list of reasons my wife is in order with me, but this is another one of them where whenever we are, whenever we are out, I'm always scanning. And I'm always scanning people and like, you know, one, like, do I know anybody around whatever, like to scan for people and have a good memory for faces. But in this case, we were at a restaurant and I saw a waitress doing a very, very good job. Like, I extremely, like, she was running between different tables. She was smiling her face, taking everyone's order, like, you know, making sure that there was a thing happening in the kitchen.

1:36:49She was kind of like doing a phenomenal job of organizing the entire crazy, busy restaurant. And so I'm talking to her. I said, what do you do outside of this? Because you look like you're super, she's like, what do you mean? I'm just the waitress. And I said, well, you would you like to, like, where, this is an extreme lab. I said, would you like to, you know, work an extreme lab? She's like, what's that? So I explained it to her and I got her, her contact info. She came into the office and she first started off as our receptionist. So she moved from like, you know, the retail world and the office world.

1:37:13And then I brought her on as my admin and she came one of my recruiters. And I taught her how to recruit and talk to people and she came in with me to info sessions. And over time, we actually hired many more people from the restaurant that were really, really good at their job. And what was amazing was one, she was organized, but not you organized, like she had to teach her Google Docs and G Suite and everything else, but she was super smart, but just never had the opportunity. The coolest thing about this is that she ended up being, she ended up taking over the HR, one of the HR functions for us.

1:37:41And she had a college degree and because of the work she had done with us, she was able to parlay that into finishing her, like doing one more year and getting a university degree. And now she's a director of HR at a company, which is amazing, like it was amazing from like, she went from that environment to this environment. And a lot of her people, she pulled the smart and intense people, she pulled from that environment, also ended up on these amazing career paths. And so I just like, if I see someone doing a good job, I'm like, what do they do that, how can I work with them? And this is a one example of like pulling somebody out of that environment.

1:38:14And I do have lots of other ones where I like, I overhear someone on their designer or an engineer and I try to hire them into my company as well. Wow, that is such a good story. I love that maybe this like restaurants are the new feeder system for tech companies did not think about that. Yeah, I mean, everyone's smart at something, right? So I was trying to figure out, she was really good at this thing, could she be so good at something else? Amazing, I feel like there's so many stories, more stories to tell, but we're gonna wrap it up and let you go for our on two final questions. Working folks find the online if they wanna reach out, learn more, maybe apply to work at Shopify.

1:38:47And how can listeners be useful to you? Sure, so Twitter is probably the place I try to hang out the most, X at FN Thour, and maybe I'll put that in the show notes. And then listeners for me, yeah, I mean, I love to be challenged. I'm sure that there are people who are like, they heard something that I said and they're like, oh, that's like super dumb, we do this instead. Or here's research that says that that won't work. I would love to hear more about these because I'm just again on a learning journey and I did something stupid, very likely. I would like to learn a better way to do things. So I would love for people to like comment and say, hey, this is dumb, you should try this.

1:39:20Or if that doesn't make any sense, I would love to learn more. So that's what I'm looking for. All right, well, leave a comment in YouTube or on the sub -stack post with what for Han got wrong. Amazing. Amazing, Han, thank you so much for being here. Thanks for having me. Bye everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or a leaving review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at Lenny'spodcast .com.

1:39:58See you in the next episode.