The triangle of tech leadership
How I think about the three jobs bundled into most tech lead roles, and why covering all three at once is harder than it looks.
26 Feb 2026
This is the frame I keep coming back to when thinking about tech leadership: three separate jobs, usually bundled into one title. It shapes how I evaluate roles, how I hire, and how I think about team gaps.
The vertices: technical excellence (architecture, technology choices, engineering quality), product delivery (roadmaps, planning, translating ambiguity into something that ships), and people management (capacity, growth, the wellbeing of the team).
One or two, usually
Most leads default to one, maybe two. The ones who claim all three are either exceptional or spread too thin. Usually the latter. Each vertex is a genuine full-time concern if you take it seriously, and the technical and delivery sides alone can fill a week without touching the people dimension at all. Something always ends up getting the leftover attention.
The best leads I’ve worked with knew exactly which vertex they owned. They were deliberate about it, not apologetic.
Where I sit
Technical and delivery are where I operate from. I care about the architecture and I care about what ships. People management is present in my work, but it’s not the dimension I lead from. I function best in teams where someone else holds that vertex with intent, whether that’s an engineering manager or a product lead who genuinely owns the roadmap.
This is not a gap I’m trying to close. A team needs coverage across all three vertices. One person attempting all three at half capacity is worse than a well-structured pair. Team Topologies makes a similar point about cognitive load: every role has a finite capacity for complexity, and team design should respect that. Knowing which vertices you own tells you who you need around you.
That's the bit. Bye.