The revised rules of engineering management with Will Larson

How has engineering management changed in the last few years? Will Larson is one of the best people to talk about this. He's been an engineering executive for the last 10 years at 4 different companies, wrote some of the most widely read books on engineering leadership and staff plus levels, and I really appreciate how deep and thoughtful of a thinker he is. Today we cover, how zero interest rates heavily influenced a decade of management habits in the 2010s, many of these habits no longer helpful. How the role of engineers is changing, and why solving problems that the business cares about is becoming much more important to thrive inside of companies. The path to becoming a CTO today, and why line managers often make better engineering executives than middle managers do. And many more. If you're an engineer or engineering manager and are wondering what your career path could look like with AI changing the industry, and how the path to CTO looks like today, this episode is for you. This episode is presented by TurboBuffer, a ridiculously scalable, fast and cheap hybrid search engine built on top of object storage by an engineering team that I've really grown to like after spending time with them. The TurboBuffer engineering team is doing something really cool, they are completely redesigning their storage architecture from first principles to make search faster, cheaper and more reliable at scale. The new system, called TurboBuffer v3, is not yet in prod, but it already passes CI. Still, it's not nearly as performant as the current production version, v2, and so the T-Buff team is now perf-maxing query plans until they are as fast or faster than v2. They're doing all of this in public, documenting how they increased performance all the way up to the v3 production launch. And it's so cool to follow along and see the different performance wins and how they did it. For example, we see how full-text search, the red line, started out as 129 times slower than the current system, but now it's only 4 times slower. And in the development log, we can also see that the team used things like batch scoring or batch reads to increase performance. A lot of these wins are basic foundational work right now, but the team will be sharing some very cool systems work over the next few weeks. But hang on, why is the team doing a full rewrite? It's because search is changing, and so is TurboBuffer. T-Buffer started as a vector database, but it's no longer VectorDB. It has evolved into a high-performance database for search. The v3 discards the vector primary index, and all indexes will share the same columnar source system. Every query will run on vectorized query engines, which is something you don't usually see in search databases, but which will result in both very fast search and just generally a very fast database. The TurboBuffer team is keeping a work log of their journey, and you can follow along at TurboBuffer.com.v3. It's a blast to see how it's being built. Will, welcome to the podcast. Thank you for having me. Excited to be here. Finally chat in person. Finally in person, because we've known each other for so long. Both started writing. We will talk about that writing as well, and also just hung out before, but this is nice. I want to jump into the beginning. How did you get interested in computers? Were you interested in computers to start with? From the time I was five, we had like a Mac 2C or something like that. This was like a, not, not black and white, not the very earliest one, but it was pretty basic and I think it had like one thing that I understood how to use as a four and a half or five year old, which was like KidPix, which you've maybe, I don't, did you ever use see KidPix? I didn't. I know of it, but I never used it. It wasn't like a super sophisticated thing. I don't even know if you could save files, but it was basically like a graphical program for children and you could make squares and circles and little like graphics. But that was kind of the introduction to me. And I remember using that computer a lot and that this is an era ones are really no internet to speak of, really no way to figure out how to do anything other than just banging on it, which is sort of the fundamental of writing software in some ways is just banging until you figure out how to make it work. I think that was a great introduction, but to be honest, I wasn't doing a whole lot in like software other than, you know, multi-user dungeons. Did you ever like play a mud growing up? Multi-user dungeon? What's a, no, what's a mud? It's a text-based game. And so basically the idea is that World of Warcraft is actually a graphical text-based game. We basically derive from these ideas of muds or multi-user dungeons. But when I was a kid in high school, that's when I started doing more software. So a little bit, you start with IRC, Internet Relay Chat, and Merc, which I don't even know what the M stood for, to be totally honest. But as a client, you could do a little bit of scripting with regexes, but then a lot of the mud clients as a kid could do a ton of triggers, regexes, and that's where I got a little bit further into it, learned my regexes there. But really I didn't start writing software at all until I got to college. And then at college, what did you start writing? How did you get into a more serious level? So I came into college not really knowing what I wanted to study. And I thought I might do physics or English or economics. My father was a professor of economics, so there's some family lineage to try to live up to. But ultimately I kind of fell into computer science at my school, which was a small kind of private school in Kentucky. There were, I think, 13 people in the computer science program the year that I graduated. And that was the entire program. So I think there were four graduates my year, and then like the juniors and sophomores in total were like 13. And so it was quite small. So I think there were four that graduated my year, but yeah, but really that was when I got into it. And why? I just enjoyed, had an intro course that we were required to take. And it's kind of funny with a lot of American colleges, especially smaller private ones, they have random kind of requirements. So I was required to take a introduction to Christianity course, like at the history of Christianity, but also required to take like an introduction to computer science or some other course. I forget what the other alternative was. So I really enjoyed the computer science one. Did you decide that you were probably going to be a professional software developer, engineer, programmer, whatever we call it back then? So I think one of the interesting things when you talk a lot about careers is like a lot of folks go to like elite schools. So you talk to someone from Waterloo and they go, how did you get your job? They're like, well, literally everyone at Waterloo is coached on how to go do software. They're literally trading the answers to interviews with each other. So they know the interviews and drill on the interviews before they go in. They also like amazing program. They've been doing co-ops for years. Like they're great. They're great candidates. They tend to do really well. But go to Waterloo, you go to MIT, you go to Stanford, you really, there's like this path and you just kind of put your foot on it and you do well and it carries you there. And these are amazing students. It's like an escalator almost. But it is an escalator. If they're good enough to stay in the program, they tend to kind of get there. Coming to a small school with, again, like four-ish folks that graduated my year in computer science, there really was no path. I remember one of the folks that graduated the year before that was working in software, he went to go work on a horse racing betting software company in Lexington, Kentucky, which I don't think there were more than like five engineers there. And this was like a really talented, really capable person. And this is kind of what they knew how to find. And so for me, it actually was interesting. I wasn't quite sure what I was going to do. I actually ended up teaching English in Japan on the JET program, the Japanese exchange teaching program. And so I was in the middle of nowhere in Japan in the Gifu prefecture for a year. But that's when I really started writing a lot. So I was like, hey, I'm definitely not going to be an English teacher for more than one year. It's a one-year contract. I did that one year. I had no thoughts about doing a second year. And I came back and started trying to figure out how to actually break into Silicon Valley from there. And you had the goal, breaking Silicon Valley already. Why Silicon Valley? Can you take us back to what Silicon Valley was like back then? First of the time, I didn't know what Silicon Valley was, right? Perspective of that moment, like we were actually creating the discoverability and the conversation around it. This was before Twitter. This was before Facebook got, like, substantial distribution. This was really early moment. And so for us, like, that was the core of where people came into. Also, it was really where we sold the most ads. And so losing that traffic was basically tanking the company's, like, financial kind of prospects. And so Digg before, from the outside, Digg was working pretty well. It was, you know, seemed like maybe it was growing. But really, like, what we knew is, like, Digg was shrinking. We had one beautiful month of profitability, and then an algorithm change hit, and we started shrinking. And we knew that this is existential for us. We were going to simply not exist not that far down the path. And we were, when I joined, I want to say, like, 110, 120 people, something like this. But this was in, you know, 2010 when funding rounds were a million dollars or three million dollars or something. It's not like today when people are raising, you know, 500 million dollars and you can have a team of however many. It was a very different moment. So even with 110 people, that was pretty substantial when we were running down the remaining coffers pretty fast. The launch internally, did it go poorly? Did it go well? Because from the outside, again, there was a perception that it went terribly, and people—there was a bit, I think a lot of it was the community was upset. And then there was a bit of celebration as well, like, well, Digg messed it up. Like, they kind of deserved it. You know, the mob, the people especially who were very involved, they didn't like change. First, there's, like, a really fascinating set of cartoons someone made, which is, like, Digg versus Reddit, and, like, Digg is, like, blue, and then, like, Reddit's red, and there's this, like, giant war that someone did, like, a four- or five-part. It's, like, this very intricate— Comic someone wrote around this time, and it's kind of interesting to see how much energy people put into it. But yeah, there was a lot of passion, and I think this is one of the challenges of, like, a really passionate community, is, like, when you foster a passionate community, then you change what you are, community doesn't like that. Because, I mean, there were literally these folks, like Mr. Baby Man was, like, a really big one, like one of the top Dig kind of curators, unsolicited curators of content getting to the front page. And he, you know, he and many others were—they lost kind of their business, right? But the launch went pretty poorly. And why did it go poorly? It went poorly for a lot of reasons. So first, the launch technically wasn't really ready. And so we made a lot of really aggressive technology decisions. And again, I came in about three months before this went live, so I don't personally take a ton of responsibility. I also, again, thinking about where I was in my career, I was basically—this was my second job. I'd been at Yahoo for two years, so I won't own this one. Later in my career, I'll own anything that happened, but this one wasn't really my fault. But basically, we made the decision to launch on Cassandra, and there's, like, a joke at the time, which is that Cassandra was a Trojan horse Facebook had launched to basically ruin competition in the industry, because anyone who launched on Cassandra was basically screwed afterwards, which I think certainly was true for Dig. And so running Cassandra replaced the sharded MySQL system. The sharded MySQL system was pretty complicated, but it definitely worked. And Cassandra, I would argue, like, basically didn't work. But I remember there was a team responsible for load testing Cassandra before our launch. And two days before the launch, this other guy, Rich, who was fantastic, he and I were pulled aside and were like, Hey, well, they never did the load testing. We need the two of you to do the load testing in the next two days. And so Rich was just like a software engineer like me. And so we're like, well, I guess we'll install JMeter and try to figure out how JMeter works to do some load testing. And we had this, like, really interesting conversation with Chris, who's kind of the head of the Cassandra initiative. He's like, Hey, like, I can't do the reads on Cassandra. He's like, That's not true. I was like, Well, I can't do the writes. He's like, That's also not true. I'm like, Okay, Chris, if I'm writing to Cassandra, I can't read from Cassandra. If I'm reading from Cassandra, I can't write to Cassandra. He's like, That is true. It's like, We're supposed to launch in two days. And then we launched, and we didn't fix it. We just launched. And so I think the company thought that we were literally dying. And the company was—the company literally was dying. It was running out of money. But it was, like, the most interesting day I've ever had professionally. Can't remember when I got to the office, probably around 8 a.m. When you say interesting, you mean stressful? You can judge. Let me, like, paint the scene a little bit. So it was a launch, but they also decided to have a launch party. So the entire day there were caterers kind of in tuxedos with, like, sushi trays, champagne. Oh, wow. And so, like, the entire office was there to have this, like, kind of, like, celebration. And then in the center of the room there was this, like, table. This might have been, like, a boardroom table or something. It had been pulled out, this giant table, maybe three or four times the size of this, where the engineers were sitting. And we didn't have enough hardware to run the new system and the old system concurrently. And again, this was hardware we owned. So they were literally wiping the old servers and installing the new software. So we couldn't roll back. We didn't have the money to—or the—and because, again, we were running out of money. Enough budget for the party, but, like, not enough budget for the servers, right? So we were wiping server by server, spinning it up, and ultimately, like, the damn thing didn't turn on. It was functionally what happened, right? And so we had this, you know, like down for maintenance page up for I think roughly 24 hours. And then we were able to scrap it while the champagne and the tuxedos are coming around. Surreal. And there were people upstairs getting massages. There were, you know, I remember certain groups who won't be named playing ping pong while we were trying to get this up. And it was just like, it was sort of like a magical realism. I see what you mean by interesting. This is not how I imagined a launch like this. You could never imagine a launch like this. It was just, it was so surreal, truly like a magical realism moment where there's kind of all this normalcy happening while this site's literally imploding. And it was just, it was unlike anything I've seen. But it's also like a moment I take a lot of pride in. And so I'd been there three months. I think interesting thing is we did get the site kind of working, but there were a lot of issues. And so people just gave up. And like day by day, like people just stopped showing up. And like the small group was really the only group left of maybe like six people trying to keep it working. And we did. And so we, in the first two days, like the same guy, Rich and I wrote like a caching system from scratch on top of Redis, which helped the site stay on for hours. Yeah. But we still had huge memory leaks. And so we're actually like restarting every process every, you know, like hour or two. And the only way to keep it up was rolling restarts of every process. And so it took us, it took us like a full month to debug. And I have like a blog post I wrote a long time ago about it. But basically the core bug was we created an API service that could be used for like third parties, and it was in Python. The people writing it didn't know Python very well. And this was Python then calling like another Python gRPC, those hitting Cassandra. And basically in Python, when you instantiate a default parameter, if it's mutable, I don't know if this is still true, by the way. I hope it's not so true. But at the time it was true, where if you basically put a list as a default parameter and then you mutated it, like appended IDs into it, it would persist in memory. And so each time that function was called, it would have the same. I don't know if that was me or someone else in the batch. But I think by the time I left, it was 1.5 to 2,000 folks, something of the company. So Stripe grew about 70% year over year the period that I was there, which is a lot less than Uber, which doubled every six months. And obviously, like, Uber subsequently contracted much more aggressively than Stripe ever did, which is the natural consequence of doubling every six months. But at that point, I was just worried that, like, my entire kind of, like, savings were all in one company that was never going to go public, which I think has been true. And so it was, like, a bit of a diversification play, but also the desire to what does it actually feel like to fully lead. And so for my entire time at Stripe, I was basically, you know, one step away from the CEO, reporting into Jeff Weiner for my first year, then into David Singleton, who was my manager for the rest of the— Oh, Stripe's CTO later, or maybe at that time as well. He joined as the CTO. No, that's not true. He joined as the head of engineering, and then he became the CTO maybe a year or two later, something like that. But I was reporting to him from when he joined through the time I departed in early 2020. So I was only one step away, but I was like, what if I could get into that seat? Could I do things some better? And that seemed like the right thing to try for anyway, and has been educational ever since. And then you have had several CTO gigs then. So it was Calm, three and a half years CTO, then you were at Carta. So I was at Calm for, I think, three and a half years, then I was at Carta for two years, and then I joined Imprint a year, year and a half ago, something like that, which is where I am today. Okay, so now three times CTO, I need to ask you, what does a CTO do? As an engineer, like, if you put yourself back as being an engineer, of course, I think— I myself had aspirations when I was an engineer, like, oh, it could be nice to one day be a CTO because in your mind, it's like, well, it has some management, but it's also a lot of CTOs you see are technical and close to the thing. How do you find the CTO? I know you have a book on this as well on engineering executive careers, and there's a lot of answers, but what is your mental model? How was it, and how is it now, especially because now with AI, I think your role has changed. I think one of the worst parts of being an engineering manager in the 2010s is, I think, like when you joined the ranks of engineering management, like one of the first lessons you'd get is like, hey, you need to never make a technical decision again. That's how it used to be, right? I remember that is, that's like literally, you know, what I was told. And I think you'd see people, like the most important thing is to let go about technology decisions. And this was the ethos then, and that's definitely not the ethos today. But I think the thing that I kind of aspiration really loved is the CTO was like the only place where this, like, engineering kind of career, this technical-oriented one and this managerial one converged. And so one of the things I've believed strongly in and continue to do today is having both engineering managers, but also, like, individual contributor engineers report directly into me in the CTO roles. And so today I have 14 direct reports right now, and I think four or five of them are ICs, and then the rest are our managers. But having that balance is, like, really for many roles in management, you're just not allowed to be a technical leader, or you weren't for a long time. And so to me, actually getting to the level where they converged again and you were allowed to be a leader on the technology and the management side was, like, one of the big appeals. But also, there's so many, like, bad CTO decisions out there, and I don't mean this to reflect on any of the individuals I've talked about. I think David in particular was, like, really excellent, and the decisions at Stripe were generally decision quality at Stripe was pretty high. And so sometimes you could be like, I disagree, but you couldn't be like, This makes literally no sense. But often, like, you know, especially outside of the Stripe experience, there were just decisions that, like, just didn't make sense. And I thought, like, maybe I could do it better. But I think the thing that I've really loved in the most recent kind of era is, like, you're really, like, not just allowed to be in the details again, like you're really sort of required to be. And that to me has been, like, the very most fun part of being back in software in this era, is I think I, you know, I've done over 500 pull requests in a year and a half at Imprint, going all the way to production, which is substantially more than I did in my prior career combined. And that's pretty cool. And then you just Imprint, that's CTO, or are you more than CTO at Imprint? So I joined as the CTO, and right now I'm also kind of leading the product design teams. So product design and engineering all reporting into one person. Yeah, it's like a unified EPD structure. Is this a new trend, one person? Because CTPO, I started to hear about two years ago, Chief Technology and Product Officer, two, three years ago, and now I'm starting to hear design also going into one person a little bit. I don't know if it's a trend or not. I do think that for one challenge I've been seeing with, like, agents kind of getting more mainstream is you actually have to be able to make decisions and make them quickly. And how do we do things? How do we not do things? How does agent adoption work for product? How does it work for design? Hey, design, if they aren't using the, you know, new tools like Claude Design or the Figma MCP or whatnot, then they're really the bottleneck. How do you kind of split the responsibility there on who owns design now? And so Imprint, for example, has been experimenting with this developer-led design model for kind of second-tier features, and it's created a ton of friction. Like, it's solved this bottleneck. It's also created a lot of, like, who's responsible for these design gaps that show up when engineers do lead design and sometimes, like, don't follow the design system properly. And so having a unified kind of point that can actually make these trade-offs, I think this moment of, like, immense change, I think is pretty powerful. I do think just in my core, I believe the industry is changing more in terms of how we create software than it ever has in my career. And, you know, I started in, you know, late 2008. I've never seen a change like this. A lot of the changes I've seen were more subtle, were more kind of cultural or social. Just how I create software is really different than it was even a year ago. And having a centralized kind of mechanism during this moment of immense change, I think has been really helpful for us. But I don't personally think it's, like, a long-term trend, but I don't know. I'm trying to avoid predictions about too deep in the future at this point. Everything is changing a lot. Will just said how he's never seen the way we build software change this much in his whole career. One thing that is changing is the fact that we use GitHub hosting, which brings us nicely to our season sponsor, Entyre. GitHub hosting has a problem that starts with AI and ends with agents. Engineers like you or me are creating more code with agents. Those agents are pushing even more code, and many of us are running parallel agents, which results in even more code. GitHub is clearly struggling to keep up and has frequent outages. But there's a solution. Entyre was founded by GitHub's last CEO, Thomas Dumke, to rebuild GitHub hosting for the agentic era from scratch. Entyre was built to be very fast and to have your repos regional close to you to reduce latency, allowing for fleets of agents to push in parallel. And Entyre's performance is next level. Their repo can handle 418 pushes per second, which is up to 89 times faster than every competitor on the market. When GitHub is down, you can still keep working, and you don't even need to migrate away from GitHub. You just sign up to Entyre and the platform mirrors your repo. Also, have you ever wondered what prompt resulted in this code being generated? I find that the prompt and the conversation with the agent carries more information than the PR itself. Entyre captures And I think many of them at the time felt like that was a violation of the management contract. Like my goal, my obligation was to give them interesting work they wanted. Oh, interesting how when we look back, just how it changed from like 10 years before. Totally, right? And so I think that that was like a fascinating time to be in. But I don't think that perspective was ever really right. If you look at the people who were really senior at Stripe, but also everywhere I've worked, those folks were doing the really valuable work that the company needed. You never saw that perspective like really take hold in the executive ranks. But a lot of the folks coming in really had that belief. And I'd say, like, without naming names, certain companies that they came from had very strong versions of that, where kind of the obligation of the manager for senior hires was to give them fun work. And I think the industry's really reverted on that one for sure. Was this something to do with zero interest rates? We often come back to this, which is so curious. I wrote about this as well, how an interest rate, which feels so abstract and we sometimes hear about it, how it probably impacted funding in tech for a very long time, probably hiring startups, startups that were funded that maybe didn't have a business model, but they were still funded. And ultimately software engineering archetypes, manager types, management decisions. And then the music stopped sometime around 2022, where efficiency became more important. And now we're kind of seeing this. And now I think a lot of us are asking, and I'm also asking myself the question, like, everything that we did during that time, was it right at the time? Did you ever read, I'm going to get his name wrong, but I think it was like Ranjan Roy's, like, ZIRP explains everything blog post from The Margins? Yes, The Margins. We'll also link that. I love his writing, yes. One of my colleagues at Digg, who then I hired at Uber, was John Durrick, who is the other writer on The Margins, along with, I think it's Ranjan Roy. But so I read that piece. And it really resonated, right? I do think that Zirp has explained the entire, like, 2010s in terms of how management styles changed. Salaries went up. Then competition for hiring became your ability to hire and close and retain became the differentiator between these, like, successful companies, the less successful, because you simply couldn't retain great people. And that, like, pulled kind of leverage back into the engineers' hands and created, like, a very different environment. And so part of the way companies were pitching themselves was like, more relaxed, more focused on you, more career development. And I think in ways that I think were often, like, kind of self-defeating. So I think there's this kind of, like, broad judgment of, like, the Google perk culture. And I don't think any company that did incredibly well, other than maybe Google and Meta, had that level of perk orientation. But I do think ignoring the perks, there are many other ways that companies try to focus on rewarding work, interesting work. You know, companies like, oh, engineers maybe shouldn't be on call. That's, like, the second-tier SREs to be on call, which was interesting because that was actually a place where every single person I've worked with knows engineers being on call for the work makes the software better. And yet companies were still kind of like, oh, maybe for the enjoyment of it, we should let folks not be on call for the work they're doing and instead page other people that aren't involved in the creation of the software. And that orientation really reveals, I think, the shift in priorities in those companies. Well, I also wonder if that was a time where— Managers were rewarded for having low attrition, meaning few people left, being able to hire on the team to fill headcount. Because often there was a time, this might sound crazy, but filling headcount was difficult. You were given, let's say you had a team of 30 as a director or senior engineering manager. You had 10 headcount this year, and if you couldn't fill that, meaning you couldn't hire the right people, and this was like, let's say senior and above, so it was like you couldn't just get new grads because that would be too easy, then it kind of counted a little against you. Or someone else would get that headcount, which might help their promotion because it was kind of obvious if you have 40-plus people, you might be senior manager, that's your director title. And so managers who did well in this environment became a bit of people pleasers. And also they started to shield their engineers from the business, for example. And I wonder if this shielding from the business has bitten back a lot of people because now, as engineers, you're increasingly expected to be savvy about the business, understand the business. That's when you're going to be in demand. That's when in a startup or other places you get to hit the ground running. And I still hear stories from people who worked at this big company, let's say a big observability company, any of them, and they went to a startup, a 7% startup, and they say, It's terrible. Like, they're not letting me do things. And I'm like, Hang on, you're a 7-person company. How is it, and you're an experienced person, how is it that you're not asking, what does the business need to do? Let's do it. Boom. And they've been socialized in a different place for a while. Yeah, I think that is, like, a huge part of it in terms of the incentives. I do think the orientation around, like, headcount filling, team kind of management, like the employee kind of survey results, these are really valuable tools. I get, like, a lot out of them. But I remember spending a lot of time at these faster-growing companies, like analyzing the quality of manager based on the survey results. But survey results are, like, you have to really interpret them. Like, high scores or low scores don't mean good or bad manager. There's, like, context to ask other questions about, like, hey, why is your team all upset about this? That doesn't mean you're a good manager or not, right? And I think these became a little bit a goal of their own rather than an interpretation mechanism, which, you know, in a lot of ways is just, like, lazy kind of middle management in terms of how these are deployed. But I definitely, definitely saw that. And I think, in general, I think I hate headcount conversations, and, right, I think they're almost never the most interesting conversation. But I think in a world where managers are not allowed to make technology decisions, the only lever they have to actually execute faster is headcount or prioritization. Oh, so are you saying that At that time, and during ZIRP, where managers were, the conventional wisdom was, do not make technical decisions. This forced savvy and smart managers to put way more focus on the non-technical side, potentially underinvesting in the technical things, maybe just not making decisions that should have been done, and over-indexing on the soft side, on maybe shielding their team from the business for all these things because they put their energy there. Oh, 100%. I think that's very true. Like, for most, like what I tell my teams that I work with now is, like, hiring is the least interesting way to solve every problem. Like, we almost always should never talk about hiring. But the corollary to that is, like, if you have open headcount and ask for more headcount, we shouldn't talk about headcount either. Because, like, what matters then is, like, the hiring throughput, and you actually, like, can't use more headcount anyway. But yeah, I think we basically told managers they couldn't think about technology solutions, and then what do they have? They have, like, process solutions, they have scheduling, or they have people. And so I do think this was the natural consequence of the bifurcation of these two roles, which isn't to say we shouldn't bifurcate at all, but I do think we need effective leadership to have both, or they over-anchor around kind of hiring, and that drives a lot of the bloated orgs we saw in the past. Let's talk about careers, career development. Let's start with individual contributors. How do you think career opportunities have changed for software engineers working at startups, mid-sized companies that you see? Because— You could trust them with a project. If they had junior engineers, they would mentor them. A staff, you could trust them to set the direction of a unit or multiple projects and so on. And the engineer one and engineer twos, they could execute well, coding without too many issues, took feedback. They were kind of like almost like, they were like apprentice levels. Like I think engineer ones, engineer two, it wasn't a serious promotion in terms of it. It was just, it wasn't a destination. It was just they're growing. Some companies even had the expectation that you were that you need to grow to a certain level. But they were like almost like apprentice, honestly. Like they were just kind of getting to that to have good judgment and all these things. Now that we're all using AI harnesses a lot more, including for reviews, code reviews are slowly going away as well. We're doing less of what we used to do, which is coding and the very visible feedback between each other. How would you define what the role of a software engineer is? And is it different from before? Is it more ambitious? How do you think about it? Because it is changing. Like I feel it's getting more ambitious somehow, but I'm not sure I'm able to put my finger on exactly how, especially from a CTO perspective. And is this like the general role or is this like the level three? No, this is the general software engineering role. Because I think I feel each role has changed a lot. Maybe the staff role, the staff engineers never did too much writing code at like mid-size and above companies because they were busy making sure we're building the right thing. So maybe it's hard to separate because now no one is writing too much code, and even the smallest roles, they will need to decide, are we doing the right thing? Am I doing it right? First, I think we're still like early days in terms of where we're going. And there's certainly people you're going to talk to that are like, hey, like the software teams of the future are five people for any size company. And maybe that's true. Maybe we get there at some point. We're definitely not there right now. And I don't know if we're going to get there soon, but there certainly are companies that have a small number of engineers spending a staggering number of tokens in Productive, and that's like a pretty cool thing to see. Where is the role of software going? I think we're going to find out. And this is actually why it's such a fun time to be in the industry right now, right? The most fun thing is, like, I think our profession is changing in a much more extreme way than anything I've seen since I entered the industry. And for me, like someone who's always been very oriented around the outcomes of the work I'm doing, it's just been, like, the most fun time I've had. But I've also spoken to folks who got basically joy from, you know, being in the zone, being in that flow state, and they, like, fallen out of love with software because what they loved was, like, the actual art of doing it. And for them, like, you know, a few folks, like one person I've spoken with recently, he actually, he's retiring. He's like, I just don't enjoy writing software anymore. And he's lost this flow state. He's like, I'm more productive, but, like, I just don't enjoy it. And so I think the role is shifting, but I think it's shifting in a really interesting way. And I, to me, I have this kind of idea of software where the time to actually implement is approaching zero. These systems are still very slow in terms of, like, you know, okay, let's say you can instantly implement stuff. You still have to make all these decisions. It still doesn't work in all these ways. It's still going to scale poorly in all these ways. It's still going to break the user expectation. It's still going to have, like, the wrong unit economics to actually be, like, a profitable business. And so I do think even if software were, like, literally free to write, it's still really, really, really hard. And so, like, today you'll see this, like, if software is free, then all of a sudden engineers are running ahead of the PRDs from product and running ahead from the high-fidelity mocks from design, and that's creating a ton of issues for design teams trying to work with this engineering-led model and something we're still trying to figure out at Imprint, totally honestly, right? That also could create opportunities where, like, well, if an engineer also puts on a design hat or a business domain hat and now, like, runs an experiment full on, and obviously now you get to, like, there's only so many experiments you can run without confusing customers, which now it goes back to strategy, someone having to say no. And also, like, who are you building with? Like, if it's for people, like, they will need a number of attention. Like Netflix has, I don't know how many new movies they bring out, but I know that when I open Netflix, they don't overload me. I mean, they do, but they don't show me all 8,000 movies they figure out. And so I wonder if— If software is becoming faster, like as engineers, we will need to discover the constraints of the other parts of the business, the domain, the customers, the realities, like you say, unit economics, how money can be made. I think something I thought about a lot working at Carta. So Carta is a low-scale business, by which I mean there's not like hundreds of thousands of requests per second coming in. There's no, like, massive infrastructure problems there, but it's an incredibly detailed business. How cap tables work is really, really, really specific, and it's very complicated, and there are tons of exceptions. And then doing accounting is important, right? It's a little thing, but you need to get that right. The accuracy is really important from, like, an auditability perspective. You're also working with law firms that have, like, a real strong point of view about how everything should be done very particularly as well. And you could be in a legal battle between two founders who are arguing about how much equity was actually vested or something like that. Similarly, the other businesses Carta went into, like the fund administration, also incredibly detail-oriented. And so there are a lot of businesses out there where the domain context has always been the hard thing. And it's not super clear to me if businesses where the domain context is really the hard part. have benefited that much yet from kind of all the AI tools. It's still incredibly hard to do cap table management because of the details, the laws, the relationships, the law firms in terms of training, like the paralegals there. There's like all these little pieces that I think domain, like complex domain businesses still have like a lot of defensibility in this day and age. And I don't know if that's how that's going to change. I think it will change. Every two to three years, there's this kind of like, the product engineers are the new king, product engineers are the new superhero kind of like meme that comes around. Now it's the AI engineer. Now it's the AI engineer, who really are like product engineers that use like AI techniques, right? And so the question is— Which is pretty much every product engineer these days. A hundred percent, right? So it's like, it's unclear. I mean, I've never really quite understood what AI engineer means. I think it means someone who uses harnesses and wants to get paid a lot of compensation, is I think what it means. But it probably means something else too that I've just sort of missed the nuances on. But like, can you actually get individuals to hold all this context in their head? So even today, you know, people used to talk about like the front-end engineer who's actually a good designer, or the designer who could actually write production front-end code. That person's always been rare. And now a designer with like a little bit of taste can write production code, right? And vice versa, a front-end engineer with like good design taste can do design. Why aren't we seeing more of that yet? And so I think that's like a social constraint. Well, it's a really good question because I was asking the same thing. I saw some data from Linear showing that PRs for designers and product managers are up. And I was like, oh, actually someone messaged this to me, a fellow engineering manager, said like, hang on, I've been asking around, like, we should be seeing more designers push to production, right? Or product managers. Asked around ten companies. I asked around another— Hang on, why has none of the other competitors launched it? Why has Google Chat, who have amazing people as well—these are all people that have the domain. And I think this is where I'm starting to—this one example just started to realize, like, there is probably value in, like, Slack having all these people who are working. I'm sure there's—would be horrified of how many people work there. I know from Uber, like, why does Uber have this many people? But they're working on this, but they're not only able to operate what they have, but they keep reinventing what customers will want as the world changes. You know, the other companies seem to have not responded, even though agents have been here for a while. They just haven't responded. Slack has not only responded, they did something that is objectively good, and now it's copyable. But how did you get there, right? There's some paper about the size of the bureaucracy of managing, like, the British kind of empire, and the size of bureaucracy—the number of bureaucrats kept growing even as the territory getting managed kept shrinking. And there's sort of this inherent kind of thing where companies do just expand and create, like, bureaucracy and create, like, more kind of overhead. So there's something there where, like, sometimes companies have just kind of, like, lost the plot on their ability to actually move. But, like, my assumption—I think this is true for the Muse work on, for Meta—my impression is that when really interesting good products come out, there is one or two highly empowered people that are connected to the founder, the CEO, the executive team, that are pushing it through and that are able to make painful trade-offs that are not well liked. And those can be, like, legal versus, like, company trade-offs. Those can be product trade-offs. Those can be—there are, you know, the sacred kind of elements of how things have to be done, not doing it that way. And so, like, my guess is, like, for Slack, there was some sponsor. And look, people hate overemphasizing executives, but I do think executive sponsorship to actually empower folks to do something difficult. Imprint moved over to Linear, you know, like three or four months ago from Jira. We did it in, like, less than four weeks. And there were basically zero people that thought it was a good idea when I decided to do it. We still did it in less than four weeks, and now people are really glad we did. It solved a lot of problems we had about having centralized issue management so the agents could actually know where tasks were, pull them down, work them, actually do kind of task unification, etc. We're having a really hard time managing workloads of tasks without that. But there were like maybe three people out of like 230 that thought it was a good idea before I did it. And that one I just, you know, pushed through. And I think now people are like, Oh, that was a good idea, but they just didn't think it was. And sometimes you do have to have someone who's willing to take the risk. And then, you know, the flip side is you then need to judge execs and other senior leaders on, are the risks they made us take good? And so I think three months into the linear migration, I think, you know, no one talks about Jira anymore, but certainly no one's upset about the change. People are really glad with it. But conversely, if people had hated it, like they should be, like, you know, rallying to get me fired, right? But I think a lot of times people don't get held account to this, and so that's the flip side of that highly empowered executive sponsor that does make these great products. Sometimes we let them do incredibly boneheaded things and don't hold them to account. Which is a great segue to talking about executives. You've been a CTO, which is a former executive. Could you tell me what, in your interpretation, an executive is, and how, what is the career path today to get to that level from an engineer? Like, okay, like I like the idea of executive. I like that to be able to make decisions, including unpopular ones. Helping people, helping companies. What was the old path and what's the new path, if there's any? So I think the old path, you're a software engineer for some number of years. It could be pretty short. Then you get into management, and then you climb through middle management, and then you get to the CTO role. Middle management, engineering manager, senior eng, director. Exactly. And so I think there are a lot of problems with that. First, it means that often the people that were selected for management initially weren't, like, the most focused on the technical pieces of the work because they're trying to get promoted into management. And then the selection bias is really towards people that are able to operate well, which doesn't necessarily have a whole lot in common with the technology side. Often they happen to be really good technology, but there wasn't, like, a strong kind of selection bias for it. But you really do have to be a good bureaucrat to be an executive. And this is, like, one of the interesting challenges where a lot of my work is incentive management. It's knowing, hey, if we roll out this sort of performance review, here's how it's going to fail, and so we just shouldn't do that. We should do this other thing instead. And so if you haven't done the reps of being, like, a bureaucrat, you actually, like, can't run a function because a lot of running a function is, in fact, being a bureaucrat. You learned to be a good bureaucrat. I was a bureaucrat, right? And so, I mean, out of necessity. So at Uber, there weren't, like, really, like, rubrics. There wasn't, like, an interview. We didn't have any structure how we interviewed when I was there. So you had to make it all up yourself for your function. And again, we were doing tons of interviews, and each time we didn't give an offer out, I was, like, so pained because I was doing so many interviews. So I had to figure that out. And then at Stripe, Stripe was, like, a much more structurally cohesive company. And so we did have, like, a lot of structured process. And then I got to work on a lot of that and learned a lot there. You got pulled into it. You picked up the pace. A hundred percent. And a lot of the structure I thought wasn't working well at the point that I joined to kind of, like, work to try to iterate and improve little pieces of it because we were, you know, growing pretty quickly. And so really, you know, working these middle management jobs, I think, did educate me on how to be a good bureaucrat, which is part of being an effective executive because you can just allocate. Processes that work and avoid processes that don't work. Think about incentives that work and don't work, structure that does work and doesn't work. You know, the Jefferyd scene, like a state, like you're not allowed to be in Silicon Valley if you haven't read Seeing Like a State. But it's basically a book about how states see citizens and accomplishments and how that shapes how policy works. It's the same thing. Like if you've never been a bureaucrat, you don't know how to see things as a bureaucrat. But also, like if you can only be a bureaucrat, you don't know how anything actually works. You don't know how software actually gets made. And so it's, like, very damaging to you. So am I getting this right that you're saying to be a good engineering executive, so VP of engineering or CTO, you want to be excellent at technology, knowing how it works, being hands-on if you need to be or just be hands-on, and also be a good bureaucrat where you can manage it, and you want both. And you're saying that if you go the middle management route, oftentimes it might happen that you either never were a good technologist or you stop becoming that by the time you get up there. So you're a good bureaucrat but not technology. But if you just go from, like, an engineer, great technologist, straight up here, let's say, like you're a startup tomorrow, congrats, you're the CTO, you will not be a good bureaucrat. I think that's exactly right. And it's interesting where oftentimes I think line managers are better kind of instinctual executives than kind of middle managers because they're used to working the detail, so they can make better calls for the team or the company. Their judgment's just better on all these, like, non-bureaucratic dimensions of the job. But then their judgment's terrible on kind of the bureaucratic dimensions of the job. And so this is why I think being an executive is hard and why it's a hard career path, is that it was, you know, in the 2010s in particular, you had to climb these, like, layers of middle management to learn this kind of bureaucratic component of it, and that was the only way to get scale to actually understand that. Now those layers are kind of gone. But the interesting thing is, like, the other half of the job is now really emphasized in terms of better decision-making, understanding the actual product, understanding the actual business, understanding how software is shipped. Sometimes. And so I do think we have to be willing to kind of take lateral moves. We have to be willing to be a little bit humble. But if doing the actual work, that's like the thing that matters to the company is humility, then we've sort of, like, lost track of what we're doing here, because we really do just get paid to do things that are valuable to the companies, right? Like, there's no, like, entertainment orientation to why these companies employ us. Yeah. What about the TLM role, tech lead manager? This was a role that we declared dead. You and me both declared dead as a dead end. It is there, but this was back in, you know, like, the tech leads who were given a very small team to manage as well. And we were clear, like, in ZIRP, that it's just a career rut, and if your experience is great. I think you also made it clear that it's a trap. I think you have an article. What do you think about this role now? It's funny. It's still a trap, but it's a highly demanded trap. And so, and I think in many cases, there's no way to actually—there's no alternative. So kind of it's less a trap than simply what's there. And so I think in a lot of companies, management is getting flattened. So we're starting to see, like, a director, let's say, have a bunch of, like, tech leads and, like, an org of, like, 30 people and a couple of tech leads here and there. Yep. And I think you're either seeing kind of two models. You're seeing there are engineering managers, but they're managing much larger scopes, and so they're actually, like, less kind of hands-on the individuals than they were before, because they're managing, say, like, 12, 13, 14 people before instead of, like, you know, like, 4 to 8. And then we're also seeing kind of directors have been managing tech lead managers instead of managing kind of these line managers. In different companies, they're trying different things. But I think this is where I see the industry kind of asking for folks right now. And I do say, like, some of the best folks we've hired at Imprint have been folks that were in, like, more pure management roles that came in but really wanted to be writing software and have just been doing an amazing job of kind of, like, doing a blend of both. It is hard to find those folks where it's almost like— Interview them to be a great EM, and then, like, do you just get frustrated you're not writing more software? It's really that person is kind of what you want. But it's hard, you know, not how we've been interviewing them so far. I think we've just found a few great folks, but that is the role that we really want. And again, it kind of goes back to this thing where you want people who have the capability to do the bureaucratic parts, but don't want to, like the capability but not the desire, because those are really the folks that I see super effective these days. They can use that when they need to, but they default to actually writing software, which is really where most of the value is. As a closing topic, I wanted to ask you about how you write. You've been such a prolific writer. Still, I really enjoy your blog whenever there's a new article, I check it out. There's also, there's an email that I subscribe to and I actually get it in my inbox. How your approach to writing, and what do you think about AI? And also, what is your take on—there's a lot of AI writing going on, not just for social media on LinkedIn, we know that, but also for some authors who, before AI, they didn't write with AI, but now they're starting to a little bit. So I've been writing for about 20 years online in my blog, and I founded Irrational Exuberance in 2007. And then, you know, next year, I actually might have been like May or June or something when I started writing it, so I'm getting close to this 20-year kind of anniversary. And when I first started writing, I was simply trying to figure out how to, like, network my way into a job, basically. But I did a ton of tutorials, just like, here's how I did this, and this was a different era. Now the sort of thing that you just asked, you know, in AI, like, how do I do X? And it would write a great tutorial just for you, or maybe just do it for you directly, right? Then as I started working at Uber, I started writing a little bit more of, like, the things I've been learning in hyperscale. And then it really took off when I was writing at Stripe, because I think Stripe was a place that both had a lot to learn, but a real, like, love of writing, and that to me, like, really energized my work. And then wrote my first book, kind of the culmination of the things I had written at Stripe, An Elegant Puzzle, and then got a lot of momentum. I think a total of four books. Probably not writing another book for at least a decade, maybe not ever. But I think it's just been, it's been so transformational for me. I think, like, so much of, like, when people know me, which is not that very often, really, but, like, when people know me, it's exclusively from the books that I've written or the blog. And I really do believe writing is, like, a unique way that we as individuals can actually change the shape of the industry. And I think when you've done that, there's, like, little things that kind of pop up. So for you, like, the tri-modal kind of salary piece, right? And that is first, like, a memorable name that helps. But also, like, I think it was, like, a really important observation that a lot of people didn't understand. I think you've changed a lot of people in how they approach compensation. And then Patrick McKenzie has his work on negotiation, right? So impactful, probably created so much wealth for people in the world. I think so. I think he might try to track how much he's created on it, but I'm not sure if that's still true. But for my books, I really think I've changed the industry with them. And I think Staff Engineer, I think notably, I think, like, the Staff Plus kind of concept, that book created Staff Plus as, like, a concept, right? And there's other things that I think are, like, less, like, quotable but have been mattered. And there's just, like, there's nothing I could have done in my work in any company that could have impacted the industry in this way. This many people. And so, so positively. Or I remember the bold, elegant puzzle and the SAP engine. I read it and I took a lot of guidance from it. And that's just so powerful. And then I think about writing with AI, and, like, I've spent tens of thousands of hours over 20 years creating this, writing this stuff. I'm not, like, super craft-oriented in my writing, by which I mean I'm really trying to get ideas out more than I'm trying to write, like, the best blog post. I've never been craft-oriented in terms of writing great blog posts. I'm more just trying to get the ideas out written somewhere. I think what I like about your writing is there are very punchy ideas. It's not about the writing per se. Like, you're, I would say you're a decent writer. It's enjoyable, but it's not like—I don't like it because it's enjoyable to read. The idea comes and is there, and it makes me thinking. And I'm not thinking because of how you presented it. And again, the presentation is fine, but the idea is what brings me home. Yeah, it's pretty minimal writing. And some of your articles are short. Yep. It's not even about the length. I'm way more wordy in my writing than you are, which you will know, but it's just my natural style. But in yours, it doesn't have to be. Like, what I like about yours, you don't waste a breath in your writing when there's not much, and that's complete. Yep. And then I think about that, all the stuff I put together, all of the things I've tried to change people's minds on. And to me, like, writing with AI would just be like throwing that away. And so I think, you know, like, I've never done a newsletter trying to collect, like, a huge number of folks. It's more if you want to read what I'm writing, this is what it is. It's not like my business, like it is for you. But still, like, you know, I've gathered, like, some number of folks, and, like, they, I think they read what I write, and that's really powerful. And I know— I know if I write something, like often there'll be hundreds of companies talking about the idea there in the next week. And that's just such like a privileged spot to be in. If I just wrote slop, I would just throw it away, and it's, I could never. Technology side. Today, with smaller teams and less middle management, many CTOs will be technologists first, which Will thinks it might be better overall, and I have to agree with it. Finally, I appreciated Will's advice to middle managers, middle managers being engineering managers who have teams that other managers report to them. Will did not beat around the bush. Yes, today it's a hard time to be in middle management. The two paths to seize looking forward are either you go back to being closer to where software is being built, work on a smaller team, or as a line manager role, or just accept that your expertise of mostly being a bureaucrat but not a technologist could not be valued that much in a few years' time. Will himself took a backwards when he left the 250-person engineering team at Carta to a about 25-person team at Imprint, but he did it consciously to learn how to build with AI changing the engineering profession. I do find it inspiring that Will not only talks about the importance of learning the new rules of software engineering, but also walks the walk. Do check out the show notes on related to pragmatic engineering deep dives on zero interest rates and engineering and EM careers. If you enjoyed the podcast, do subscribe in your favorite podcast player, and a special thank you if you also leave a rating on the show. Thanks, and I'll see you in the next one.