Quick take
Managers multiply through people. Tech leads multiply through systems. Pick based on what drains you least, not what sounds prestigious.
The fork nobody prepares you for
Every strong engineer eventually faces this question. Do you go into management, or do you stay technical and lead from there?
I’ve been on both sides of this at the fintech startup. When we were small, I did both. Ran architecture decisions, hired engineers, handled 1:1s, reviewed code. It was unsustainable. Once we grew past a handful of engineers, I had to pick. And more importantly, I had to figure out what each role actually demanded so we could hire and promote into them properly.
Here’s what I learned.
Side-by-side breakdown
| Engineering Manager | Tech Lead | |
|---|---|---|
| Primary focus | People, process, delivery | Architecture, code quality, technical direction |
| Typical day | 1:1s, standups, cross-team syncs, hiring calls | Code reviews, design docs, debugging hard problems, prototyping |
| Authority | Direct — owns performance reviews, promotions, team composition | Indirect — influences through proposals, standards, and example |
| Codes? | Sometimes, in small teams. Shouldn’t be on the critical path. | Yes. Expected to ship meaningful work. |
| Accountable for | Team health, velocity, retention, stakeholder alignment | System quality, technical debt, architectural coherence |
| Hardest part | Difficult conversations. Firing someone. Navigating politics. | Being responsible for outcomes you don’t directly control. |
| Reward | Watching people grow. Team shipping without drama. | Shaping a system. Solving the problem nobody else could crack. |
That table is the short version. Let me expand on the parts that aren’t obvious.
What an engineering manager actually does
Most of the job is invisible. You’re clearing the path so your team can build. Hiring the right people, onboarding them fast, giving honest feedback, shielding the team from organizational noise. None of that shows up in a commit log.
At the fintech startup, I made a rule for myself: if I was writing production code as a manager, something was wrong. Either I hadn’t hired well enough, or I was clinging to the IC identity. Both are problems.
The trap is thinking management is a promotion from engineering. It’s not. It’s a career change. You stop building things and start building an environment. Completely different skill set. If you hate ambiguity, dislike repetitive conversations, or need the dopamine of shipping code daily — you will be miserable. I’ve seen good engineers become terrible managers because nobody told them this upfront.
What makes a great EM: you actually care about people’s careers. Not performatively. You enjoy the puzzle of team dynamics. You can sit in a room full of competing priorities and walk out with a plan everyone tolerates.
What a tech lead actually does
The tech lead owns the “how.” You decide the architecture, set coding standards, break ties on technical debates, and make sure the system doesn’t rot while the team ships features.
You still write code. That’s non-negotiable. A tech lead who stops coding loses credibility fast. But you also spend a surprising amount of time communicating. Explaining tradeoffs to product managers. Writing design documents. Mentoring junior engineers through code review. The ratio shifts — maybe 50% coding, 50% everything else — but the code stays.
The frustrating part? You’re accountable for the system but you don’t control the people building it. You can’t assign tasks or run performance reviews. You lead by influence, by being right often enough that people trust your judgment. If your ideas are bad, or if you can’t communicate why they’re good, you have nothing.
At the fintech startup, our tech leads owned specific domains. One person owned the data pipeline architecture. Another owned the API layer. Clear ownership, clear accountability. No committees.
How to choose
Forget the title. Look at how you spend your energy.
After a day of back-to-back 1:1s, are you energized or drained? After eight hours deep in a codebase, do you feel alive or lonely? The honest answer points you in the right direction.
Better yet — test it. Before you commit to either track, volunteer for the work. Mentor a junior engineer for a quarter. Run a sprint planning cycle. On the tech side, drive an RFC through to implementation. Own a migration. Lead a postmortem.
The title matters less than the work. If you’re doing the work and it fits, the title will follow.
The hybrid trap
We tried the “tech lead manager” thing at the fintech startup when the team was four people. I was doing both. It sort of worked until it didn’t. You end up being mediocre at two jobs instead of good at one. Skipping 1:1s because you’re deep in a debugging session. Skimping on code review because you have a hiring pipeline to manage.
If your company is small enough that one person must do both — fine, just know it’s temporary. Plan the split before you need it.
One more thing
Management isn’t a promotion. Tech lead isn’t a consolation prize. I’ve met directors who would’ve been happier as principal engineers and staff engineers who secretly wanted to run a team. The industry does a bad job of framing these as equal. They are.
You can switch tracks. People do it all the time. But switching costs something — you lose momentum, you rebuild credibility, and skills you don’t use will fade. So pick deliberately, try the work before you commit, and don’t let someone else’s career ladder define yours.