What a Staff Engineer Actually Does Day-to-Day

“So… do you still write code?”

I get this question constantly. From recruiters, from friends outside tech, and, most painfully, from junior engineers who seem worried that career progression means eventually being promoted away from the thing they love.

The short answer: yes, I write code. The longer answer is more interesting, and honestly, weirder than I expected when I first stepped into the role.

The “senior who doesn’t code” myth

There’s a persistent misconception that Staff Engineer is just a fancy title for someone who attends architecture meetings and draws boxes on whiteboards. A sort of engineering middle-manager who traded their IDE for Google Docs.

That’s not it. Not even close.

I still open my editor every day. I still debug production issues at inconvenient hours. I still get that dopamine hit from a clean refactor. The difference isn’t that I stopped coding. It’s that coding became one tool in a larger toolkit, not the whole job.

How the time actually splits

People love asking for percentages, so here’s an honest breakdown of a typical week. This will vary wildly depending on what’s on fire, but roughly:

• Coding & prototyping: ~30% — Writing code, spiking on new approaches, building proof-of-concepts. Often this is the gnarliest code nobody else wants to touch — migrations, performance-critical paths, cross-system integrations.
• Code review & technical guidance: ~20% — Reviewing PRs, yes, but also sitting with engineers and talking through approaches before they write the code. The best review happens before the first line is written.
• Architecture & strategy: ~20% — Writing technical proposals, evaluating trade-offs, defining how systems should evolve over the next 6-18 months. This is the whiteboard stuff, but it’s grounded in real code, not abstract hand-waving.
• Mentoring & unblocking: ~15% — Pairing sessions, career conversations, helping someone see a problem differently. Sometimes this looks like teaching; more often it looks like asking the right questions until someone teaches themselves.
• Meetings & communication: ~15% — Syncs, planning sessions, stakeholder updates. I won’t pretend I love this part, but the meetings I’m in tend to be the ones where technical decisions get made or unmade, so showing up matters.

The ratio shifts constantly. Some weeks I’m 80% coding because we’re in crunch on a critical project. Other weeks I barely touch my editor because three teams need alignment on a shared platform decision. The ability to context-switch between these modes is, honestly, the core skill of the role.

From best IC to force multiplier

This is the career transition that nobody prepares you for (I wrote about it in From Senior to Staff): the thing that got you promoted — being an exceptional individual contributor — is no longer the thing that makes you effective.

Early in my Staff tenure, I’d catch myself instinctively grabbing the hardest ticket on the board. It felt productive. It felt like I was earning my keep. But I was actually creating a bottleneck and robbing a senior engineer of a growth opportunity.

The mental shift is this: your output is no longer measured by what you ship. It’s measured by what everyone around you ships, and how well they ship it.

That means sometimes the highest-leverage thing you can do is spend an hour helping someone design an approach that saves them a week of rework. Or writing a one-page technical decision document that prevents three teams from building the same thing differently. Or saying “actually, we should not build this” and saving six months of wasted effort.

It’s an uncomfortable transition. You go from clear, tangible output (“I built this feature”) to fuzzy, indirect impact (“I helped the organisation make better technical decisions”). Your calendar will feel less productive even when your impact is higher.

Driving direction without authority

Staff Engineers have a strange amount of influence and essentially zero authority. You can’t tell anyone what to do. You don’t control headcount, budgets, or roadmaps. You’re not anyone’s manager.

So how do you actually drive technical direction across teams?

You build trust through competence. When you’ve debugged enough hairy production incidents and your architectural predictions have been proven right a few times, people start listening. This can’t be shortcut.

You write things down. A well-written RFC or technical proposal does more to align an organisation than a dozen meetings. I’ve seen a single document change the direction of a multi-team initiative because it clearly articulated trade-offs that had been hand-waved over in meetings for months.

You create alignment through conversation, not decree. I spend a surprising amount of time just… talking to people. Understanding what different teams are building, where they’re stuck, what they’re worried about. Then connecting dots between teams that don’t know they’re solving the same problem.

You pick your battles. You cannot care about everything equally. The fastest way to lose influence is to have a strong opinion on every technical decision. Save your political capital for the decisions that actually matter.

The uncomfortable parts nobody warns you about

Let’s be honest about the downsides.

Imposter syndrome gets worse, not better. When your output was code, you could point at things and say “I did that.” When your output is influence and alignment, some days you wonder if you did anything useful at all.

You will be in meetings where you’re the only person who understands the technical implications of a business decision, and you’ll have about 90 seconds to articulate why it matters before the conversation moves on. This is a skill I’m still developing.

Context-switching is relentless. In a single afternoon you might go from reviewing a junior engineer’s first PR to debating database migration strategy to explaining to a product manager why “just add a cache” isn’t a solution. Your brain will feel like browser tabs you forgot to close.

Saying no is now part of your job. Not to be difficult, but because you can see the broader system and where complexity is accumulating. This makes you unpopular sometimes. That’s fine.

Why it’s the best role in engineering

Despite everything I just said — the ambiguity, the imposter syndrome, the meetings — Staff Engineer is the best role in software engineering.

You’re close enough to the code to stay sharp and enjoy the craft. You’re senior enough to influence the direction of real systems. You get to mentor people and watch them grow into roles you helped them see. You solve problems that span teams and systems, which are the most intellectually interesting problems in the building.

The best days are when a technical strategy you championed pays off, or a junior engineer you mentored gets promoted, or a system you designed handles 10x the load without flinching. That satisfaction is something writing code alone never quite matched.

It’s messy, it’s ambiguous, and some days I still just want to put my headphones on and write code for eight hours straight. Sometimes I do exactly that, and those are good days too.