The Six Leadership Styles, and the One That Quietly Destroys Trust

"So, thoughts? I really want to hear where everyone lands on this before we commit."

Two of us already knew the vendor had been selected. The order form had gone to procurement on the Friday. The meeting was on the Tuesday.

A quick pass, because you've probably met all of these and may not have named them.

Servant is you removing obstacles so the team can work. Democratic is the team deciding and you counting the votes honestly. Consultative is you gathering input and then deciding yourself. Commander and chief is you deciding and telling, which has a bad reputation and is exactly right during an incident or when the team genuinely has no basis to form a view. Coaching is you deliberately trading short-term speed for someone's growth, letting them run something you could do faster. Laissez-faire is you handing over a whole area to people who have earned it and then actually staying out of it.

Six modes. Every one of them correct somewhere. The skill is reading urgency, risk and how much the team has done this before, then picking one on purpose rather than defaulting to whichever one matches your temperament.

Most people can learn that in a quarter. What takes longer is noticing that one of these six is far easier to fake than the others, and that faking it does more damage than any amount of blunt direction.

Here's my position, and I'll defend it. Fake consultation damages trust faster and more permanently than any of the behaviours that get warned about in leadership training.

Think about why. If you're directive and abrupt, people know where they stand. They may not love it, but the contract is clear: you decide, they execute, and if it goes wrong it's on you. That's an honest deal.

Consultative leadership offers a different deal. I'll take your input seriously, then I'll make the call. Also honest, also fine, and it's the mode most technical leaders spend most of their time in, correctly.

The failure mode is running the ritual of it with the decision already made. You book the workshop. You put up the options. People spend real effort preparing, they argue the trade-offs, they bring data. And then the outcome is the thing you'd already chosen, and everyone works out why within a week, because engineers are extremely good at noticing when the evidence didn't change the answer.

What you've spent isn't a meeting. You've spent their willingness to bring you things.

Worked example, and this one is common enough that you may recognise it.

A 9-person SRE team at a retail bank is choosing between two approaches for a new internal API layer in front of the card platform. The lead runs it properly on the surface: a two-week spike, two engineers each building a thin prototype, a two-hour session to compare, everyone invited.

The session goes well. Approach B wins on operational cost and the group more or less agrees. A week later, the decision record says approach A, with a paragraph about strategic alignment that nobody in the session had heard before.

Approach A may well have been the right answer. That isn't the problem. The problem is that the constraint driving it, a commitment made at a level above the team, existed before the spike started and was never mentioned. Two engineers spent two weeks building a prototype that was never in the running.

Here's what happens next, and it happens quietly. The following quarter, there's another architecture decision. The invitation goes out. Attendance is fine, because attendance is compulsory. But the prep is thinner. The arguments are shorter. Two of the strongest engineers say almost nothing and agree with whatever the lead seems to be leaning towards, because they've concluded that the lead's lean is the only variable that matters.

That team is now measurably worse at making decisions, and nobody has complained about anything. Nothing appeared in an engagement survey. The lead's read is that the second session was more efficient.

The fix is almost embarrassingly small, and it costs you one sentence at the top of the meeting.

Tell people which kind of conversation this is. "This one's yours, whatever you decide I'll back." Or "I want your input and I'm making the call by Thursday." Or "This is already decided above us and I'm not able to change it, so this session is about how we implement it well, not whether." All three are respectable. Any of them beats letting people guess.

The third one takes nerve, because you're admitting you don't control something. Do it anyway. Engineers are fine with constraints. What they are not fine with is discovering that a constraint existed and you let them waste a fortnight pretending it didn't.

And a related habit worth building: when you do consult and then go the other way, say so explicitly and say why. "The group preferred B. I've gone with A because of a commitment on contract renewal timing that I hadn't shared, which was my mistake." You'll feel exposed writing that. It buys back more credibility than a year of agreeable meetings.

One more thing while we're here. Requiring full consensus before anything moves is its own kind of hiding, dressed up as respect for the team. If everyone agreed, nobody decided, and somebody has to be accountable for the call. Your job includes ending conversations.

Look at the next one in your calendar. Write a single line at the top of the agenda, in the invite, before you send it, saying which of these it is: the team decides, you decide with their input, or the decision is already made and this is about execution.

If you can't write that line honestly, you've found the meeting you shouldn't be running in its current shape. Change it, or say out loud what it actually is.