Engineering Leadership

At some point the highest-leverage thing an engineer can do stops being writing code. It becomes deciding what the team builds, making sure the people building it aren't blocked, and creating the conditions where good work is the normal outcome. That transition catches people off guard, because the feedback loops get much longer and the definition of "done" gets much less clear.

Two distinct paths lead there. The tech lead stays technical and owns direction, architecture, and delivery for a team. The engineering manager owns the people — growth, performance, hiring, and the team's health as a system. They overlap and are frequently held by the same person at small companies, but the skills differ enough that treating them as one role is how good engineers become unhappy managers.

Most of the craft here is unglamorous and repeatable: consistent one-on-ones, a real onboarding plan, blameless postmortems, an honest position on technical debt, and metrics that describe the system rather than rank individuals.

TL;DR

Two Tracks

Featured Topics

Roles

Working With People

Running the System

Common Questions

Should I go into management?

Only if the work itself appeals to you, not because it's the next box. Management means your output is the team's output, your feedback loop stretches from hours to months, and most of your day is conversations, context-switching, and decisions made with incomplete information. Many strong engineers are happier and more impactful on the staff-plus IC track, which also carries scope and influence. Trying management and returning to IC work is common and carries no stigma at healthy companies — do it as an experiment rather than a commitment.

How do I lead without authority?

That's the ordinary condition of a tech lead, and it's mostly about credibility and clarity. Be the person whose technical judgment holds up, explain reasoning rather than issuing conclusions, write decisions down (ADRs) so they survive without you re-arguing them, and delegate real ownership rather than tasks. Influence comes from people wanting your input; it evaporates when you're seen as routing work rather than doing it.

How should I measure my team's performance?

Measure the system, not the people. DORA metrics — deploy frequency, lead time for changes, change failure rate, time to restore — describe how well the delivery pipeline works and point at real bottlenecks. Individual output metrics (commits, story points, lines of code) are gamed the moment they're tracked and damage the collaboration you need. For individuals, use the qualitative signals: scope handled, quality of judgment, and impact on others' effectiveness.

What do I do about technical debt the business won't fund?

Stop asking for "refactoring time" and start pricing the debt. Attach it to outcomes leadership already cares about: this module causes 40% of our incidents, that coupling adds two weeks to every feature in the area, this dependency is unsupported and blocks the compliance audit. Then propose incremental payment — a standing capacity allocation, or paying down debt in the areas you're already touching — rather than a rewrite. See Technical Debt.

My best engineer wants to leave. What now?

Find out why before trying to fix it, and expect the stated reason to be incomplete. Compensation is often the surface answer for growth, autonomy, or a manager problem underneath. A counteroffer that changes only money usually delays the departure by months. The durable lesson is that this is a one-on-one failure — retention problems are almost always visible for a quarter before anyone resigns, if the conversations are the kind where people say true things.

Related Hubs