Every engineering org eventually has the same conversation. The team is growing, it needs a lead, and the obvious candidate is the senior engineer who knows the system better than anyone — the one who wrote half of it, fixes the incidents nobody else can, and gets tagged on every hard pull request. Promoting them feels like rewarding excellence. What it often does instead is take someone out of the job they're exceptional at and drop them into a job that needs a different set of skills entirely. Six months later they're writing code at midnight to make up for the hours lost to one-on-ones, the team isn't growing any faster, and everyone quietly wonders why the promotion didn't work.
Why the best engineer gets the promotion by default
In too many companies, there's still only one meaningful way up. If an engineer wants a bigger title, more influence, or a substantially higher salary, the path runs through management. So the reward for being great at writing software is a job that involves a lot less writing software. The company isn't choosing the best future lead — it's choosing the best current engineer and hoping the skills transfer. Sometimes they do. But being the strongest individual contributor on a team and being the person who makes everyone else on that team stronger are two different talents, and plenty of people have one without the other.
The habits that make a senior engineer great
A strong senior engineer often becomes the person everyone relies on when something difficult breaks. They know the code inside and out: why that module is shaped the way it is, which table can't be touched on a Friday, and what the comment on line 400 is really warning about. They carry years of context in their head, and that knowledge lets them solve problems faster than almost anyone else. That expertise is enormously valuable. But it can create a dangerous dependency when the organization starts treating one person's knowledge as a substitute for building the team's capabilities.
The trouble starts when that same person has a team. A senior engineer often finds it's faster to just do the work themselves than to explain it to someone else — and in the moment, they're right. Explaining a tricky change takes an hour; making it takes twenty minutes. But every time they take the shortcut, the team learns nothing, the knowledge stays in one head, and the lead becomes the bottleneck for every hard problem. The habit that made them the best engineer — owning the hard parts personally — is exactly the habit that keeps a team from growing past them.
"It's faster if I just do it" is often true in the moment. That's what makes it a trap — the hour you saved today is the same hour you'll spend again next month, because nobody else learned how.
One thing I've learned over years of building and leading software projects is that being the person everyone comes to for answers can feel like success — until you realize that nothing moves without you. If you're the only person who understands the architecture, the team doesn't really own the system; you do. And the more indispensable you become, the harder it is for the organization to grow. At some point, seniority has to stop being about how many problems you can personally solve and start being about how many problems the team can solve without you.
A tech lead isn't the same job as an engineering manager
There's an important distinction here that companies often blur: a technical lead isn't necessarily an engineering manager. A tech lead may still write production code, guide architecture, review designs, and mentor engineers. An engineering manager is responsible for people, performance, hiring, and team effectiveness. In smaller companies, one person may wear both hats. The mistake is assuming that excellence in one role automatically qualifies someone for the other — and the "team lead" job most senior engineers get promoted into is usually some blend of the two, with the people half nobody prepared them for.
What makes a team lead great
A great team lead may not know every aspect of the system — and they don't need to. What they know is how to ask the right questions to figure it out. They can sit down with the engineer who owns a component, ask what's actually blocking them, and come away with a decision instead of a rewrite. They're comfortable saying "I don't know, who does?" and then making sure the answer gets written down so the next person doesn't have to ask.
Their output isn't their own code — it's the team's output. They measure a good week by how many people got unblocked, not how many tickets they personally closed. They give context instead of instructions, let someone take a slower path when it means that person will own the area afterward, shield the team from churn that doesn't need to reach them, and make calls with incomplete information when waiting would cost more than being slightly wrong. None of that requires being the strongest coder in the room. Some of it is actually easier when you aren't, because you're not tempted to grab the keyboard.
What makes each one better
Neither profile is fixed. A senior engineer can become a good lead, and a good lead can sharpen their technical depth — but each has to work on the opposite muscle, and it helps to be specific about what that muscle is.
For the senior engineer stepping into a lead role
- Explain, don't fix — when someone is stuck, ask questions until they find the answer instead of taking the keyboard.
- Get the knowledge out of your head — write the design notes, the runbooks, the "why it's like this" comments nobody else can write.
- Accept a slower first time — let someone else take the hard ticket, even if it takes them three days instead of your one.
- Measure the team, not yourself — a good week is one where other people shipped things they couldn't have shipped a month ago.
For the team lead building technical depth
- Stay close enough to the code — read pull requests regularly so your questions stay sharp and your estimates stay honest.
- Know where the bodies are buried — you don't need every detail, but you need to know which parts of the system are fragile and who understands them.
- Trust your senior engineers on the technical call — your job is to make sure the decision gets made and written down, not to make every one yourself.
- Pick up a small ticket now and then — not to be the hero, but to feel the build times, the flaky tests, and the friction your team lives with every day.
There should be two paths, not one
The real fix isn't better management training for engineers who never wanted to manage. It's giving software engineers two genuine career paths: a management track and an individual contributor track. The management path is for people who get their energy from making a team effective — hiring, coaching, planning, unblocking, and owning delivery. The technical path — staff, principal, and beyond — is for people who want to keep going deeper: owning the architecture across teams, making the hard technical calls, reviewing the designs that matter most, and mentoring through the work itself rather than through a reporting line. Will Larson's Staff Engineer: Leadership Beyond the Management Track makes the case well that senior technical leadership is a real career path, not a consolation prize.
For that to work, the technical path has to go as high as the management one. A senior technical contributor should be able to reach compensation, organizational influence, and recognition comparable to leaders at a similar level of responsibility — without taking on direct reports. If the technical track tops out two levels below the management track, every ambitious engineer will still feel pushed toward management — and you're back to promoting your best coder into a job they never wanted, because it's the only way you could pay them what they're worth.
If the only way to give your best engineer a raise is to stop letting them engineer, your career ladder is the problem — not the engineer.
It's the same mistake companies make in hiring, just turned inward. Judging a senior candidate on how fast they can solve a puzzle measures speed, not senior judgment; promoting a senior engineer because they write the most code measures output, not leadership. In both cases the signal is real — it's just a signal for a different job.
What if your company is too small for two career ladders?
You don't need fifty engineers and a formal HR leveling framework to get this right. If you have five developers, you probably don't need a Distinguished Engineer. You do need a way to recognize the person who owns your architecture without making them responsible for performance reviews, hiring, and vacation approvals.
That might mean giving your strongest technical contributor more ownership over architectural decisions, recognizing that responsibility in their compensation, and letting someone better suited to people management handle the team. The titles matter less than the principle: technical influence and organizational authority don't have to come from the same job.
How to tell which path someone belongs on
Titles and tenure won't tell you. A few honest questions usually will — treat them as conversation starters, not a formal evaluation method.
- When a junior engineer is stuck, does this person instinctively take the keyboard — or start asking questions?
- Do they get more satisfaction from shipping something hard themselves, or from watching someone else ship it for the first time?
- Would they be happy going a full week without writing any production code?
- When a project starts falling behind, does this person focus first on solving the technical problem, or on understanding what's preventing the team from delivering?
Neither set of answers is better. They just point to different roles. And the healthiest organizations make it safe to try one path and come back: a senior engineer who spends a year as a lead and decides they'd rather be a principal hasn't failed, they've learned something important about themselves — and they'll be a better principal for having seen the job from the other side.
Where this leaves you
The best engineering organizations don't just identify talented people. They figure out how to multiply that talent. Sometimes that means helping an exceptional engineer become a great manager. Sometimes it means giving that engineer more technical responsibility while someone else leads the people. And sometimes it means recognizing that the person who holds a team together isn't the person who writes the most code.
The mistake isn't promoting your strongest engineer. It's assuming that being your strongest engineer tells you which job they should do next.
Promote people into the job they'll be great at — not out of the job they're already great at.