Technical Leadership
Setting technical direction and raising the standard of decisions across an organisation — largely without authority and largely through other people.
Definition
Technical leadership is responsibility for the quality of technical decisions across a scope larger than one can personally make decisions for. It operates through direction, standards, mentoring and judgement rather than through instruction.
What it involves
Setting direction. A small number of technical goals the organisation is moving toward, stated clearly enough that hundreds of independent decisions align without being individually reviewed.
Establishing what good looks like. Standards, paved roads, review expectations, decision records. The point is that the right thing becomes the easy thing.
Raising the standard of decisions. Mentoring, reviewing reasoning rather than output, and asking the questions that improve judgement — because an organisation making better decisions without you is the actual goal.
Owning the hard problems. The ones nobody else can or will take: the migration nobody wants, the disagreement between two senior people, the decision with no good options.
Representing engineering to the rest of the business, in terms it can act on.
What distinguishes it from being the best engineer
The best engineer makes excellent decisions personally. A technical leader makes the organisation capable of making excellent decisions, which frequently means accepting a decision that is 80% as good and owned by the team over one that is 100% and imposed.
That trade is genuinely uncomfortable and it is the core of the role.
What it requires
- Credibility, earned through having built things and being willing to look at code.
- Judgement about which decisions to be involved in, since being present at everything adds latency and diffuse value.
- Comfort with being wrong publicly, which is what makes your positions credible.
- Restraint. The strongest signal a technical leader can send is not overruling a reasonable decision they would have made differently.
Failure scenarios
- Becoming a bottleneck, with every decision routed through you.
- Overruling too often, so teams stop deciding and start asking.
- Direction stated too vaguely to align anything.
- Losing technical credibility by disengaging from the systems entirely.
- Optimising for being right rather than for the organisation being effective.
Interview question
"What changes when you move from making architectural decisions to being responsible for how an organisation makes them?"