The Pragmatic Engineer
00:46:09 · Gergely Orosz, Titus Winters
[00:46:09] S0: In the book, you write about the importance of a team, and I I I'll quote you. In the realm of programming, lone craftspeople are extremely rare, and even when they do exist, they don't perform superhuman achievements vacuum. Their world changing accomplishment is almost always the result of a spark of inspiration followed by a heroic team effort. A great team makes brilliant use of its superstars, but the whole is always greater than the sum of the parts. But creating a superstar team is fiendishly difficult. [00:46:37] S1: Yeah. Don't think I wrote that chapter. [00:46:40] S0: It's in the book that you are a co author of. So I wanted to reflect on this especially with AI because now I'm starting to hear a lot more people say, yeah, in the past, we talked about a 10x engineer up to up to one... Up to 22, 23. [00:46:57] S1: We started on that. [00:46:58] S0: But I am now starting to hear people say like, oh, there's now the 100x engineer, which is this engineer who is a great engineer, uses AI amazingly well, and we are also hearing stories of individuals doing heroic efforts by themselves and with a bunch of AI agents. So I just wanted to ask you how the full... Concept of the team holds up as we have more AI tools and the concept of a standout team.
00:46:58 · Gergely Orosz, Titus Winters
[00:46:58] S0: But I am now starting to hear people say like, oh, there's now the 100x engineer, which is this engineer who is a great engineer, uses AI amazingly well, and we are also hearing stories of individuals doing heroic efforts by themselves and with a bunch of AI agents. So I just wanted to ask you how the full... Concept of the team holds up as we have more AI tools and the concept of a standout team. [00:47:23] S1: Yeah. So I think regardless of where you fit on the spectrum of AI believerism, I think the team is still critical. Like, if you believe that the agents are the only answer in another direction forward, we're still managing that team of agents. And I've heard an increasing number of voices talking about it as the problem right now is we need to make every engineer into an engineering manager for a team of agents. And we don't have the training or skill set or background to have done that. Like, we're asking them to do a thing with no no scaffolding or guidance. The alternative is you think of the AI and the agents as your tools, your IDE, but it is still you in conjunction with the team of humans around you. It's still team behavior. Right? I think there are certainly differences in the social dynamics and things like that between you and the agents, which I'm gonna go out on a limb and say the agents don't have feelings. [00:48:27] S0: They definitely do not. Right? Should not.
00:48:27 · Gergely Orosz, Titus Winters
[00:48:27] S0: They definitely do not. Right? Should not. [00:48:30] S1: Like, I'll just hold that line for a bit. But... Yeah. Like, I I think understanding clear communication and being able to write things down and get it out of your head is still, you know, a substantial important thing. Like, I... Yeah. I think it is still unquestionably still teams at the root of it. Software engineering is a team sport. [00:48:55] S0: Period. Also, guess just one, like, pretty, like, naive way to just prove that this is probably still true is if we just look at some of the leading AI companies, the leading AI labs, the Anthropic, the OpenAI's. When I talk to people there, I see standout individuals who are working as a team, you know, like Claude Code, for example. They're they're... They cleverly have a public face in front of both of them, Boris Cherny who created it, and I think they do amazing job. It makes it very relatable that this is a human. There's a team behind Boris. Yeah. And and that team, you can... When I met them, you can tell the the jail. They work together. They trust each other. You know? Like, at some point, Boris will be on holiday. Right.
00:49:35 · Titus Winters, Gergely Orosz
[00:49:35] S1: And you will not know because things just happen. Right. Like, you said the important keyword. Right? Trust. Right? Like, a substantial part of this is the psychological safety aspect of it. The other thing, which I think is natural for the AI labs but hasn't been nearly as dominant for the rest of the industry yet, is you're learning as you go. And if you look at all of the research, you know, like DORA research on stuff or any research on productivity or team efficacy or any of those things, like, at root, it always boils down to culture, psychological safety, and the the permission to learn. Right? It's the permission to admit that I don't know something. It is the incentive to learn from each other. It is the incentive to share your mistakes so that the team only has to do that once. Your lint rules or SRE postmortem culture. Every effective structure and organization in tech is actually about information flow and learning. And I think a really great perspective on that. I love Kat Hicks, the psychology researcher for tech. Like, her book, The Psychology of Software Teams, is beautiful. And, like, she talks about, you know, these these things a lot. Right? Similarly, there's a platform engineering at Google book that some of my friends are putting out. There's early release chapters on O'Reilly. I might have written the chapter on education for that. [00:51:03] S0: So so very surprisingly slash not surprisingly.
00:51:03 · Gergely Orosz, Titus Winters
[00:51:03] S0: So so very surprisingly slash not surprisingly. [00:51:06] S1: Right? But, yeah, like, education is the powerful route for, like, let's make this mistake a minimum number of times. Let's codify what we've done. Let's give people permission to admit they don't know and to grow because it's not a one off game. It's an iterated game, and you'll do better over time if your team is better next time. [00:51:30] S0: I want to go back to psychological safety because back about five, ten years ago, we kind of would talk so much about it in engineering leadership side side circles. This was pretty well understood that, you know, a good team feels a safe team. If you, for example, make a mistake, you cause an outage as an engineer, like literally, you push a code and that code causes outage. We should have a blameless postmortem where we don't say that, hey, Gergely pushed this code and he caused the outage because that's now, I mean, I feel terrible and... But let's talk about, like, for example, how could have we avoided this at a system Why did a test not fire? Why was it rolled out immediately when he was a new joiner on the team or she was a new joiner to him? Like, maybe some onboarding could have helped yada yada yada. What... How how do you define psychological safety and why is it important? Especially just playing devil's advocate, like, when we're talking about smart engineers who know stuff, like, is it all that important to us? Because we we should know our thing. Right? I'm just like, I'm kinda removing my emotional Yeah.
00:52:26 · Titus Winters, Gergely Orosz
[00:52:26] S1: Yeah. Hat here. Yeah. We should know our thing. Sure. So I would say... And it's been a little hard to, like, root this stat, but from talking with people in DORA, the the research... The one thing that I love was we can explain 30% of the variance in whether or not you... Your team will hit its goals based on how you score on psych culture questions. Right? Like, we could give you a 15 question true false or maybe Likert scale, like, but like a 15 question assessment for the team and predict 30% of whether or not you will hit whatever your goals are. That's insanity. Right? That is more powerful than any other signal. Like, okay. So you think that we're all engineers, and this is all just computers and tech and emotions have nothing to do with it. Find me anything that's even remotely that powerful predictor of success. It's a people problem. Like, period. Right? And going back to... Right? It's it's not a single shot game. It's an iterated game. I regularly cite Fred Brooks in the Mythical Man Month essays. Right? And in the surgical team... Like, the surgical team is my least favorite chapter in that book because it's structured as if we're only ever gonna do one project. Get the best person to do this. Get... Have everyone else build the tools and do the documentation. Under them. It's very [00:53:53] S0: hierarchical.