Technical leadership without management

You do not need direct reports to lead technically. The levers are designs, standards, a short strategy for an area, and a quality bar in review. The trap is becoming either the hero who ships alone or the person who only multiplies and never touches code.

The levers

Design reviews and RFCs. Show up prepared. Ask the questions that surface risks: data model, failure modes, operability, migration. Leave written feedback that teaches. See design docs.

Standards and glue. Lint rules, CI gates, API guidelines, on-call hygiene, ADRs. Boring standards prevent a thousand one-off debates. Push for standards that reduce cognitive load, not bureaucracy for its own sake — a lesson platform teams learn the hard way (platform engineering).

Tech strategy for an area. "Where should this subsystem be in 18 months?" Write a short strategy: current pain, principles, sequenced bets, explicit non-goals. Strategies that fit on two pages get read. Fifty-page visions do not.

Quality bar in review. Seniors do not nitpick formatting while missing correctness and operability. They model what "good" means and explain why.

Mentorship at this level is structured growth for someone else: pairing on design, reviews that teach, safe first-on-call, and sponsoring visibility (their name on the launch note when they did the work). Track mentee outcomes the way you track metrics: first ship, first design doc, first incident command. If you have no one to mentor on a tiny team, mentor sideways: help a peer team ramp, or write guides that scale beyond one person. See mentorship.

Walking through the balance

A useful personal dashboard for an aspiring senior:

• Coding / designing deeply: enough to lead from reality (often about 40–60% early senior, less at staff)
• Reviewing and unblocking: invest where your comments change trajectories
• Writing: strategies, designs, postmortems, hiring loops
• Mentoring: deliberate, not only drive-by Slack help

Track a month. If coding is 95%, you may be stuck at strong-SDE2 habits. If coding is 5% and everything is meetings, reclaim maker time (productivity and focus) or you will lose the technical taste that makes leadership trustworthy.

Common mistakes

• Nitpicking formatting while missing operability. The bar is correctness and how it runs.
• Fifty-page visions nobody reads. Two pages with non-goals.
• Standards as bureaucracy. They should cut cognitive load.
• All meetings or all heroics. Track the month and adjust.

Check yourself

1. You spent a week writing a 50-page vision for a subsystem. What should you have written? Two pages: current pain, principles, sequenced bets, explicit non-goals.

2. Your month was 95% coding. What is the risk? Strong-SDE2 habits. Leadership needs reviews, writing, and teaching too.

Key takeaways

• Technical leadership uses designs, standards, strategy, and reviews — no reports required.
• Keep coding enough for credibility; spend real time on leverage activities.
• Mentor on purpose and put other people's names on work they did.
• Two-page strategies get read.

Further learning

Next, get agreement to stick in navigating organizations.