Staff Engineer vs. EM: What My Calendar Actually Looked Like in Both Roles

I've shipped code at 2 AM before a funding round closes. I've also sat across from an engineer telling them their role was being eliminated. Both experiences changed me, and both taught me something the internet's endless "staff engineer vs. engineering manager" articles won't tell you. The question itself misses the point.

After six early-stage startups, three exits, and two decades of watching engineers agonize over this fork in the road, I can tell you that asking "which path is better?" is like asking whether drums or bass matters more to jazz. It depends on the song. Depends on the band. Depends on what makes you want to show up and play.

What you actually need is a framework for understanding yourself, not a pros-and-cons list written by someone who doesn't know you. That's what I'm giving you here: a structured self-assessment that engineers at FAANG companies have used to make this decision, plus a practical "shadow week" approach I've seen work at companies from seed stage to IPO.

What Staff Engineers and Engineering Managers Actually Do Day-to-Day

Forget job descriptions. HR writes them and nobody reads them. Let me show you what actually fills your calendar in each role.

Staff Engineer Reality

When I was operating as a staff-level IC at a Series B company, my typical week looked like this:

Monday: Four hours writing a design doc for a system migration. Two hours in architecture review, mostly listening and asking questions that made people uncomfortable.
Tuesday: Pair programming with a mid-level engineer stuck on a gnarly concurrency bug. Another hour talking the PM off a ledge about scope.
Wednesday: Cross-team sync where I'm the "glue" translating between infrastructure and product teams. Wrote maybe 200 lines of code.
Thursday: Deep focus work. Finally. Prototyping a new caching approach. This is the day that feeds my soul.
Friday: Code reviews, mentoring conversations, one 1:1 with the EM who wants my read on team dynamics.

Notice something? My time spent on actual coding varied wildly. Various surveys suggest senior and staff engineers spend anywhere from 20–50% of their time coding, depending on organization and role. Everything else was influence, communication, and technical decision-making that didn't require a keyboard.

Engineering Manager Reality

Compare that to when I briefly stepped into an EM role during a leadership gap:

Monday: Five 1:1s back-to-back. Career conversations, project blockers, one difficult discussion about performance.
Tuesday: Sprint planning, roadmap review with product, capacity planning spreadsheet that made me question my life choices.
Wednesday: Interview loop for a senior hire. Hiring committee. Wrote zero code.
Thursday: Team retrospective, escalation from another team about a missed commitment, context-switching between technical decisions I no longer had time to deeply understand.
Friday: Performance calibration prep, headcount justification for next quarter, catching up on Slack threads I'd ignored all week.

So here's the thing about the IC versus management track distinction in software engineering: it isn't about technical versus non-technical. It's about which flavor of non-coding work energizes you.

Staff engineers still spend enormous time communicating, but their leverage comes from technical credibility. Managers spend their time building systems of people rather than systems of code.

A 5-Question Self-Assessment Framework (With Scoring Guide)

When engineers ask me "should I become a staff engineer or manager," I run them through these five questions. Be honest. Nobody's watching.

Question 1: What's Your Relationship with Ambiguity?

Scenario: A project is failing. Requirements keep shifting. Nobody agrees on the technical approach.

(A) I want to grab the keyboard and prototype three solutions to prove which one works. Show, don't tell.
(B) I want to get everyone in a room, align on constraints, and make sure we're solving the right problem before anyone writes code.

If you picked A, that's +1 for staff engineer. B is +1 for engineering manager.

Question 2: How Do You Define Impact?

Scenario: Your team ships a successful product. Which moment makes you proudest?

(A) The architectural decisions that made the system scale, or the elegant solution to a hard technical problem.
(B) Watching a junior engineer you mentored present the work they led, or seeing a struggling team you reorganized finally hit its stride.

A = staff track. B = management track.

Question 3: What Drained You Most in the Last Month?

Think about your most exhausting work experiences recently:

(A) Meetings where people talked about work instead of doing it. Process overhead. Organizational politics.
(B) Deep technical problems where you felt stuck. Extended debugging sessions. Working alone for long stretches.

Now here's the twist: if A drains you, management will be brutal because that's most of the job. And if B drains you, the IC track at senior levels might surprise you with how little pure coding you actually do.

Question 4: What Do People Already Ask You For?

Look at your Slack DMs and calendar invites from the last quarter:

(A) Technical advice, architecture reviews, debugging help, "can you look at this code?"
(B) Career advice, conflict mediation, "how do I navigate this situation with my manager?"

Your current reputation signals where your natural gravity pulls you.

Question 5: How Do You Handle Being Wrong?

(A) I'd rather be wrong about a technical decision because I can test, iterate, and prove the right answer empirically.
(B) I'd rather be wrong about a people decision because relationships are repairable and humans are forgiving.

Staff engineers live or die by technical judgment. Managers? People judgment is the whole ballgame. Which type of mistake scares you less?

Scoring

Count your As and Bs. Four or more in either direction gives you a clear signal. Split down the middle? You might be a good fit for a tech lead role that blends both, or you need more data, which brings us to the shadow experiment.

Salary, Scope, and Career Currency: What Each Path Really Pays

Let's talk money, because anyone who tells you this decision shouldn't involve compensation is either wealthy or naive.

Compensation Comparison

At FAANG and equivalent companies, staff engineer and engineering manager comp is roughly equivalent at paired levels. We're talking $350K–$500K total compensation for Staff/M1, scaling up to $600K–$900K+ for Principal/Senior Staff and Director/Senior Director.

But the real difference is in the ceiling. VP of Engineering can hit $2M+ at large companies. Distinguished Engineer can too, but those roles are rarer. Some large tech companies have more Distinguished Engineers than you'd expect, while VP and SVP counts can range from dozens to hundreds depending on company size and organizational structure.

At startups, the calculus changes entirely. Startup equity often favors managers because they're seen as "leadership." I've watched technical co-founders get smaller refresh grants than the VP of Engineering they hired. Unfair? Maybe. Real? Absolutely.

Career Currency Beyond Cash

Money isn't the only asset you're building. Consider:

Staff engineer currency:

Deep technical expertise that's portable across companies
Open source reputation, conference talks, published work
Ability to join any technical project as an individual contributor
Consulting and advisory opportunities

Engineering manager currency:

Network of people you've hired, promoted, and mentored
Organizational design experience that scales
Ability to build teams from scratch
Board and executive relationships

Choosing between technical lead and management often comes down to which type of career capital you want to accumulate.

A Shadow Week Experiment: Test-Drive Both Roles at Your Current Company

I've recommended this to probably two dozen engineers: before you decide between the IC track and management track, actually experience both. Why do so many people pick based on imagination rather than information?

How to Set It Up

Step 1: Talk to your manager. Say something like: "I'm thinking about my long-term career direction, and I want to make an informed choice between the staff engineer path and management. Would you support me shadowing both roles for a week each?"

Almost all managers will say yes. This shows career intentionality, which they want to see.

Step 2: Find your shadows.

For the staff track: Ask a Staff or Principal Engineer if you can shadow them. Attend their meetings. Watch how they prepare for architecture reviews. See their inbox.
For the management track: Ask an EM (maybe your own, maybe another) to let you observe 1:1s with permission from their reports, attend hiring debriefs, and see how they prep for planning cycles.

Step 3: Take notes on your energy, not just your observations. After each day, write down: What energized me? What drained me? What surprised me?

What You'll Learn

Engineers who do this shadow experiment almost always learn something unexpected. A staff-plus role explained on paper looks different than watching someone actually do it. Same goes for management.

One engineer I mentored was convinced she wanted to be an EM until she shadowed one. "I didn't realize how much of the job is basically therapy," she told me. "I thought I wanted to help people grow. But I want to help them grow technically, not emotionally." She's now a happy staff engineer.

Another engineer was dead-set on staying IC until he shadowed. Watching the EM run a team retrospective and change the whole energy of a struggling team, he said: "Oh. That's what I actually want to do."

You don't know until you see it up close.

Why Switching Between Tracks Is Your Secret Weapon

Nobody tells you this about the pros and cons of staff engineer vs. engineering manager roles: the most effective senior leaders I've worked with have done both.

Consider this. The best VPE I ever reported to had been a Principal Engineer for six years before switching to management. Her technical credibility meant engineers actually listened to her. She could call BS on unrealistic timelines because she understood the work.

And the best staff engineer I've collaborated with spent four years as an EM before switching back. His experience leading humans made him devastating in cross-team negotiations. He understood organizational dynamics in ways that lifetime ICs often don't.

How to Position the Switch

Want to advance your career without managing people, but you've been an EM? Frame it this way: "I developed deep organizational knowledge, and I'm ready to apply that to technical leadership at scale."

Want to move from IC to management? Frame it as: "I've built technical credibility, and I'm ready to multiply my impact through people."

Companies increasingly see pendulum moves as a feature, not a bug. You're more valuable with both perspectives.

So. Staff engineer vs. engineering manager. You've got the framework, the salary reality, the shadow experiment approach, and the permission to switch later.

Your 30-day action plan regardless of which direction you're leaning:

Days 1–7: Complete the 5-question assessment. Write out your answers; don't just think them. Show them to someone who knows you well and ask if they agree.

Days 8–14: Set up your shadow week. Email that staff engineer or EM today. Don't overthink it. Worst case, they say no.

Days 15–21: Execute the shadow. Take those energy notes.

Days 22–28: Have three career conversations with people who've walked both paths. Ask them: "What surprised you most about your current role? What do you miss about the other path?"

Days 29–30: Make your decision. Not a lifetime commitment. Just a next-step decision. You can always adjust.

After decades of building products, I've learned something: the best career decisions aren't about optimizing for the perfect answer. They're about gathering enough information to make a good-enough choice, then executing with conviction.

You can analyze forever. But will it ship?

Make the call. You've got the framework. Now use it.