Staff+ Archetypes

"Staff+" is shorthand for the senior individual-contributor track that begins where Senior ends: Staff, then Principal, then Distinguished or Fellow. It is a leadership track. The lever is technical judgment applied at a scope wider than a single team, exercised without a reporting line under you.

The defining property is not seniority of title. It is that the org changes its behavior because of your technical work, and it does so without you being anyone's manager. You lead by being right often enough, visibly enough, that people route decisions through you.

The IC Track vs the Management Track

The two senior tracks diverge less than people think. What is the same:

• Leadership. Both set direction, build alignment, and own outcomes larger than themselves.
• Communication. Both spend most of their day in writing and conversation, not in the thing they're nominally expert at.
• Dealing with ambiguity. Both are handed problems with no defined edges and expected to return them with edges.

What differs:

• No direct reports. You have no headcount, no performance reviews to write, no hiring-and-firing authority.
• Influence, not authority. A manager can assign work. You can only convince. See influence without authority.
• Technical judgment is the product. A manager's output is the team's output. A Staff+ engineer's output is the quality of the technical decisions the org makes — including ones they never touched directly.

Two misreadings to kill early:

• It is not "a manager who failed at people." The skills overlap heavily; the IC track is not a consolation prize.
• It is not "a senior engineer who codes more." If anything you code less. The promotion is into a different job, not a turbocharged version of the old one.

The Four Archetypes

Will Larson's Staff Engineer framing names four shapes the role takes. They are not job titles — they describe where your impact comes from. Most real roles are a blend, but it helps to name the pure forms.

Tech Lead

What they do. Guide the approach and execution of a single team, usually the largest or most critical one. They own the technical direction of that team's work, pair with the manager on planning, and unblock people. The most common Staff archetype.

When an org needs it. A team big enough or load-bearing enough that someone must own its technical coherence full-time, but where the problems are scoped to that team.

A day in the life. Reviewing a design doc, sitting in sprint planning to flag a hidden dependency, pairing for an hour on a gnarly bug, writing the technical section of a quarterly plan, declining three meetings.

Failure mode. Becoming a second manager — drifting into people and process and leaving the technical seat empty. Or never leaving the keyboard, owning so much implementation that the team can't function without you.

Architect

What they do. Own the technical direction of a critical area that spans multiple teams — an API surface, a data platform, an auth system. They hold the long-horizon view and the constraints that keep independent teams from diverging. See technical strategy.

When an org needs it. A domain too important and too cross-cutting to leave to whichever team touches it this quarter. Usually appears when team count and system complexity have outgrown ad-hoc coordination.

A day in the life. Writing an RFC, walking three teams through a migration path, saying no to a shortcut that would calcify into tech debt, reconciling two teams' conflicting assumptions about the same interface.

Failure mode. The architecture astronaut — designing for problems the org doesn't have, in diagrams nobody implements, disconnected from the code that has to honor them.

Solver

What they do. Drop into the hardest active problem and fix it. The performance regression nobody can find, the migration that's stuck, the incident that keeps recurring. Deep, often roaming, rarely tied to one team.

When an org needs it. When the highest-value work is a small number of genuinely hard problems rather than steady ownership — common in fast-moving or fire-prone orgs.

A day in the life. Two weeks heads-down on a thing, then gone. Bisecting a regression across six months of commits, reverse-engineering an undocumented system, shipping the fix, writing it up, moving on.

Failure mode. The hero who creates dependency. If the org only knows how to solve hard problems by summoning you, the Solver has made themselves a permanent bottleneck instead of a temporary one. See scaling yourself.

Right Hand

What they do. Operate as a senior leader's technical extension — usually a director's or VP's. They borrow that leader's scope and context, take on the most ambiguous org-level problems, and translate between executive intent and engineering reality. The rarest and most senior-leaning archetype.

When an org needs it. A large org where a single leader's span is too wide to cover technically, and where decisions need someone with both the leader's context and deep technical credibility.

A day in the life. Sitting in the leadership staff meeting, then spending the afternoon untangling why a reorg's technical assumptions don't hold, then drafting the memo that realigns three orgs.

Failure mode. Becoming a proxy with no independent judgment — a messenger who launders the leader's opinions as technical findings — or being so fused to one leader that the role evaporates when that leader leaves.

Scope and Altitude

The thing that actually levels up across Staff → Principal → Distinguished is not difficulty. It is scope — the blast radius of your decisions.

The same problem looks different at each altitude. "Our API is slow" is a profiling task to a Tech Lead, an interface-design problem to an Architect, a capacity-and-prioritization question to a Right Hand, and a build-vs-buy bet at the company level. Climbing the track is largely learning to recognize which altitude a problem actually lives at — and resisting the urge to solve it at the altitude you're most comfortable with.

Choosing and Shifting Archetypes

Nobody is one archetype for a career. They shift with the org's needs and your own pull.

• Most people blend two. A Tech Lead who also solves the hard problems on their team. An Architect who acts as a director's Right Hand for one domain.
• The org's need dominates. A startup rarely needs an Architect; it needs Solvers and Tech Leads. A 2,000-engineer company has roles a 50-person one can't.
• Your archetype can change without a promotion. Moving from Tech Lead to Solver is a sideways shape change, not a level change.
• Pick by leverage, not comfort. The right archetype is the one that addresses the org's biggest unmet technical need that you're credible to fill — not the one that feels most like the work you already enjoy.

Be explicit about which shape you're playing, and renegotiate it when it stops fitting. An unstated archetype is how a Solver ends up resented for not owning anything and a Tech Lead ends up resented for owning too much.

Anti-Patterns

• The architecture astronaut. Designs for elegance and imagined future scale, decoupled from the code anyone ships. Diagrams accumulate; nothing changes. Tell: their artifacts have no implementation owners.
• The hero / solver who creates dependency. Fixes everything personally and leaves no transferable capability behind. The org's resilience goes down over time because hard problems route to one person. Heroics are a failure of the system, even when they save the quarter.
• The title-chaser. Optimizes for the promotion, not the impact — picks visible work over valuable work, frames others' wins as their own, treats "Staff" as a trophy rather than a job description. Orgs that promote on visibility breed this.
• The engineer who took the promotion but kept the senior job. Got the title and the scope, but still spends every day doing exactly what they did as a Senior — closing tickets, owning one service well. Comfortable, and a waste of the level. The promotion was into a wider scope they declined to occupy.

A useful counter to all four: tie the work to the org's actual problems, leave capability behind you not just fixes, and measure yourself by what the org can now do without you — see mentoring and scaling yourself.

The Self-Check

The track is leadership without authority, and the trap at every level is doing the job below you because it's where you're comfortable.

If you vanished for a month, would the org's technical decisions get measurably worse — or just its ticket throughput?

If only throughput suffers, you took the title but kept the old job. The Staff+ work is the part that would be missing.