Tech Lead vs. Engineering Manager vs. Staff Engineer

How to Know What's Right for You

In 2017, Charity Majors was having drinks with a friend, an engineering manager who’d been in the role for about a year. By the second drink, she was giving him the same advice she’d given countless others before:

“Go back to engineering. For your own happiness and mental health.”

She could see what he couldn’t: he was drifting too far from code, and it would cost him.

She went home and wrote “The Engineer/Manager Pendulum”—one of tech’s most referenced posts. The idea: the best managers stay close to hands-on work. The best engineers have managed. You don’t pick a lane forever. You swing back and forth.

Charity knew this because she’d lived it—engineer, manager, engineer again, across multiple companies.

But here’s what nobody tells us: the pendulum only works if you know which direction to swing.

The pendulum isn’t random. You don’t just swing blindly between roles hoping something sticks. Each swing should be intentional—you investigate, you try it, you commit for a few years.

What these roles actually are

Let me give you the simplest possible breakdown.

Tech Lead means you’re still writing code, but you’re also making the technical decisions for your team. You’re designing systems, unblocking people, breaking down projects, and coding the hard parts. You’re in it.

Engineering Manager means you’ve stopped writing production code. Now you’re focused on people—hiring, growing your team, clearing obstacles, translating between business and engineering. You’re still technical enough to make good decisions, but your job is making your team effective.

Staff Engineer means you’re solving problems too big for one team. You’re setting technical direction across teams, building systems everyone needs, or diving into the hardest problems nobody else can solve. You influence through proposals and prototypes, not authority.

That’s the theory.

Here’s reality: at some companies, tech leads code 70% of the time. At others, 30%. At some places, engineering managers review every design doc. At others, they haven’t looked at code in years. Some staff engineers work across ten teams. Others are just senior engineers with fancier titles.

The titles don’t tell you what the job actually is.

So how do you figure it out?

Stop looking at titles. Start looking at work.

If you’re at your current company

Find three people in each role. Ask them what they did yesterday. What they did last week. What their last three projects were.

Don’t ask “do you like your job?” That tells you nothing.

Ask:

• “Walk me through your calendar yesterday”

• “What percentage of your time is coding vs meetings vs writing?”

• “What’s the hardest part nobody warned you about?”

• “How much autonomy do you actually have?”

You’ll learn more in three conversations than from any job description.

If you’re interviewing

Same thing. Talk to people doing the role. Look at their actual work.

For tech leads: “Can I see a design doc you wrote? What was the last technical decision you made?”

For engineering managers: “How technical do you need to be here? Give me an example.”

For staff engineers: “Show me something you shipped. How long did it take to get buy-in?”

Watch for the red flags:

Tech Lead red flags:

• Nobody can explain what tech leads do that senior engineers don’t

• They’re in meetings all day with no time to code

• There’s no clear next step after tech lead

Engineering Manager red flags:

• They’re managing 15+ people (impossible to do well)

• They seem stressed and underwater

• Technical decisions happen without them

Staff Engineer red flags:

• The company has one or two staff engineers total

• They seem frustrated or bored

• Nobody can explain what problem they solve

What do you actually want to do?

Forget the titles for a minute. What kind of work do you want to be doing every day?

You might want to be a Tech Lead if:

You love coding, but you also love being the person who figures out what to build. You like making architectural decisions. You enjoy mentoring people by working alongside them. You want to shape the technical direction of a project while still implementing the hard parts yourself.

You’re comfortable context-switching between coding and coordination. You can handle being responsible for the team’s technical decisions even when you’re not writing every line.

What this feels like when it’s working: You spend your morning in a design review you led, your afternoon knocking out a critical feature, and you end the day unblocking two engineers. You’re tired but you built something real and helped your team move forward.

You might want to be an Engineering Manager if:

You’re genuinely interested in people problems. Not as a break from “real work”—you actually find it fascinating why some teams click and others don’t. Why someone’s struggling and how to help them grow.

You’re comfortable with slow feedback loops. You won’t see the impact of your work for months. You plant seeds and trust they’ll grow.

You can handle ambiguity and politics. You’re the buffer between your team and organizational chaos. You’re translating business goals into engineering work and engineering reality into business language.

What this feels like when it’s working: Someone you hired just shipped their first major project. Someone else on your team just got promoted. Your team’s delivery is smooth and people actually want to work here. You didn’t write any code, but you made all of that possible.

You might want to be a Staff Engineer if:

You see technical problems that span teams and you can’t let them go. You’re willing to spend three months writing proposals, building consensus, and convincing people when you have zero authority.

You’re comfortable operating in ambiguity. Success metrics are fuzzy. Half your impact is invisible. You’re patient enough for this.

You want deep technical impact without managing people. You’d rather spend a week getting buy-in for the right architecture than spend a week in 1:1s.

What this feels like when it’s working: You just spent four months getting five teams to migrate to a new system. It was slow and frustrating and political. But now those teams can move twice as fast, and you’re the reason why.

The match has to work both ways

Here’s where people mess up.

They want to be a staff engineer because it sounds cool, but their company is 80 people and doesn’t have real cross-team problems yet.

Or they want to stay technical so they become a tech lead, but their company treats tech leads as project managers who barely code.

Or they go into management because it seems like “the next step,” but they hate being away from the code.

You need two things to be true:

1. You want to do this kind of work

2. This version of the role actually exists at your company

If both aren’t true, you’re going to be miserable.

Try it before you commit

Talking to people tells you what the role actually is at your company. Trying it yourself tells you whether you’ll like doing it. You need both. Someone else’s dream job might be your nightmare.

Want to be a tech lead? Volunteer to lead the technical direction on the next project. Do it for three months. Notice: Do you miss coding more? Does the coordination energize or drain you?

Want to be an engineering manager? Ask to shadow your manager. Lead a retrospective. Help with the next hire. After six months, you’ll know if people problems interest you or exhaust you.

Want to be a staff engineer? Pick a problem affecting multiple teams. Write a proposal. Try to get buy-in. You’ll find out fast if you can handle the slow influence work.

You’ll know in your gut if it fits.

What actually matters

Here’s what I’ve learned watching people navigate these choices:

The title matters way less than the work. You can be a “Staff Engineer” and be miserable because the role isn’t real at your company. You can be an “Engineering Manager” and love it because your company gives you the right balance.

Different people find meaning in different kinds of impact. Some people light up when they ship a feature. Others when they unblock a team. Others when they see someone they mentored succeed. There’s no hierarchy here—just different ways to contribute.

Your company context is everything. A tech lead at a 50-person startup looks nothing like a tech lead at Google. Know what you’re signing up for.

Start here

Three questions:

1. What kind of daily work do I want to be doing in 2-3 years? Be specific. Not “I want to lead”—lead how? Through code? Through people? Through influence?

2. What do these roles actually look like at my company? Talk to people. Look at their calendars. Look at what they shipped.

3. Is there a real match? Or am I trying to force something that doesn’t exist here?

If there’s no good match where you are, the answer isn’t “which role?” It’s “which company?”

The real point

Here’s what Charity understood that most people miss: your career isn’t a ladder you climb and get stuck on. It’s not a choice you make once at 30 and live with forever.

It’s a pendulum.

The people who get stuck aren’t the ones who pick wrong. They’re the ones who refuse to swing.

Don’t do that.

Figure out what work makes you feel alive. Find a company where that version exists. Do it for a few years. Then when you get restless, swing the other direction.

Tech lead lets you shape systems while building them. Engineering manager lets you multiply impact through people. Staff engineer lets you solve the hardest cross-team problems.

All three are good for different people at different times.

The trick isn’t picking the right one. It’s knowing when to swing.

P.S. If you want my help with that next step, I’m opening a private group for senior+ engineers aiming for tech lead.

Video courses. Expert workshops. Q&A calls. 1:1 support.

👉 Join waitlist