Leading People
Servant Leadership Is Great Until the Data Centre Is on Fire
Principal Architect · 7 April 2026 · 6 min read
02:14 on a Sunday. Half a rack has dropped, storage replication has stopped, and there are nine people on the bridge. The lead has just said, with genuine good intent, "so what does everyone think we should do?"
Forty minutes later they were still thinking.
The bridge call that cost an hour
I've sat on that call. Not that exact one, but near enough, more than once.
What happens is predictable. Two engineers advocate for failing over to the secondary site. One says failover is riskier than it looks because the last test was nine months ago. The database specialist wants twenty minutes to check replication lag before anyone touches anything. Someone from the application side joins and asks a reasonable question that resets the conversation to the beginning.
Every one of those people is being helpful. The lead is being inclusive. And the clock is running at something like four thousand pounds a minute in lost transactions, which nobody on the call is tracking because they're all deep in the technical argument.
Nobody had decided in advance who decides, so the bridge ended up running a consensus process on an irreversible call under a hard time constraint. You can have any two of consensus, speed, and a genuinely contested call. You cannot have all three.
Two dials tell you which style to use
Forget the taxonomy for a second. Before you pick how to lead a given moment, you're really reading two things.
How reversible is this decision? Renaming a service, choosing a linting standard, restructuring a sprint board: all cheap to undo. Run those democratically and you lose nothing, and you gain people who are invested because they chose it. Migrating production data, signing a three-year contract, failing over a site: expensive or impossible to undo. Those need one accountable decider, informed quickly by the people who know most.
How much time do you actually have? Not how much time it feels like. Actual time, in minutes, before the option set shrinks. At 02:14 on that bridge the honest answer was "about ten minutes before failover stops being the cheap option", and nobody had said that number out loud.
Layer team maturity on top and you have your answer most of the time. A team that has run this scenario before can be given the outcome and left alone. A team seeing it for the first time needs you closer, asking directed questions rather than open ones.
The pattern that gets people into trouble is having one setting for everything. The permanently consultative lead who can't make a call when the room is deadlocked. The permanently directive lead whose senior engineers stop offering opinions by month three, because why would they.
Say the switch out loud
Here's the bit that stops style-switching from feeling like personality disorder to the people around you: you narrate it.
"Normally I'd want us to agree on this together. Not tonight. I'm making the call, here it is, here's why, and we'll review the decision properly on Tuesday."
That sentence costs six seconds and it does three jobs at once. The team knows the mode has changed and why. Nobody wonders whether their input was unwelcome. And you've committed, in front of witnesses, to going back to normal, which is the promise that keeps you honest.
What corrodes trust is not directive leadership. It's unpredictable leadership. If your team cannot tell from the situation which version of you is about to show up, they hedge. Hedging looks like long silences in meetings, decisions that quietly wait for you, and engineers who stop telling you bad news early.
Same incident, run properly
Take the same 02:14. The lead opens with the time constraint rather than the question: "We have roughly ten minutes before failover gets more expensive than staying put. I'm going to make this call at 02:25 either way."
Then directed questions, by name, with a time box. "Three minutes: what's the replication lag and when did we last verify the secondary?" Not "what does everyone think", which invites nine answers, but a specific question to the person most likely to have the answer.
At 02:24 the lead says the decision, the reason, and the fallback: "We're failing over. Replication lag is under a minute and the risk of sitting here is higher than the risk of the switch. If the secondary doesn't come up clean within fifteen minutes we roll back and we ride it out until the hardware team gets on site."
Ten minutes, one accountable decision, everyone clear on what happens if it's wrong. Notice the lead still consulted. They just did it inside a structure where a decision was always going to come out of the other end.
Then on the Tuesday, in daylight, the review is entirely democratic. Should the failover threshold have been different? Why hadn't the secondary been tested since last March? That's the right conversation for a reversible improvement, and it is exactly the wrong conversation for 02:14.
Where servant leadership actually earns its keep
None of this is an argument against it. Ninety per cent of your week is reversible, unhurried, and full of people who will do better work if you clear obstacles and then get out of the way. That's where teams are built, where people grow, and where you get the credibility you spend on the night you have to say "I'm making the call".
The credibility is the point. A leader who serves the team consistently for six months can go directive for ten minutes and nobody blinks. A leader who is directive by default has nothing in the account when it matters.
The recommendation
Before your next incident, not during one, write down two lines and put them where your team can see them: who makes the call when the room can't agree, and how long they get before they have to.
One name and one number. Agree it in a calm room on a Wednesday afternoon. The value of that is not in the document. It's in never having to work it out at 02:14 with nine people listening.
Principal Architect
Founder of the Institute of Technical Leadership, writing from two decades of technical delivery.


