The Pragmatic Engineer · 5 min · Oct 21, 2026

Durable teams let leaders focus on the problems only they can solve

Will Larson · CTO, Imprint

Will Larson repeatedly organized engineers into small pods that owned areas, then intervened only when something went wrong.

In this episode

19:39 Digg launched a rewrite without load testing or rollback capacityPro pick 6 min
50:47 ZIRP pushed managers toward hiring and people-focused workPro pick 7 min
1:33:30 Middle managers may need to return to hands-on engineeringPro pick 6 min
1:16:22Durable teams let leaders focus on the problems only they can solve5 min
1:26:01 A CTO needs both technical judgment and bureaucratic experience6 min
57:21 Staff engineers are distinguished by how they resolve ambiguity4 min
10:19 Central server approvals created a black market at Yahoo2 min

“The first thing I did was like, all right, what are some pods? And figuring out like some areas I could put together who could own areas.”

Will Larsonat 1:18:10 · The Pragmatic Engineer

Takeaways

Form small pods with clear ownership of an area.
Let teams build context instead of moving people to each crisis.
Reserve leadership attention for the hardest unresolved problems.

About this segment

Will Larson repeatedly organized engineers into small pods that owned areas, then intervened only when something went wrong. Durable ownership builds context and leaves leaders free to tackle cross-team problems.

Will Larson is CTO of Imprint and author on engineering leadership.

Led engineering at Stripe, Uber, Calm and Carta; author of Staff Engineer and The Engineering Executive's Primer.

Gergely Orosz, Host · Host, The Pragmatic Engineer
Spent four years at Uber heading mobile, web and backend teams; shipped part of its payments system.

From “The revised rules of engineering management with Will Larson”, Oct 21, 2026. Watch the full episode

Transcript

Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.

1:16:29
related to this is you you wrote uh revised rules of engineering management to read the next article we'll link it in the show notes below and one of the rules that i want to highlight you say we wrote durable high ownership teams i'm quoting you durable high ownership teams with domain context are even more important one of my biggest lessons at uber was that persistent durable teams work magic by accumulating domain context building a sense of camaraderie and feeling increasingly strong sense of ownership over an area as they continue to work on it now this was from uber like what like 2014 15 team.
1:16:59
So like more than 10 years ago. And you're saying that you feel this is very relevant, right? I think this is the only way to build skilled organizations. And it's interesting, though. I think this is this seems kind of like obvious, but it's actually a bit of like a non-consensus take, if you will. And so a lot of times you're at a company, say there is 50 engineers and you have a really important project for a partner.
1:17:21
That project's late. There's still the Mythical Man month thing. They're like, hey, we're moving 15 more people to work on this key project. and you know the mythical man month i i want to say was written in like 80 84 75 75 and the second version 95 and it's that that's a while ago um and so more than 50 years we know this doesn't work and so like first like when people do things like this a lot of it's like optics and creating the perception of doing everything possible yes so that when you miss it's not it's not your fault but actually not only does does it not work it also destroys thing that does work which is creating little pods that are able to own areas. And so when I joined Stripe, I had, you know, I took over kind of the team Jorge was leading at the time and he moved on to a different part
1:18:06
of the company, I think to lead connect. And so I had 30 people and one manager was managing like four or five of them. And then I was directly managing say like 23, 24 people. The first thing I did was like, all right, what are some pods? And figuring out like some areas I could put together who could own areas. And then once I saw some progress, I just stopped thinking about them entirely until something went really wrong. So I could focus on the bigger priorities for me, which is like the problems you couldn't solve. This works so well. And so at Uber, I did the same thing. When I came into Imprint, I did the same thing as well. Same at Com. Carto was like a really well kind of scaled organization by the time I joined it. So I didn't need to do the same thing there. I think this just works incredibly well. I think if you do this well, that people
1:18:54
actually do better work than you will from top-down dictation, simply because they understand it really well. And it gives you the ability to actually put your attention on the highest leverage or most painful parts of the company. And so, yeah, I think this is a strange non-consensus take, but it just works incredibly well. But optically, it almost always looks wrong. And that's like one of the reasons it's hard to do where you have like a partner launch and you're like hey i'm not gonna i'm not gonna move these folks i'm gonna let them stay on what they're doing it's really important instead the team that's on the the critical path we're gonna work hard as hell together but like we're gonna burn to get through it we're not gonna pull everyone over because if you don't do that or or what what you might have done in the past is
1:19:39
especially in serp uh where it was you had meetings recruitment all that you would say Like for this team on a critical path, we remove them from all of the BS, the recruitment, the university trip. You don't need to attend all hands and all these things. So you can be heads up, which actually, by the way, works so much better than adding people. And also sometimes telling people like, look, this will be a two week push.
1:20:00
Anyone who can commit to it, please do so, including putting extra hours. And in return, you can take time off afterwards or or, you know, like you create incentives and you just treat them as adults. And you're saying, like, can you and oftentimes people will like I know in my life outside of work, sometimes you are OK taking a thing for this one thing, especially when you know that I will repay you in kind somehow.
1:20:25
And if you don't do that, the thing that happens is actually at a at a real growing company, there's a crisis every day. And that means if you rotate people to crises, there's a crisis for everyone every day. And it creates the sense of like devastation. And so I remember talking with someone at Stripe one or two years in, we were talking about this. And he's like, the way Stripe had run up to that point, his metaphor was like, it was like people on a wall trying to defend a castle. And they were always running to the place where they're about to get like overwhelmed. But they just couldn't be everywhere because they were getting faster and faster at running.
1:20:59
But they still were not everywhere all at once. And what we were trying to do was switch this metaphor was like we had many people in many places. And so the people working in one spot had to solve that spot, but it meant they didn't have to be everywhere. Those are kind of the two tradeoffs. But to be a successfully scaling company that's growing quickly, you do have to get to a mode where it's not the same people running everywhere at once because those people just completely burn out over time. And there's a certain point where they just can't manage the coverage anymore.
1:21:29
no matter how amazing they are. Although I think the question with AI is that point much further than it was before. But I'm not sure if it is. I still think their attention runs out before their ability to write code does.