Architecting Teams that Scale

0:03 J'ai toujours rêvé de vivre dans une grande bibliothèque gratuite avec une accessibilité incroyable. C'est exactement ce qui se passe avec le web et surtout le code. Et ça, c'est les bienfaits de GITHUB. Et nous avons une chance exceptionnelle d'avoir le CTO de GITHUB, Jason Warner, qui va nous expliquer comment il a rendu scalable le modèle de GITHUB. Hey everybody, I'm Jason Warner. I'm the CTO at GITHUB. And as many have been doing in 2020, this keynote is pre-recorded. But I'll be with you live at the end of the session to answer a lot of questions. But today, in this session, I'll be talking about architect teams at scale. And I want to jump into a little bit of history about where this talk has come from. So right now, as I said, I'm the CTO at GITHUB. I've been here for about four years. Before that, I ran engineering and a portion of product for Heroku.

1:04 Before that, I ran engineering for Canonical, the people who make Ubuntu Linux. Over the last decade, my job has essentially been to take engineering teams and get them scaled, more efficient, better, just executing at a different pace and scale. And you can tell, too, my prime audience for customers was developers. And so all these lessons and all these things come from in those sorts of organizations. One of the main differences between this and maybe some of your lives is that these were San Francisco, Silicon Valley, VC-backed, high-growth startups. So a lot of the lessons are coming out of those sorts of moments. That said, a lot of this can be applicable to you too. So before we get too far, we need to define a couple of terms. What don't we mean by scale? Well, while I'm the CTO at GITHUB, I will not be talking about technology. This is not about monoliths. This is not about databases. This is not about Amazon, EC2, EKS, any of those sorts of things.

2:09 In fact, It's about something completely different. So what do we mean by scale? Well, we mean a very complex system, the human system. The organization that constructs a company is itself an engineered system. And I find them to be just as challenging to understand as the technical systems. In fact, many cases more challenging. And that's what we mean by scale. We mean we're going to talk about what it takes to build an organization of people who get things done from two people in a garage with a dog all the way to 5,000 people and what that means along the way. And why is that important? Well, it's incredibly important because this right here is what our day-to-day jobs feel like sometimes. Engineers, managers, architects, all of us inside organizations are constantly under barrage by too much information, too many feature requests, too many X's, Y's, and Z's, and not enough time.

3:14 And most of what we end up doing is having to say no, prioritizing and kind of shuffling things for later. And engineering managers in particular, I mean, folks like myself, but also executives, managers, directors, anybody who has to work with people on a regular basis and work through people to get work done, can't actually make it. It does actually feel like sometimes it's hurting cats. And I don't mean that in a derogatory sense. I mean that in a positive sense of the word. Cats are very autonomous. Cats are independent. Cats move about in ways that we sometimes joke about on the Internet, but they are incredibly intelligent, thoughtful creatures. But they sometimes look aimless. And our job as managers is to actually bring about a little bit more systemic order to the system. So as also you can probably tell by that, I am a cat person, not a dog person. And I do get a lot of guff about that. But that's a story for another day.

4:16 I would like you to suspend disbelief on one thing for me today. And here's what we're going to talk about here. So I have a friend, very good friend. He gave me this a long time ago. He said that there's two types of people in the world. There's poets and there's librarians. And you never want a poet doing a librarian's job and you never want a librarian doing a poet's job. And obviously on the spectrum of poet to librarian, everyone falls somewhere on that spectrum. And then obviously where you are relative to another person is also going to change. So to this friend who gave me this quote, I very much look like a librarian. But to most other CTOs in the Valley, I am one of the most extreme. poets in the world. So it's all context where you fall on the spectrum. But it's incredibly important that we think this way in the context of the spectrum of scale, because here is where it gets very dicey. There are no rules about how to scale organizations.

5:20 Two people in a garage with a dog look dramatically different than 10 people. And that looks dramatically different to 50 people. And then there are no rules about how you get from 50 to 500 and to 5,000. All the context will change dramatically in each one of those steps. And what worked for you with two people and a dog in a garage, will absolutely not work for you when it's 50 people. And all of those things will not work for you when it's 500, let alone 5,000 people. Some of them might, some of them won't. But here's the thing when it talks about the spectrum of scale, is that if you expect it to be this smooth ride along the way and for everything to kind of go smoothly and just kind of orderly add people to an organization and add context and shared vision, all of those sorts of things, and it to go incredibly smoothly, you're in for a rather rude awakening. So this is what we mean by the spectrum of scale today. It's how to go from two people in a garage.

6:21 And go all the way to 5,000 people. And I'm not going to give you rules, but I'm going to try to give you things that help make this easier. With that in mind, today I'm asking you all to be poets. I'm asking you to suspend disbelief about trying to buy an off-the-shelf book that says, now you've added the 13th person to your organization, now you need an HR ladder that does X, Y, or Z. None of those things are actually true. They help sell books or they help sell podcasts or whatever it be. But that's not what this is about. This is about the overall feeling, the overall meta, the overall everything that kind of inspires warmth and heart and everything else inside an organization. That's what today is about. And yes, I am still the CTO of GitHub when I'm saying these things. Before we get too far, I need to give you two caveat slides. One is the culture slide. We have to talk about culture. So this is not a culture talk, and I am known as a culture person. And so I say those two things in conjunction with each other.

7:23 But here's what I want to say about culture for today. One, you will end up with a culture. Whether you think you will end up with a culture or not, or you don't believe in the word culture, or you think it's overused, you will end up with a culture. The idea that you do not have autonomy over this, though, too, is one I want you to suspend disbelief on. You do. I think you need to be explicit about what kind of a culture you want to be. It may not exactly look like what you thought it was going to, but it'll be directionally correct. But we're not going to talk about that today. That's a presentation for another time. And then the actual caveat slide about technology. And while this is not a technical talk, what I want everyone to understand about technology is that no code, no piece of software, no technology actually has the right to life. It is there to serve us. All code, all technology, all systems are there for our purposes, not its. And if we let technology have its way with us, it will control our business and our organization.

8:29 And it will dictate more about your organization than almost anything else in the world. If you let your code get away from you and it's too hard to wrangle, you will construct your organization around your code. If you let your monolithic application become too hard to wield, all of a sudden your org decisions look very dependent upon who can act in which way inside your code base. This means that your organization is now out of your control. It's being dictated to you by terms that you no longer set. So when it comes to technology, what I want you to understand today is that you don't need to let your technology control you, but you will end up being controlled by your technology if you're not explicit about what it's supposed to do for you. And that's all I want to say about technology for today. We have about 30 minutes for this talk. So we are going to spend the vast majority of our time on what I call the boulders. And then the analogy about boulders, rocks, pebbles, and sand.

9:31 If you spend the majority of your time inside your organization on the boulders, you have a chance for success. If you have the luxury of doing boulders and rocks and pebbles and sand, you have a high likelihood of success. But if you don't do the boulders and you skip this to go to the rocks, pebbles and sand, you're as the classic saying goes, you're building a castle on sand. So we're going to talk about the boulders today. And what are the boulders? Well, here is what I think that all. organizations need, no matter the size, scale, or scope. But if you start with these when you're two people in a garage and you fully understand what they mean, you have a shot at scaling your organization from two people to 5,000. These are much harder, much harder to put in later. So if you start from the beginning, you're on really good footing. Now, these are hard-fought lessons on my part. I've never had the luxury of doing these from the beginning. In fact, the GITHUB turnaround story was when it was already about 850 people that I had put these things in.

10:33 And, you know, if you think about this at a scale of 5,000 people, I don't even want to imagine trying to do that. But let's talk about what these are. So these six things represent some of the most important concepts to scaling an organization. Again, this is not about technology. This won't be about when to bring in engineering ladders, and this won't be when to change the raise and bonus cycles to look a certain way. Those are all nice to have. Those will be in the sand category later when we talk about them. If you don't have these, none of those other things are going to matter. So let's start going down this list pretty quickly. Mission and vision. It's really simple. In the fullness of time, what are you supposed to be doing? Who are you supposed to be doing it for? And why do you even exist? Every employee in your organization should be able to tell you this. And in fact, it should be so obvious that at some point your company, if you have the good fortune to be as successful as you want to be, should enter what I call the zeitgeist moment. The entire world tells you what you're doing because it's just that obvious.

11:35 So think of it this way. If you can't say five years from now, we are going to be doing X, you're going to be a feature-led factory. You're just going to be chasing features that enterprise customers or your customers in the world tell you what to do because you won't have a very large vision and a very specific mission to go after. So write it down. Don't just put it in your head. Write it down. Make it so that everyone in the organization knows and can articulate it. And this should not be multiple pages. This should be a paragraph. This should be a couple of sentences. It's super obvious once you actually have success with this. Next, principles and practices. Here's how I distinguish between the two. Principles endure, practices serve for the principles. So principles are those that maybe between five and seven of them, they define who your organization is, how it's going to act, and what you're going to be from the ethos perspective. And practices are going to be those that help you achieve your principles in your current moment.

12:36 So as an example, maybe your principle is trust. Maybe one of the prime principles that you want to go after is customer trust. And two people in a garage, the practice that's going to be is hyper transparency because no organization is going to buy your software because they don't know if you're going to be here tomorrow. But at 150,000 people, you're going to keep trust, but it's going to be around. SOC 2, Type 2 compliance and audit reports and investor relations. And the principle or the practice by which you achieve that principle changes dramatically at your scale. So principles endure and practices will change with context. Again, write these down. I think the principles should be written down and the practices that you're orienting and optimizing for in that context for you should be very explicit with people. Otherwise, you will end up with half of the people thinking you're still two people in a garage, half the people thinking you're 5,000 and you're acting in accordingly. Third, context.

13:38 I cannot overemphasize context. I cannot. I don't think I could ever do it justice by just talking for hours on it. But the simple fact is when an engineer, a marketer, or a salesperson wakes up in the morning, they should know exactly what they're working on, why they're working on it, for who they're working on it for, and when it's due. They should not know the ticket, what is said in the ticket. They should know all the meta around it, the context around it. So this is where I see many, many senior leaders fail for what it's worth. And I mean, I don't mean fails and like, oh, no, we made a mistake. I mean, spectacularly fail. And this is the quintessential do what I say, not what I do kind of moment. They tell an organization what to go do. Go build that feature. That's. Practically useless. Go build X feature for the customer because they have a hard time doing Y with our software in the environment under which they need to operate.

14:42 And this is incredibly important for us because we're going after this market right now. Context matters. You want people to be able to make autonomous decisions because there are a thousand decisions that an engineer needs to make each week. You cannot answer every one of those questions. Context allows them to make those decisions. The main job of a leader in an organization is not to make every decision. It's not even to make the majority of decisions. It's actually to make as few of the decisions as possible. It's to make the only decisions that they can make for their level. So I like to say that I want to make the one or two decisions a year that only I can make. Every other decision should go to the person who is more appropriate to make it, and they delegate, and they continue to delegate, and they continue to delegate all the way down. This is impossible to do if you don't provide the context. Again, I cannot overemphasize this one. This is one that most founders will fail at spectacularly. And the type of founders that make it through this section are the ones that become public company founders and are able to become the public company CEOs that they admire so much.

15:50 If ever you see a founder who does not. Make it from two people in a garage to a public company CEO founder or something along those lines. This is in all likelihood where they failed. Moving on to expectations. This is rather straightforward, I hope, but if you can't say what you are about as an organization and what you are not about as an organization, you likely are in for some trouble. But it's very straightforward. Just have the conversation about expectations. I expect that we will deliver this in two weeks. I expect that this is going to be ready. In some form or fashion for our launch in three months. I expect that we will retain and promote the best people. I expect that we will go fast. I expect that we will have a higher quality bar. I have those expectation conversations at the highest level. Have these at the manager level. Have these at the team level. Talk about expectations. One of the common things I talk about quite a bit when it comes to just leadership in general is I don't ever really try to change someone's mind anymore.

16:56 I just don't think it's worth my time, nor do I think it's worth their time. Only somebody, only an individual can change their opinion about a situation. What I do instead have conversations about is expectations. So as an example, I'm not going to endlessly debate about technology decisions or strategy direction anymore. I think that at one point I would love to have those conversations, but you can have the discussion. But at some point I have to make a decision. So in that moment, what I will say is let's have that conversation. Great. I've decided my expectation is that you all either are on board with this or if you disagree, will help me validate or invalidate this at some point in the future. And then we will make another decision. But right now, this is our direction. I expect you are all on board with that. It's an expectation conversation. Not everyone has to be in consensus agreement conversation. Very, very different than how you operate. So measurables, again, kind of straightforward.

17:57 You can only get better at what you measure. I do not believe. for what it's worth in being a data-driven organization. I believe that's kind of a false statement to kind of fall into, nor do I believe in being an intuition-driven organization. And those are the two extremes, by the way. I believe that everything kind of falls in the middle. And where you orient is what kind of organization you're going to be. I'm a big fan of saying you're data-led or data-informed, one of the two. That's the real side of the spectrum that you're going to be on. And that will depend on if you have strong intuition about a market or if you don't. Data-led is when you don't have strong intuition. You need to understand how the market's going to evolve. Intuition-led or data-informed, sorry, is when you have strong intuition and you need to make sure that you are being validated along the way. So measure those things. That's for the business level. I do think that you should measure at the team level. I do think that you should measure at the individual level. But I don't mean like how many PR somebody submitted or anything like that. I just mean what is going on with our system? Is it healthy? Is it not healthy? We all know this about the production systems that we run, but you can do this at the organization level too.

19:03 Authenticity is my own personal add to this. I have found that over the last 20, 25 years of me doing this, the last 15 as an executive leader, that you get the best results when people think of you as a human and not as some executive autonomous robot who is here to make decisions and extract value out of shareholders. No one wants to come to work for people who are going to burn them out or any of those things. And no one wants to come to work for people who are going to burn them out or any of those things. to work for people who basically look at this as some sort of transactional situation. So I talk about this a lot as authenticity. And I try to show this in every interaction. But it's simple things that matter here. It's not going above and beyond and talking about my life story over and over again. No, I mean, I do do that when I'm coming new into an organization. I talk about who I am and what matters to me. But it's the simple things. You know, I've walked into meetings before when I had a massive headache in the morning. And I said, hey. You all are going to get a version of me that you don't see very often, but I got a really bad headache.

20:04 You're going to get a low energy version of me. And it's nothing that you're doing. I just don't have the capacity today to be that person all the time. And that's appreciated because people will sit there if I was a different version of myself that day and think, what is going on with Jason? What did I just mess up? What is happening here? So preempt that. Just be authentic about the situation that you're in. You know, when we were going through the GITHUB acquisition, I was really straightforward with folks. I said, I don't know what a lot of stuff means at the moment. I don't know what's going to happen with X, Y, or Z. I will work to find out, but I really don't know right now. Give me a couple of days. Give me a week. Let me go figure out some of those things. But even I have never done this before. So give me a little bit to figure this out. It goes a long way. You don't need to play act at this level. Everyone's an adult. We all pay taxes. We're all having kids. We're all doing adult things. Treat everyone like an adult and you yourself will get treated like an adult. So that's the set of the boulders.

21:05 I have a couple of things I want to add to the category of base level requirements for an organization, and then we'll get to the appendix slides. And all the pebbles, the rocks, pebbles, and sand will be in the appendix, and I think it's worth your time to go there. But I want to talk about some of the other things that I really, really think heavily influence organizations at scale. So let's talk about process. Everyone wants to talk about process. And I think that, you know, we've got to talk about about this here. One, don't overdo, don't ever overdo process. Overdone process, basically that's the definition of bureaucracy. Underdone process is chaos. But if you're gonna find yourself anywhere on the spectrum of underdone or overdone process, actually be a little bit underdone, just That's where I have found that the best work happens. You want to be as organized as possible, but slightly late to that. I'm not kidding about this. Overdone means that you're just going to tamp out creativity and everyone's going to be annoyed. This is a, my next one is actually a rather controversial one, but I do have, I've come to believe in this over the last 25 years, but I think there's one last must have inside an organization to become, to scale throughout the spectrum, as well as to become world-class.

22:20 And there's one last must have, and I do believe that you're going to need one world-class person. And you need really just one to make it to escape velocity, but you do need at least one. And many times people think that this is a founder. I believe that's a mistake. I don't think that the founder or founders should be in this category. In fact, I think if the founders or the investors or everyone thinks that that's the case, The founders themselves are not world class because they're not able to attract people better than them. That is a sign that they can't be world class people. So I really encourage people to think about this. as early as possible. Most of the great companies in the world when they were forming talk about one founding engineer, one early engineer who made all of the difference. And it's not uncommon to hear those stories in books by the founders. And if you think about, in my experience, this holds true. And I think as you scale, you have to start thinking about it as not for the company, but for the division or the team or the sub-organization.

23:29 So as an example, at Microsoft right now, if Microsoft only had one world-class organization, it wouldn't be a $1.5 trillion plus company. And I don't think along the way anyone would argue that Microsoft only ever had one and it was Bill. I think that everyone would talk about one or two engineers early on and 10 total engineers at some point in the late 90s. And if you think about it that way, what these are, if you understand what a strip mall in the United States looks like, a strip mall is an organization of all these, it's a vast track of land with a lot of. Stores and a lot of the stores in this have storefronts that lead outside. It's like the opposite of a mall where a mall is indoor. A strip mall is something that's outside. Well, there's this concept called anchor tenant and a strip mall is made or broken by which quote unquote anchor tenant you can get. If you can get a Home Depot or a Walmart or a big, a big big store, you basically increase the overall traffic to that strip mall.

24:30 increase the chances that this strip mall will succeed for the small stores. A world-class person is an organizational anchor tenant. And that's what you're after. You are trying to build around that person's expertise. Now, the one caveat here is that world-class person will define your organization. If it's very early and you are an engineering or product-led organization, you hire a world-class salesperson, very likely you'll become a salesperson. that organization overnight. That's what world-class people do. So don't assume that that won't happen. It's something you want to be careful about. So I still believe you need one very much. You should be intentional about it. And if you're a founder or a high-level executive of an organization, you should always, always be on the hunt for these people. They're incredibly rare. All right, so a couple of takeaways from all this together that I really want you all to kind of synthesize.

25:32 This is my favorite quote of all time about organizations. This is about life in general for me personally, but since we're talking about organizations, Eleanor Roosevelt put it best. Great minds discuss ideas, average minds discuss events, and small minds discuss people. And when you think about this at its root, think about this as your organization. What is your organization constantly discussing? Is it discussing ideas, events, or people? Simple as that. Just don't overcomplicate it. It's discussing people. You've got some work to do. But if it's constantly discussing ideas, Yeah, that's what you're after. You always want to be discussing ideas. You need to execute. You always need to execute. But the type of organization you're going to be from long term will be defined by something like this. Now you yourself have a job to do too. The culture of any organization is shaped by the worst behavior the leader is willing to tolerate. Wholeheartedly believe this. Hardly believe this. The job of leaders is basically to train the organization to make decisions while you are not in the room.

26:35 That is effectively what we're trying to do. We're trying to train the neural net, as one of my very good friends said, to make decisions that we might make while we were in the room, but when we're not in the room and when we're not available to make those decisions or when it's inappropriate. And one of the larger tools that you have to make or break that is what are you willing to tolerate? If you as a leader, if you really reward the brilliant asshole, as we've called them in our industry, people will tune to that. Okay, so for me to get my next promotion or to get recognized, I really need to do a great job and it's okay for me to become this really virulent person. No, you need to understand what you're doing when you reward people in a certain capacity. This cuts both ways too. So if you allow a person to be an underperformer, but they are the nicest person in the world and everybody loves them. That gets tuned inside the organization. Everybody starts to see that and understand that.

27:37 This is about shaping organizations and what they're supposed to be. So this is hard. This is one of the harder ones. We all understand that you can't reward abusive behavior. We all understand you can't reward certain types of things. But when it gets a little iffy, everyone relents and bends and they say, well, maybe just this one time. Well, it's never just that one time. Because that gets synthesized in the organization. And then it's, what about Mary? Or what about John? And then it becomes your organization. So in that, here's something I really encourage everyone to think about. If you're a leader inside an organization, you're building an organization and scaling it, you need to balance two modes. You need to balance being a sociologist and a psychologist. And it's very simple what this means. If you're a psychologist, you need to care after the individual. This is your job as a manager. You have a direct report. You have to understand their career ambitions, their pros, their strengths and their weaknesses, what they're supposed to be doing on a regular basis, and help them get better, help them achieve their objectives to some degree.

28:43 And also care after a lot of their career. And I don't mean like actively do a lot of the stuff that an individual might have to care for in their career, but you know, think about it and help them and coach them and all that sort of stuff. But you cannot make decisions based upon somebody's career ambitions while you're making decisions for the company. That is what you have to do as a sociologist. When you're an executive or a high level leader or even a team leader, you need to make decisions for the totality of the organization that you run, the whole. So when I'm in the GitHub exec room and I'm making a decision, I am not making a decision as the CTO. I'm not making a decision who has five direct reports that have different career ambitions. I'm not even thinking about myself as the technology leader. I am making a decision for the entirety of GitHub, the entirety of our customer base, the entirety of our customer base. of software around the world. I am literally not thinking about a single person inside my organization because if I do that, I'm failing at the greater job. And this is something I came to much too late in my career. I was much more team oriented and I still am very team oriented, but I was too team oriented early or too individually oriented, I should say, early.

29:53 And even as a team lead or even as a line manager, you have to balance this. Because your objective as a manager who has five direct reports, I mean, you don't have managers reporting to you, is you have to care after the entire team and the individuals in that. But you also have a job to do, which is the entire team's objective. You have to balance this. It's simply that the percentage of time that you spend in each one of these categories changes as the organization grows. If you're a founder with two people in a garage, you're doing psychologists and sociologists probably half the time. But if you're 5,000 people and you're a founder and you're doing anything that looks like sociologists less than 99% of the time, you're probably not doing the job correctly. This is something from GITHUB's time. I just think this, for me, this resonates when I think about focus. As you grow and as you scale, your eyes get wide, your stomach, you know, the eyes are bigger than the stomach type of scenario. You think you can bite off more than you can chew?

30:53 No. Assume you always have less. Focus, focus, focus. And the reason why I say this is that sprawl happens naturally and things will get mediocre as you sprawl. So what I said earlier about process, you want a little bit less process. That is true. You also want a little bit more focus at all times. Always try for just a little bit less. And it's incredibly important that you think about this overall when it comes to human systems. So anytime you add a new ladder, a new level to your HR ladders, what does staff level engineer seven mean when you? have staff level engineer one and two and three and four and five and six and seven. Well, all of a sudden, at some point, it was way before you got to seven, that staff level engineer no longer meant that much. But staff level engineer seven definitely does not mean anything more than staff level engineer six. You've just completely diluted that level. You've got to understand what you're actually doing inside your organization when you do this. So this is my last time I'll mention culture in this slide, the second to last time.

32:02 What we do and how we do it is actually my definition of culture. It's as simple as that. So here's what I mean by culture. Your culture is defined by the worst behavior, as I mentioned before in that quote. But it's really also going to be about achieving objectives. That's the balance in that quote. The balance is the worst behavior could be underperformance or the worst behavior can be abuse or the worst behavior can be whatever. So what we do and how we do it is mind distillation in this. They're two sides of the same coin. So you can say we're going to run as fast as possible and achieve all of these objectives and get all of the short term value out of the stock market that we can. And we're going to burn all of our people out and maybe one or two of them are going to get divorced or have wrecked their lives to do this. You've just defined what type of organization you are because of what you're going to do and how you're going to do it. So understanding that the balance of what and how is what your culture will become. This is the most important thing. I'm not judging. anyone when I'm saying this either. I'm saying be explicit, which leads me to my next point.

33:05 Be explicit in what you were going to be. Again, not judging anybody in this one, but if you're not explicit, you don't have a chance of success. It'll just happen to you. But if you are explicit, it allows other people to also opt into your organization. If you're two people in a garage, you're not explicit that you are going to become a mercenary organization. You've just kind of pulled the rug out of people. At some point, you're going to have to have a very difficult conversation when you have to let people go or transition them out. However, if you are explicit incredibly early on, there are actually people in the world who love to work for mercenary organizations and do not care about some of the softer creature comfort things. Just be explicit about it. Again, I'm not judging anyone. I'm just trying to inform leaders on how they should operate. And this actually goes counter to what a lot of Silicon Valley is talking about these days, where they talk about becoming a little bit softer on organizations. I don't actually think that's true. Look at Tesla. Tesla is not a soft organization, and she's outsized results. I also will never work for Elon. I think he's a horrible manager. And as a high-level leader, I will never report to Elon.

34:07 I think he's an atrocious manager. But there's a bunch of people who are in positions like mine who would love to work for him. I'm not going to judge him. He achieved some amazing things. Just not for me. I'm glad I know what it's about so I can opt out. So explicit also reminds me of one other thing too. This is where technology can ruin you. I really encourage people to think that You want to do things on your time horizon. And the more explicit you are, the more chances you have to do it on your time horizon. Imagine that your technology is holding you back. At some point, you have to respond to that technology. But you no longer have a luxury of time or forethought. You're required to do it because you're down in production and every customer can no longer access you. You do not any longer control your destiny. Your technology controls it for you. This is why you need to be explicit. This is why you do need to get in front of it. of certain things. What I call this is doing this when you want to, not when you need to. If you're 99% of the way towards destruction, you've already lost.

35:08 But if you're only 75% of the way, you have room to maneuver. Think about that on a regular basis. What are you, what's a, what is a small fire that if paid, not paid attention to becomes a large fire? Time to put out the small fire if it has a chance of becoming a large fire. What's a small fire that will only ever continue to be a small fire or maybe burn out on its own? Maybe you don't. But do it when you want to, not when you need to. Last couple of things that I think I've learned in the last couple of years that I might have changed my opinion on. This is probably the one that I've changed my opinion on the most from early in my career. I absolutely believe that constraints are good. I believe constraints are incredibly good when they're date driven. I'm not the type of person that when I want my own software project, I would love to be day driven. That is just not the way I'm built. But I think from an organizational perspective, they're actually quite good. And the reason why they're good from an organizational perspective is twofold. One, they're common.

36:10 Everybody, no one has to figure out process of another organization or another division. So everyone is playing on the same level playing field there from an organization perspective. It's also a common construct, the calendar. But two, it's a level playing field with the world. Time is literally the only thing that doesn't change between me and your competitors. Stripe, look at Stripe, one of the best executing startups in the world. Stripe is executing at a different level, but they are bound by the same seven days a week, 24 hours in a day that everyone else in the world has. They do not have any advantages in that. So if you're not date driven, I don't think that you can compete anymore. I think you have to understand that the dates help you by orienting yourself around something that is the same physical constraint that everyone else in the world has. Then you optimize everything inside. that process. You optimize everything inside your organization around that. They want immutable law, so don't try to bend the immutable law.

37:13 We've learned that many times in our lives about physics. The last two before we end this presentation are going to be pretty simple. This is something I very much believe every leader and every person in the world should actually do, but every leader absolutely. The best leaders are the ones that do this, but honest introspection is the best superpower for everyone. If you're a leader, you should be reflecting every day on what you did well that day and what you can improve upon, what your organization needs out of you and how you're going to do that better. The best leaders are the ones who have done this. The worst leaders are the ones who think that their organization is the one that got a lot of things wrong. It's quite simple. And the last one, probably my most important one, and I have an entire talk on this one, but reputations last longer than roles. So as a leader, as an engineer, as in anything, your job is actually to do your job, but while maintaining and building your reputation. Because if you can achieve that, if you can achieve the job done while your reputation increases or at least maintains, then you've done yourself an amazing service.

38:22 Everything else after that kind of knocks on. Think about it this way. If you did your job and you burned everyone out, your reputation takes a hit. So you short-term gain, long-term loss. But if you did your job, you found a way. to do your job where you achieved your outsized results in the moment and your reputation increased, that is actually the goal. It's the goal of every organization. It's the goal of every person. It's the goal of every outcome. Think of it that way. This is, again, this is one of my probably more important points, and I have a talk on that that we can give later. But that's it. That's the boulders. I went over my time a little bit. Architecting teams at scale. This is me on GITHUB. This is me on Twitter. You can come and ask me questions in my AMA on GITHUB. And past this is the appendix where you have the rocks, pebbles, and sand, where we will learn about what things to add, things to remove, things to worry about, things to ignore. But that's talk for another time, and I'll be back here to answer some questions.

39:23 So that's it. Thank you all. Thank you for your time. And as a reminder, I'll be here live to answer some questions at the end. So stick around and see me in the exact same hoodie.