Writing
01 · 12 March 2025 · 2 min read
Why most technical leadership fails at scale
Competence doesn't collapse systems. Poor judgment does.
Technical leadership rarely fails because the leader can't write software anymore. It fails because the organisation starts treating activity as progress, and nobody in charge stops it.
At a small scale, competence covers a lot of ground. A strong engineer can still personally inspect the risky paths, rewrite the brittle service, and sit in on the incident call. That works right up until the system outgrows any one person's working memory. Then the job changes underneath you. The question stops being "can I make this work?" and becomes "what still works when I'm not in the room?"
The competence trap
Teams promote the person who shipped the last hard thing, and that person keeps shipping. Quietly, the organisation turns them into a bottleneck: every design review, every vendor call, every production scare runs through them. Output looks high. What's actually happening is the system becoming more dependent on one person's judgment, not less.
Scale asks for a different kind of competence. You have to make decisions with incomplete information, and then put constraints in place that stop those decisions from rotting over time. Architecture is one of those constraints. So is hiring. So is saying no to a roadmap that would look great in a board pack and fall apart on a Friday night.
Judgment is the product
Poor judgment is expensive at scale because it compounds. A wrong abstraction doesn't just slow one team down, it becomes the default path every team after it inherits. A weak incident culture doesn't just make one outage longer, it teaches everyone that noise is normal.
The leaders who hold up under that kind of pressure tend to do three unglamorous things well. They name the real constraint before they name the feature. They design for the operator, not the demo. And they refuse to let a tool stand in for actual discipline.
None of that photographs well for a case study. All of it is what keeps a system alive once it actually matters.
If you're leading a technical organisation and it still only works because you're personally excellent, you don't have a leadership problem yet. You have a scale problem you haven't admitted to yourself.