Technical leadership

Overview

Past senior, the job stops being "write the hardest code" and becomes "make the group produce better systems than it would without you" — while the org chart may give you no authority to command any of it. Technical leadership is that discipline: choosing what matters, aligning people on it, unblocking more than you produce, and growing the engineers around you. It is a parallel track to management (Fournier's tech lead vs engineering manager split, Larson's staff-plus archetypes), and the skills are learnable, not charisma.

Key points

The archetypes name the job (Will Larson, Staff Engineer): Tech Lead (guides a team's execution), Architect (owns a critical domain's direction), Solver (dropped on the hairiest problems), Right Hand (extends an executive's reach). Knowing which one a role actually is prevents doing all four badly.
Influence without authority is the core mechanic: you get alignment by writing things down (design docs, ADRs, RFCs), building coalitions before the meeting, and being reliably right in public and gracious about it — not by escalating. The currency is trust, accumulated slowly and spent carefully.
Technical strategy is diagnosis, not vision boards (Rumelt via Larson): a hard look at the actual situation, a guiding policy, coherent actions. A strategy that doesn't say no to anything is a mood.
Delegation is the multiplier and the growth engine: hand off problems with context and an owner, not tasks with instructions; the point where "it's faster to do it myself" is true is exactly where delegation starts paying. Sponsorship — putting someone's name on the visible work — grows engineers faster than feedback does.
Glue work is the job, not a distraction (Tanya Reilly): the design review that caught the split-brain, the onboarding doc, the cross-team nudge that unblocked the quarter. Do it deliberately, make it visible, and don't let it be invisibly assigned.
Run the rooms well: design reviews that critique the design rather than audition the reviewer; incident reviews that produce learning, not blame; 1:1s (yes, leads have them too) that surface problems while they're small.
Stay technical, strategically: keep a real (non-critical-path) coding lane; your judgment decays without contact with the code, but the team fails if you hold the critical path hostage to your calendar.

Details

Lead vs manager, without the mythology

The management track owns people outcomes (staffing, growth, performance); the technical track owns system outcomes (architecture, quality, direction). They overlap in the middle and both live or die by communication. The classic failure is treating the lead role as "senior engineer plus meetings" — the work shifts from output to leverage, and calendars, writing, and saying no become the actual tools.

Writing as the leadership medium

Design docs and ADRs are not bureaucracy; they are how a decision scales beyond the room it was made in. The discipline: state the problem before the solution, name the options considered honestly, record the decision and its expiry conditions, and circulate before consensus is needed, not after.

Practice

Write a one-page technical strategy for a real project you own — diagnosis, guiding policy, three coherent actions, and one explicit thing you will not do; review it in three months against reality.
Run an RFC end to end — take a genuinely contested decision on your project, write the RFC, gather async comments, drive it to a recorded decision with an ADR; the drill is the process, not the outcome.
Delegation rep — hand a problem you could solve in a day to someone who will need a week, with context and acceptance criteria but no instructions; your job is restricted to unblocking. Write down what you learned about your own bottleneck-ness.
Design review as a service — review a design (a colleague's, or an open-source proposal) producing only questions and trade-offs, zero prescriptions; leading a review without steering it is the skill.