Incident management restores service. Problem management makes sure the same class of failure costs less every time it appears. A team that only does the first is very busy and never gets quiet.

The mechanism is boring and administrative, which is exactly why it gets skipped. Classification is what lets you see patterns instead of anecdotes: if severity is assigned by whoever shouts loudest, your incident data is noise.

The known error database is the organisation’s memory. When it is maintained, an engineer meets a failure a colleague already solved and closes it in ten minutes. When it isn’t, they rediscover it, and the company pays twice for the same lesson.

“Human error” is never a root cause. It is a description of a system that permitted the error and didn’t catch it.

The RCA quality bar is where I am least willing to compromise. An analysis that terminates at a person has failed, and I’ll send it back. The useful question is never who typed the command — it is why the command was available, why nothing flagged it, and why recovery took as long as it did.

Two things make it hold in practice. RCA needs a protected turnaround time, because an analysis delivered weeks late is a document rather than a control. And blamelessness has to be real rather than declared — everyone can tell the difference between a company that has written the word on a wiki and one where naming your own mistake has visibly never harmed anyone. Only the second kind gets told the truth.

The payoff isn’t a dashboard. It’s that the same incident stops arriving.

At fifteen you can hold every thread yourself. You know roughly what each person is working on, and your instinct is usually right because it rests on direct observation. That competence is exactly what betrays you at thirty: your information becomes second-hand, and the instinct keeps firing with the same confidence on much worse data.

So the first real decision at that size is what you are going to be deliberately ignorant of. Not what you’ll delegate, since delegation still implies you’re tracking it, but which categories of detail you will genuinely stop holding. A leader who keeps a hand in everything at thirty people becomes the queue the whole organisation waits in.

The second change is where predictability comes from. On a single team it is mostly the team’s own discipline. Across four teams, almost all the variance lives in the connections between them — the dependency raised too late, the shared service nobody owns, the release that needs three teams to align on one afternoon. Working harder inside each team does very little for that.

You stop optimising decisions and start optimising who gets to make them.

Making the seams explicit does almost all of the work, which is why cross-team release coordination stops being an administrative chore and becomes a first-class responsibility with a name attached to it.

The third change is the uncomfortable one. You now lead through people whose judgment you have to trust before you have much evidence for it, and the only way to get evidence is to let them decide things while the stakes are still survivable. Managers who can’t tolerate that never build a second layer — and an organisation without a second layer is just a large team with a bottleneck at the top.

It works when it starts from a task somebody already resents. Not the most impressive use case: the most annoying one. Release notes assembled by hand. First-pass triage on a noisy alert stream. Turning an incident timeline into a draft analysis that a human then corrects.

These are unglamorous, low-stakes and high-frequency, and they have the property that matters most — the person doing them can immediately tell whether the output is any good. That feedback loop turns curiosity into habit, and habit is the only thing that survives the enthusiasm phase.

Measure the work, not the tool. Usage statistics tell you how compliant people are, not whether anything got better.

Before any of it reaches a team, the governance questions need real answers, because engineers will ask and a vague answer stops adoption dead. What data is allowed to leave the building. What output requires human review before it reaches a customer, a repository or a regulator. Who is accountable when it’s wrong — and the answer is always a person, never the tool.

The last thing I’d say is that this is mostly a permission problem wearing a technology costume. Most engineers have already tried these tools privately. What they lack is a clear signal about what is sanctioned, what is off limits, and whether using them reads as competence or as cutting corners. Answer that plainly and adoption largely handles itself.

I screen for three things. How someone reasons when the information is incomplete — not whether they reach my answer, but whether they can say what they’d need to know and how they’d find it. Whether they can disagree well, holding a position under pressure without turning it into a contest. And whether they have ever changed their mind about something technical, and can explain what changed it.

That last one is the most predictive question I know, and it’s remarkable how many strong applications have no answer to it. What I’m not selecting for is recall: trivia interviews measure preparation and confidence, both distributed for reasons that have nothing to do with how good someone will be a year in.

Feedback delivered at review time isn’t feedback. It’s a verdict on a period the person can no longer influence.

The other half is what I owe. Clarity about what “good” looks like at their level, specific enough that they could assess themselves against it without me. One-to-ones that aren’t status meetings. Feedback early enough to act on, including the uncomfortable kind. And honesty about what I can’t promise — I would rather say plainly that the promotion isn’t available than manage someone with an implication I can’t back.

I treat attrition as feedback on management before anything else. People rarely leave a role they’re growing in, for a manager who is straight with them, on a team that ships. When someone leaves, at least one of those three was missing, and working out which one is more useful than concluding that the market is hot.