Engineering Leadership
The skills that got you promoted are the ones you now have to let go of. Engineering leadership is the shift from being valued for what you build to being valued for what your team builds — and almost everything about the job changes at that line. Your output is now indirect, measured through other people, which feels like doing less while being responsible for more. This guide is the map: the transition itself, leading people, making decisions, scaling teams, and leading change.
The trap is universal and worth naming up front: the instinct to keep writing the hard code, reviewing every PR, and making every call. It works right until it doesn't — usually around three reports — and then you're the bottleneck. The job is to build a team that decides well without you, not to be the person everything routes through.
Start here
The Tech Lead Transition — what actually changes when you stop being the senior IC.
The Senior Engineer's Blind Spot — the individual-contributor habit that quietly stalls new leads.
Engineering Strategy Is Just Strategy — tying technical decisions to outcomes people care about.
The transition
The first months in a lead role feel like doing nothing, because the work no longer shows up as commits. Learning to value indirect impact — an engineer who grew, a decision that compounded, a team that shipped without heroics — is the whole transition, and it takes longer than anyone expects. The Engineering Leadership path walks it end to end.
Leading people
Most of leadership is the unglamorous, high-leverage work of helping specific people do their best work: weekly one-on-ones that build trust instead of collecting status, delegation that hands over outcomes rather than tasks, mentoring that's about the other person rather than your own expertise, and hiring the right people and interviewing them well. None of it shows up on a burndown chart, and all of it determines whether the team thrives.
Decisions and direction
Teams rarely stall on bad decisions — they stall on no decision, circling the same question while the work waits. A lead's job is to break that loop: gather input efficiently, separate reversible calls from irreversible ones, make the call, and get real commitment even from the people who disagreed. Then point the team somewhere: a direction clear enough that people can say no to good ideas in service of the right ones.
Make Technical Decisions — decisions your team will actually commit to.
Set Team Direction — turn quarterly goals into this week's priorities.
Scaling teams and culture
Every engineering team slows down as it grows — the ones that keep shipping redesign how they work at each stage instead of just adding headcount. Going from ten to fifty engineers breaks nearly everything that made the small team great, and the fix is deliberate structure plus a culture strong enough to survive the growth. Process tells people what to do; culture tells them what matters.
Leading change
Half of leadership is moving people, systems, and processes from one state to another without breaking everything in between — a reorg, a new process, a migration. Resistance to change is information, not an obstacle: the team is telling you something. The classic frameworks (Kotter, Lewin, Bridges, ADKAR) each offer a useful lens, and a Change Advisory Board, run well, accelerates delivery instead of slowing it.
Measuring what matters
Leadership eventually needs evidence, not anecdotes — but the wrong metrics corrode trust the moment you target them. Delivery metrics like the DORA four tell you whether the team is actually getting healthier; lines of code and commits-per-engineer tell you nothing good. The full treatment lives in the Software Quality Engineering guide, under measuring quality without gaming it.
Frequently asked questions
What's the hardest part of becoming a tech lead? Letting go of the individual-contributor identity that got you promoted. Your output is now indirect — measured through the team — and learning to value that (and to stop being the bottleneck) is the core of the transition. More here.
How do I delegate without quality slipping? Hand over outcomes, not step-by-step tasks; be clear about the stakes; set light check-ins; and — the hardest part — don't snatch the work back the first time it wobbles. The full method.
How do I make decisions faster without making bad ones? Separate reversible ("two-way door") decisions from irreversible ones, gather input efficiently instead of endlessly, make the call, and secure disagree-and-commit. Indecision usually costs more than a wrong-but-reversible choice. Here's how.
What should I measure as an engineering leader? Delivery health — the DORA metrics (lead time, deploy frequency, change failure rate, time to restore) — not activity metrics that get gamed. See the metrics section of the quality guide.
Keep going
The Engineering Leadership path is the hands-on spine of all this — five parts from the transition to setting direction. Pair it with the change-management guides when you're leading a reorg, and the quality metrics work when you need to show the team is improving. Lead through people, decide promptly, and measure what actually reflects health.
