Every few months, a senior engineer asks me what I actually do all day. They’ve been heads-down shipping features, they look up, and they wonder what comes after senior. The honest answer catches them off guard: most of my week has nothing to do with writing code.
When I first stepped into the staff role, I expected to write the hardest code and design the most complex systems. I was wrong about all of it. The role is less about being the best individual contributor and more about making everyone around you better. That shift is genuinely disorienting the first time you experience it.
“A Staff Engineer is not just a Senior who has been around longer. The role is a discrete step that requires a different set of skills, behaviours, and perspective.” — Will Larson, Staff Engineer
The Typical Week
Here is what a real week looks like — not the idealized version, the actual one.
| Day | Morning | Afternoon |
|---|
| Monday | Technical strategy review, update architecture roadmap | RFC review for two teams, async feedback on design docs |
| Tuesday | Deep coding block (migration tooling) | 1:1s with two engineers I mentor, team sync |
| Wednesday | Cross-team alignment meeting (API contracts) | Prototype for a proposed caching approach |
| Thursday | Write strategy doc for next quarter’s platform direction | Code reviews (6-8 PRs), incident review |
| Friday | Open source contributions, learning block | Ad-hoc pairing sessions, write weekly update |
The ratio shifts depending on company stage and team size. In a smaller startup, I coded closer to 50% of the time because every hand mattered. In a large engineering organization with hundreds of engineers, it dropped to roughly 20% because the coordination surface area was massive.
From Best IC to Force Multiplier
The hardest part of becoming a staff engineer is accepting that your individual output matters less than your organizational output. At senior level, you are rewarded for shipping great code fast. At staff level, you are rewarded for making entire teams ship great code faster.
Your metrics change completely:
| Senior Engineer Measures | Staff Engineer Measures |
|---|
| Features shipped | Architectural decisions unblocked |
| Code quality of personal PRs | Engineers who leveled up through your mentorship |
| Technical complexity handled | Cross-team conflicts resolved before they became crises |
| Velocity and throughput | Bad technical bets the org avoided |
The Lonely Middle Ground
Here is something I wish someone had told me earlier: staff engineering can be lonely. You are no longer purely part of the engineering team’s daily rhythm. You sit in meetings with directors and VPs where you are the only IC. You think about problems on a six-to-twelve month horizon while your team thinks week-to-week.
The engineers on your team respect you but see you as somewhat separate — the person who shows up to standups sometimes but spends most of the day in “mysterious meetings.” The managers include you in leadership discussions, but you are not a manager. You exist in an organizational gap.
| Relationship | How It Feels |
|---|
| With your team | You’re present but not fully embedded in daily flow |
| With other staff engineers | Your true peers, but scattered and rarely in the same room |
| With managers and directors | Included in strategy, but you don’t carry the people-management weight |
| With senior leadership | You translate between technical reality and business goals |
If you do not actively maintain your technical skills, the gap between you and the codebase widens fast. Block at least two half-days per week for hands-on coding. It keeps you credible, keeps you grounded, and honestly — it keeps you sane.
Writing as a Core Competency
I write more documents than code at this point, and I am not exaggerating. RFCs, strategy docs, architecture decision records, one-pagers for leadership, post-incident reviews. The written word is how staff engineers scale their influence beyond the meetings they attend.
A well-written RFC saves dozens of hours of meetings. A clear strategy document prevents months of misaligned work. A solid architecture decision record means you do not have to re-explain the same trade-off to every new hire for the next two years.
If you are aspiring to staff, start writing now. Write design docs for your features even if your team does not require them. Write post-mortems that capture real lessons. Write proposals for problems you see. Your writing portfolio matters more than your code at this level.
Navigating the Breadth-vs-Depth Tension
You need to understand enough about a dozen different systems to make good cross-cutting decisions, but you also need to go deep enough on a few of them to maintain credibility and spot real issues in reviews.
My approach: maintain deep expertise in two or three areas and cultivate “dangerous enough” knowledge in everything else. Pair with specialists when you need to go deeper on something outside your core. The key is radical honesty about what you do not know. Staff engineers who pretend to be experts in everything lose trust fast. Staff engineers who say “I don’t know enough about this — let me bring in someone who does” build trust just as fast.
Is It Worth It?
Some days I miss the simple satisfaction of writing a function, watching tests go green, and shipping a feature. There is a clarity to individual contribution that gets muddied at the staff level.
But then I see an engineer I mentored get promoted. Or I watch a cross-team migration go smoothly because we spent three months building consensus. Or I read a design doc from a team I have never worked with directly, and it follows the patterns I championed — not because I told them to, but because those patterns proved themselves.
The blast radius of your impact is genuinely different. And for me, that trade-off is absolutely worth it.