When I started leading teams, I thought my job was to make the best technical decisions. I had opinions about architecture, about how systems should be structured, about what good code looked like. I thought leadership meant applying those opinions at scale.
It took longer than I'd like to admit to realise that the decisions weren't the hard part. The hard part was everything that determined whether those decisions actually happened — how they were communicated, who bought into them, whether the team understood the reasoning well enough to extend them to situations I hadn't anticipated.
The Problem With Being Right
Being right about a technical decision means very little if you can't bring the team with you. I've seen technically correct architectural choices fail in production not because the design was flawed, but because the engineers implementing it didn't understand the constraints it was designed around. They made reasonable-seeming local decisions that violated the architecture's assumptions, and the whole thing unraveled.
The failure wasn't technical. It was a communication failure. The architecture existed in one person's head instead of the team's shared understanding. That's a leadership failure.
What I've Had To Learn
How to explain decisions in terms of the problem they solve, not the solution they represent. Engineers push back on 'we should use CQRS here.' They rarely push back on 'our read and write patterns have completely different consistency requirements — here's why that matters and here's one way we can handle it.' Same destination, very different journey.
How to give people room to own things. The instinct when you care about quality is to stay close to the work. The effect is that the team stops thinking autonomously. The best teams I've been part of had room to make decisions — including decisions I wouldn't have made — and to learn from them. My job was to set the boundaries clearly, not to make every call within them.
How to have the conversation that nobody wants to have. Performance problems, misaligned expectations, work that isn't good enough — these conversations are genuinely uncomfortable, and the temptation is to avoid them or soften them until they say nothing. Doing it badly is worse than not doing it. But not doing it at all is worse than doing it badly.
The Actual Job
I've come to think of technical leadership as context management. My job is to make sure the people doing the work have enough context to make good decisions without me in the room. What are we optimising for? What are the constraints we can't violate? What trade-offs are acceptable and which aren't? Where is quality non-negotiable and where can we move fast?
If the team can answer those questions without asking me, I'm doing my job. If every decision flows through me because nobody has enough context to make it independently, I've built a bottleneck, not a team.
The technical part — the architecture, the patterns, the standards — is still important. But it's upstream of all of this. Getting the people part wrong makes the technical part irrelevant.