​

Staff Engineer · Will Larson

“Most career advice presumes the existence of a well-defined path and a well-understood game. For staff-plus engineers, both of those presumptions are wrong.”

​

Why I Picked This Up

I was a senior engineer who’d been told “you’re doing great, keep it up” for two years straight. No promotion, no concrete feedback on what was missing, and no clear picture of what “the next level” actually looked like. I was writing excellent code, mentoring juniors, delivering on time — and plateauing. Will Larson’s book didn’t just describe the staff engineer role. It gave me the vocabulary to understand why I was stuck and the map to navigate forward. For an immigrant engineer in Australia, where the cultural norms around self-promotion and visibility are different from the Silicon Valley playbook, this book was a lifeline.

​

The Four Archetypes

Larson identifies four archetypes of staff-plus engineers. Understanding these wasn’t just intellectually interesting — it was the most important career clarity I’ve ever gained.

​

Finding My Archetype

I spent months trying to be all four. That’s a recipe for doing none well. After honest reflection, I realized I’m a blend of Tech Lead and Architect — I’m most energized when I’m setting technical direction for a team while also seeing the cross-team picture and connecting the dots. The Solver archetype tempted me because it’s exciting and visible. But it’s also exhausting and can become a treadmill where you’re always fighting fires without building anything lasting. The Right Hand archetype didn’t fit my personality — I need to be hands-on with technology, not operating as a proxy for someone else’s vision.

​

The Archetype Nobody Talks About

Larson’s framework is clean, but real life is messy. Many staff engineers — especially at smaller companies or in non-FAANG environments — operate as hybrids. I’ve been a Tech Lead who occasionally Solves and sometimes Architects. That’s fine. The archetypes are lenses, not boxes. What matters is knowing your default mode — the archetype you fall into when nobody is directing your work. That’s your true archetype. Mine is Tech Lead. When left to my own devices, I gravitate toward a team, set technical direction, unblock people, and ship.

​

Writing the Promotion Packet

This was the chapter that changed my trajectory. Larson argues that a promotion to staff engineer is never a surprise to the person being promoted — it’s the culmination of a deliberate campaign.

​

My Process

Step 1: Understand the rubric. I got the actual promotion criteria from my manager and HR. Not the vague values poster — the specific behaviors and evidence the committee looks for. If your company doesn’t have a clear rubric, that’s a signal to start writing one with your manager. Step 2: Gap analysis. I mapped my current work against the rubric, honestly. I was strong on technical execution and mentorship. I was weak on cross-team influence and written technical vision. Step 3: Close the gaps deliberately. I volunteered for a cross-team architecture review. I wrote my first RFC that proposed a system-wide change. I started presenting at engineering all-hands. Each activity was chosen to fill a specific gap, not just to “look busy.” Step 4: Assemble the evidence. I kept a running document — a brag doc — with specific examples, metrics, and testimonials for each rubric dimension. By the time the promotion cycle came, my manager didn’t have to advocate from memory. The evidence was compiled, organized, and ready. Step 5: Get sponsors, not just supporters. There’s a difference between people who say “yeah, they’re great” and people who’ll actively argue for your promotion in a room you’re not in. I needed the latter. I identified two senior leaders who’d seen my cross-team work and explicitly asked them to sponsor my case.

​

Operating at Staff Level

Getting the title is the beginning, not the end. Operating at staff level is a fundamentally different job than being a senior engineer who’s really good at coding.

​

Sponsorship Over Mentorship

Mentorship is giving advice. Sponsorship is putting your reputation on the line for someone else. At staff level, your job shifts from being mentored to being a sponsor. What I do: I identify one or two engineers per cycle who are doing invisible but important work, and I make that work visible. I advocate for their projects in leadership meetings. I connect them to opportunities they wouldn’t find on their own. This isn’t selfless — it’s how impact scales beyond what I can personally deliver.

​

Visibility as a Tool

This was the hardest adjustment for me. As a senior engineer, I could let my code speak for itself. At staff level, code is necessary but insufficient. If leadership doesn’t know about your impact, it doesn’t exist in the organizational narrative. What I do:

• I write weekly updates that frame my work in terms of business outcomes, not technical tasks
• I present at engineering all-hands at least once per quarter
• I write RFCs and architecture decision records that become part of the organizational memory
• I share learnings from incidents and projects in a way that’s useful to teams I don’t directly work with

​

Technical Vision

A staff engineer’s most valuable output isn’t code — it’s a compelling technical vision that aligns engineering effort with business goals. What I learned: A good technical vision is not a 50-page document. It’s a clear, concise articulation of where we’re going technically and why. It should be short enough that a new engineer can read it in 20 minutes and understand the engineering organization’s priorities. I write technical visions as living documents with three sections:

1. Where we are (current state, honest assessment of strengths and debts)
2. Where we’re going (target state, 12-18 months out)
3. How we get there (sequenced bets, not a waterfall plan)

​

The Immigrant Dimension

Larson’s book is excellent, but it’s written from a predominantly American perspective. As an Indian immigrant working in Australia, I’ve had to adapt the playbook.

​

Accent and Perception

I won’t pretend this doesn’t matter. In rooms where leadership is evaluating your “executive presence,” accent and communication style are factors — not because anyone is overtly biased, but because System 1 pattern-matching (see Thinking, Fast and Slow) associates certain communication styles with “leadership material.” My approach: I didn’t try to change my accent. I invested in clarity — structured communication, deliberate pacing, and writing as a primary medium. My RFCs, technical visions, and written updates became my strongest tool because writing neutralizes accent bias entirely. When the document is compelling, it doesn’t matter what you sound like reading it aloud.

​

Cultural Navigation

Australian workplace culture values egalitarianism and understatement. The American “selling yourself” approach that many career guides recommend can backfire here. Bragging is socially penalized. Self-promotion needs to be wrapped in team credit and framed as sharing rather than showcasing. My approach: Instead of “I designed this system,” I say “Here’s what we learned building this system.” Instead of “I mentored three people to promotion,” I say “Three engineers on the team grew into senior roles this year — here’s what worked.” The impact is the same. The framing respects the culture.

​

Proving Yourself Differently

As an immigrant, there’s an unspoken feeling that you need to prove yourself harder. That your credentials need more validation. That your accent means you need to be clearer, your documentation more thorough, your delivery more polished. I used to resent this. Now I see it differently — the extra rigor I developed to navigate this dynamic made me a better communicator, a more thorough documenter, and a more persuasive leader. The skills I built to compensate became genuine strengths.

​

Creating Impact Without Authority

Staff engineers have influence without direct authority. You can’t tell people what to do — you have to make them want to do the right thing.

​

The Three Levers

1. Technical credibility. People follow your lead because they trust your judgment. This requires staying technical enough that your opinions carry weight. The moment you stop reviewing code and writing designs, your credibility erodes.
2. Relationship capital. People follow your lead because they trust you as a person. This means being reliable, generous with credit, honest about trade-offs, and willing to be wrong publicly.
3. Narrative control. People follow your lead because you’ve defined the direction in a way that makes sense. This is where technical vision, RFCs, and strategic communication come in.

​

Staying Technical vs Going Broad

The biggest tension at staff level: how much time do you spend coding vs leading? There’s no universal answer, but here’s my ratio: 40% hands-on technical work (code, reviews, design), 30% communication and influence (writing, presenting, 1:1s), 30% strategic work (vision, planning, cross-team coordination). I protect the 40% aggressively. Not because the code I write is more important than anyone else’s, but because my technical judgment atrophies without practice. A staff engineer who hasn’t written production code in 6 months is an architect with stale intuitions.

​

What Changed After Reading This

1. I stopped waiting for the promotion to come to me. I built the case deliberately and presented it clearly.
2. I found my archetype and stopped trying to be everything.
3. I started writing more — RFCs, vision docs, weekly updates. Writing became my primary tool for influence.
4. I reframed the immigrant experience from a limitation to a differentiated advantage.
5. I invested in sponsoring others, which paradoxically accelerated my own growth by expanding my network of impact.

​

Key Quotes I Revisit

• “There is a widespread belief that becoming a Staff engineer is a function of completing difficult, important work. That’s true, but it’s also insufficient.”
• “You can’t lead without trust, and you can’t build trust without being vulnerable.”
• “Staff-plus engineers are the folks who’ve decided to stay on the technical path and have found a way to have broad impact.”

​

Who Should Read This

Any senior engineer wondering what comes next. Any manager wondering whether they should go back to the IC track. Any immigrant engineer who feels like the career advice they’re reading wasn’t written for people like them — because it mostly wasn’t. Read this alongside a mirror. Be honest about where you are, where you want to go, and what you’re willing to invest.