What Nobody Tells You About Leading Engineering Teams

What I’ve read this week all point to the same, somewhat unglamorous, truth: leading an engineering team well has very little to do with technical brilliance and almost everything to do with the daily discipline of decisions, honesty and attention. I’’ve seen this happen so many times in post incident reviews; where the team asked “what are we changing” rather than “why did this happen”. It’s so easy to jump straight to actions rather than take the time to understand the reasons why something turned out the way that it did.

So for this week, here’s eight pieces that between them, map out what that discipline actually looks like in practice.

Gautam Govind And Alex Ponomarev

Gautam Govind and Alex Ponomarev, writing in Thriving In Engineering, start from Gautam’s own move from backend engineer to team lead. His point is simple but easy to forget: as an individual contributor, a bad call mostly costs you your own time. As a lead, the same bad call costs someone else’s time, confidence and work. If you take that shift away from a new manager, you’re left with someone who still thinks decisions are a personal skill rather than a shared risk. I think that’s the real gap between “being good at the job” and “being good at leading people who do the job”: not just a bigger version of the same skill, but a genuinely different one.

Gregor Ojstersek And Dr Milan Milanović

Gregor Ojstersek and Dr Milan Milanović, in their Engineering Leadership newsletter, lay out six long-standing laws — Conway’s Law, Brooks’s Law, Goodhart’s Law and others — as a working toolkit rather than trivia. Conway’s Law says your system will end up mirroring your org chart whether you plan that or not. Brooks’s Law says adding people to a late project makes it later, not faster. Goodhart’s Law says the moment a metric becomes a target, it stops measuring what you actually wanted. None of these are new, but Milan’s twenty-odd years of engineering leadership behind the piece make the examples land. If you’re scaling a team right now, these are the reason your reorg isn’t fixing the problem you think it’s fixing.

Kellan Elliott-McCrea

Kellan Elliott-McCrea takes on the recurring tech-industry habit of declaring management obsolete, using Facebook’s recent experiment in flattening management as his evidence. Incidents went up, morale went down, even though raw code output went up. His framing is that managers act as catalysts — they lower the activation energy needed for a team to actually change direction, not by doing the work themselves but by building the trust and context that let other people move faster. I think this is the article from this week’s batch I’d most want a sceptical engineering leader to read, because it’s not just a defence of management for management’s sake, but a specific claim about what happens when you remove the catalyst and expect the reaction to carry on at the same rate.

Anton Zaides

Anton Zaides, on Manager.dev, splits engineering managers into four archetypes: the Umbrella, who prioritises the team’s welfare; the Crusader, who fights for the customer; the Gatekeeper, who protects technical standards; and the General, who optimises for company goals. His argument is that no single archetype is correct: most of us are a blend, shaped as much by the culture we sit inside as by our own values. I’d add that the more useful exercise isn’t just picking your own archetype, but noticing which one your organisation is quietly rewarding, because that’s usually the one you’ll drift toward whether you choose it or not.

Michael Heap

Michael Heap makes a case that sits close to something I care about: after an incident, the question “why did this happen?” almost always produces a reasonable explanation — and a reasonable explanation is exactly what stops anything changing, because everyone involved acted sensibly given what they knew. His reframe is to ask “given that reasonable people produced this outcome, what are we changing?” That’s a genuinely different question. It assumes competence rather than blame, but it still demands a concrete, system-level answer rather than a well-meaning commitment to “be more careful.”

Bruce Daisley

Bruce Daisley, in Make Work Better, argues that workplace connection isn’t just a soft nice-to-have sitting alongside the “real” metrics, but something with a measurable return on investment in its own right. It’s a shorter piece than most of this week’s selection, but it’s a useful counterweight to the laws-and-archetypes framing above: all the structural thinking in the world doesn’t help if the people on your team don’t actually trust or know each other. If you’ve ever cut the team social budget first when things got tight, this is worth fifteen minutes.

Cat Hicks

Cat Hicks, writing on Fight for the Human, looks at what’s happening to developers’ sense of identity as AI reshapes the day-to-day of the job. Her research angle is that developers who believe technical skill is an innate, fixed trait feel the most threatened by that change — because if your identity rests on “I’m naturally good at this,” anything that erodes the uniqueness of that skill feels like an attack on who you are. Her proposed fix is building “learning cultures” that reward growth and collaboration over competitive brilliance, which lowers the threat and frees up the problem-solving capacity that anxiety otherwise eats up. I think this is the piece from this week that ties most directly back to Anton Zaides’ archetypes above: the Gatekeeper archetype and the fixed-skill identity she describes are, I’d guess, the same person wearing two different hats.

James Stanier

This one’s behind The Engineering Manager’s paywall, so it’s only worth clicking through if you’re already a paying subscriber. James Stanier argues that as organisations grow, the layers of management between a leader and the actual work become what he calls a “distortion machine” — each layer filters and reshapes what gets reported upward, usually toward whatever looks best rather than what’s true. He draws on Warren Buffett’s “institutional imperative” and on Jim Casey of UPS, who used to personally interview delivery drivers rather than rely on reports about them. The practical takeaway is that if you want the truth, you have to go and get it yourself occasionally, rather than trusting that it’ll survive the trip up through several layers of summary.

So What Should Engineering Leaders Actually Do?

A few things that I’ll be thinking about:

• Treat a new lead’s first real failure as a decision-impact problem instead of a technical one. Gautam Govind and Alex Ponomarev’s framing is the clearest way I’ve seen to explain why the job feels different from day one.
• Next time a reorg or process change doesn’t land the way you expected, check it against Conway’s, Brooks’s or Goodhart’s Law before assuming the team got it wrong.
• Notice which of Anton Zaides’ four archetypes your own organisation is quietly rewarding — and whether that’s the archetype you’d actually choose for yourself if nobody was watching.
• In the next postmortem, try swapping “why did this happen?” for Michael Heap’s “what are we changing?” and see whether the conversation moves somewhere different.
• Don’t treat team connection as the first budget line to cut — Bruce Daisley’s ROI framing is a useful one to have ready when that conversation comes up.
• If your team is anxious about AI eroding what makes them valuable, Cat Hicks’ research suggests the fix lives in team culture: what the team rewards matters more than what you tell someone in a one-to-one.
• Go and get the truth yourself occasionally, the way James Stanier describes Jim Casey doing — don’t assume it survives the trip up through several layers of reporting.