Early in my career I thought “staff engineer” just meant “a senior engineer who’s really, really good at coding.” So I doubled down on getting faster and deeper at writing software. I got better at it, and I did not get closer to staff. The work that actually moved me there was almost none of it typing: a document that stopped three teams from building incompatible systems, a quarter spent getting two orgs to agree on one approach, mentoring two engineers who then carried a project I couldn’t have done alone.
That was the lesson, and it’s where this course starts: staff is not “senior plus one” on the same axis. It’s a different axis. This lesson is about understanding that shift, because if you aim at “senior but faster”, you’ll work very hard in the wrong direction.
What Actually Changes
Here’s the honest comparison between the two levels:
Read down that table and notice the pattern. At every row, the staff version is bigger in scope and more indirect in how impact happens.
- Scope goes from your team’s projects to problems that span teams, orgs and quarters.
- How you’re measured goes from what you build to what you make possible for others to build. This is the big one, and it’s uncomfortable, because the thing that got you here (shipping great code yourself) is no longer the thing.
- The hardest part goes from technical execution to judgment: choosing what matters, influencing people you don’t manage, deciding well under uncertainty.
- Code becomes a tool of influence, a prototype to prove a point, a reference implementation, a tricky bug fixed to unblock a team, not your main output.
- Authority is mostly gone. A staff engineer usually can’t tell anyone to do anything. You lead by trust and clarity (Lesson 7).
- The failure mode shifts in a way that catches people off guard. As a senior, you fail by missing a deadline, a visible, obvious failure. As a staff engineer, you fail by being busy and productive on work that didn’t matter. You can have a great quarter by every local measure and have moved nothing that counts. Avoiding that is most of the job.
If you take one thing from this lesson: stop trying to be a faster senior engineer. Start asking “what’s the most important thing I could change for many people, and how do I make that happen without doing it all myself?”
The Four Archetypes
Staff engineers don’t all do the same job. Will Larson, in Staff Engineer, identified four common shapes the role takes. Knowing which one you are (or want to be) clarifies what “good” looks like for you, because the archetypes have genuinely different days.
- Tech Lead leads the technical direction of one team, usually paired with an engineering manager (the EM owns the people, the Tech Lead owns the “how”). This is the most common archetype and the closest to the senior role, so it’s where most people start. The risk is staying too in-the-weeds on your one team and never broadening.
- Architect owns a domain across several teams, data infrastructure, payments, search, identity. You hold deep context in that area and set the patterns others build on. The danger is becoming an “ivory tower” architect who’s lost touch; good architects stay hands-on enough to keep their designs real (Lesson 12).
- Solver gets pointed at the hardest current problem and goes deep on it. The org sends you where the fire is. Great for companies with lots of gnarly one-off problems, but the risk is you firefight forever and never build lasting systems that prevent the fires.
- Right Hand extends a senior leader’s reach, working org-level problems with borrowed authority. It’s the most “leadership-shaped” archetype and the rarest, usually only at larger scale.
None is more “real staff” than another, and you can move between them over a career. But they shape your days, your peer group, and what success means, so it helps to know which one you’re in and which one fits you.
The Fork: Staff IC or Manager?
At the senior level, the career ladder splits. You can continue as a staff+ individual contributor (the subject of this course) or move into engineering management. A few things people get wrong about this fork:
- Neither is a promotion over the other. A staff IC and an EM at the same level are peers. In healthy companies the ladders are parallel, with the same levels, pay bands and influence.
- Both are leadership. The staff IC leads through technical judgment, design, strategy and influence; the manager leads through people, hiring, growth, team health. Different tools, same goal: making a team more than the sum of its parts.
- Pick based on what energises you, not status. The real question is: on a good day, would you rather spend your time on a thorny design problem, or helping a struggling teammate grow? There’s no right answer, only the right answer for you.
- You can switch later. Many strong leaders do a few years of each (the “pendulum”). Managing for a while makes you a better staff engineer, and vice versa.
- Staff IC is NOT “the path for people who can’t manage.” It’s a demanding leadership track in its own right. If anything, staying technically deep and developing the influence skills is harder than picking one.
This course assumes you’re interested in the staff IC path (or in understanding it). But much of it, writing, decisions, influence, strategy, applies to managers too.
So What Do You Actually Do All Day?
If code isn’t the main output, what fills the week? Roughly:
- Thinking and deciding: which problems matter, which approach, which trade-off. The highest-value and least visible part.
- Writing: design docs, strategy, decision records, proposals (Lessons 3, 4, 5). Writing is how a staff engineer’s thinking scales beyond the room.
- Talking to people: understanding what teams need, aligning them, unblocking, building trust (Lessons 6, 7). A lot of a staff engineer’s week is conversations.
- Some hands-on work: a prototype, a hard bug, a reference implementation, a tricky review. Enough to stay credible and grounded (Lesson 12), not enough to be the bottleneck.
- Growing others: mentoring and sponsoring (Lesson 9), so the team’s ceiling rises.
- Firefighting and judgment calls: being the calm in an incident, making the risky call when it’s genuinely ambiguous (Lesson 11).
If that list feels less concrete than “ship feature X”, that’s the point, and the discomfort. The rest of this course makes each of these concrete and teachable.
Pitfalls to Avoid
- Aiming for “senior but faster.” Staff is a different axis (scope, influence, judgment), not more of the same.
- Clinging to code as your main output. Your impact is now what you enable others to do.
- Not knowing your archetype. Tech Lead, Architect, Solver and Right Hand have different days and different “good”.
- Treating the manager path as higher status. They’re parallel; choose by what energises you.
- Thinking staff IC is for people who “can’t manage.” It’s a demanding leadership track of its own.
- Measuring yourself by activity. The new failure mode is being busy on work that didn’t matter.
Quick Recap
- Staff is a change in kind, not degree: changing what the work is for many people, not doing your own work faster.
- Impact is measured by what you enable; code becomes a tool of influence; you usually have no authority and lead by trust.
- Four archetypes: Tech Lead (one team), Architect (a domain), Solver (the hard problem), Right Hand (a leader’s reach).
- The ladder forks into staff IC and management, parallel, both leadership; pick by what energises you.
- The new failure mode is being busy and productive on work that didn’t matter.
Next lesson: the skill that prevents that failure mode, operating at the right altitude, and choosing work by its importance, reach and durability.