Staff archetypes and company stage

Day 19: Staff Archetypes Are a Match to Your Company's Stage, Not a Personality Type

You can do six months of excellent Staff work that your company didn't need. Most seniors aiming for Staff pick an archetype the way they'd pick a job title, by whichever one sounds most senior. That's the wrong filter. Your company's stage decides whether your Staff work lands or stalls, and it counts for a lot more than your personality.

The founder hire

When I was CTO of my own startup, I made what I thought was the best hire of my career. He was a brilliant engineer who had built systems I'd only read about. In his first six months he wrote the best architecture document I have ever seen: a multi-tenant, event-driven platform with clean boundaries, a migration plan and trade-offs that held up. I printed it and kept it on my desk.

In those same six months, the feature our biggest customer had asked for still hadn't shipped. That customer was a renewal we badly needed. Sales asked me for a date every week, and every week my answer got vaguer.

One night I reread the job description I'd written for him. The first line said 'Design our long-term platform architecture.' He had done exactly what I hired him to do. The mistake was mine. I'd hired the archetype that sounded most senior, and the company needed a different one.

The four archetypes in 90 seconds

These four come from Will Larson's book Staff Engineer. If you've read Days 1–18, skim this. If not, here's what each one actually does in a normal week.

• ▹Tech Lead: guides how one team (sometimes two) approaches and executes its work. A Tuesday at PhoenixDX looks like running the design review for a new agent-evaluation feature, splitting it into tickets an agent or a mid-level engineer can finish in a day, and haggling over scope with the PM.
• ▹Architect: owns the direction and quality of a critical technical area across teams. Their Tuesday: review an RFC on how three services share tenant data, then write the decision record so nobody has the same argument again in six months.
• ▹Solver: goes deep on the hardest problem the org has right now, then moves on to the next one. This Tuesday it's a p99 latency spike in the LLM inference path, and it only shows up when two customers run batch jobs at the same time.
• ▹Right Hand: extends an executive's attention and authority across the org. On Tuesday they join a sales call to unblock a deal, cut a launch down to what can really ship by Friday, run the incident retro, then sit on a hiring loop.

What went wrong: I hired an Architect when I needed a Right Hand

We had one big customer, a product that changed every month and about six engineers. Nothing in the system was stable enough to be worth architecting. Our real problem was getting one feature into one customer's hands before the renewal. That's glue work, and glue work belongs to the Right Hand.

Put a Right Hand in the same seat for those six months and the work would have looked unglamorous, something like this:

• ▹Unblock sales. Sit in on the customer calls, turn 'we need reporting' into a concrete list of three exports, and tell sales honestly what ships and when.
• ▹Cut scope. Ship a thin slice in three weeks: single-tenant, a bit ugly, working.
• ▹Say no on the founder's behalf, in writing. A one-page 'What we are not building yet' doc, with the multi-tenant platform on it, to revisit once a second customer needs it.
• ▹Own the launch: checklist, rollout, customer-side training, and the first two weeks of support for that account.
• ▹Protect the team by absorbing the context-switching, so the other five engineers keep shipping.

You wouldn't get a conference talk out of any of that. You would have kept the renewal. The architecture doc was right, just for a company we hadn't become yet.

The stage-to-archetype map

This map is the core of today's lesson. The headcounts are rough heuristics from my own experience, not hard lines. Judge your stage by the shape of your problems, not by how many people you employ.

STAGE              | MOST USEFUL              | GETS FRUSTRATED                | MISMATCH WARNING SIGN
-------------------+--------------------------+--------------------------------+------------------------------------------------
0 -> 1             | Right Hand, Solver       | Architect (nothing is stable   | Design docs outnumber shipped customer features.
(pre-PMF, 1 team)  |                          | enough to design for)          | Roadmap items are systems no customer uses yet.
-------------------+--------------------------+--------------------------------+------------------------------------------------
Early traction     | Solver, Tech Lead        | Architect (still too early);   | The same production fire keeps coming back.
(repeatable sales, |                          | Right Hand if founders won't   | Staff person works on 'platform' while sales
 1-3 teams)        |                          | delegate                       | escalations pile up.
-------------------+--------------------------+--------------------------------+------------------------------------------------
Scale-up           | Tech Lead, Architect     | Solver (fires turn into        | Teams rebuild the same thing three ways.
(several teams,    |                          | process); Right Hand with no   | Every cross-team decision goes to the CTO.
 hiring fast)      |                          | clear exec to extend           |
-------------------+--------------------------+--------------------------------+------------------------------------------------
Multi-team org     | Architect, Right Hand    | Solo-hero Solver who wants     | Simple decisions take a quarter.
(groups, platform  | (to a VP or CTO)         | to fix everything personally   | Nobody can explain why the system looks the
 teams, directors) |                          |                                | way it does.

Read the 'gets frustrated' column as closely as 'most useful'. A frustrated Staff engineer isn't a bad engineer. Their strengths just have nowhere to go at this stage, so they do one of two things: leave, or invent work that suits them. My Architect was doing the second.

The agent twist: coding agents redraw the map

Tools like Claude Code, Cursor and Codex now write a big share of the implementation. That changes two things.

First, the Solver's edge has moved. A Solver used to be valuable because they knew the answer. They'd seen this deadlock before and knew where the memory leak lived. Agents now produce plausible answers in seconds, so what's scarce is spotting the plausible answer that's subtly wrong. Say an agent fixes a flaky test by widening a timeout, and the race condition underneath stays hidden. Or a migration runs cleanly on the staging dataset and then silently truncates a column in production. Your value as a Solver now comes from knowing the system well enough to distrust confident output.

Second, a fifth kind of work now shows up at every stage: designing the harness the agents work in. It isn't a new archetype yet. It's work that falls to whichever of the four is closest to it. It has four parts:

• ▹Context: what the agent sees. Repo conventions, CLAUDE.md or AGENTS.md files, architecture notes written for a reader with no memory of last week, and which docs are in scope.
• ▹Evals: how you know the output is good. That means tests that check behaviour, not just coverage, plus golden datasets for LLM features and review rubrics.
• ▹Guardrails, meaning what the agent is allowed to do: permissions, CI gates, protected paths, and the changes that always need a human sign-off.
• ▹Task breakdown: cutting work into pieces an agent can complete and a human can verify. It's the old Tech Lead skill of slicing tickets, and it now matters twice as much.

At 0→1 the harness might be one context file and a test command the agent has to pass. At a scale-up it turns into shared conventions, eval suites and guardrails across teams, which is Architect territory. Later days in this series go deeper on agentic software engineering. For today, take this away: whatever archetype you pick, the harness work sits unclaimed at most companies right now, and owning it is one of the fastest ways to build your Staff case.

Self-check: turn the map on yourself

Write these three answers down. Don't just think them. Your gut answer usually describes the company you wish you worked at.

• ▹What stage is your company really in? Ignore the funding round and the pitch deck and look at last month's problems. Were they 'will anyone buy this', 'can we keep it running', 'can teams work without colliding' or 'why does every decision take forever'? Each one points at a different row of the map.
• ▹Which archetype's work already lands on your desk without anyone asking? Sales DMs you about deals. You get paged for the weird bugs. Two teams ask you to settle their API dispute. Work that finds you on its own is evidence of fit, and your manager has probably noticed it already.
• ▹Which archetype does your manager quietly wish they had? Listen to what they complain about in 1:1s. 'I'm in every customer escalation' means Right Hand. 'Teams keep rebuilding the same thing' means Architect. 'Nobody trusts what the agents ship' means harness work.

Your archetype sits where all three answers overlap. If the one you'd prefer isn't in that overlap, you have two honest options: build the archetype the company needs, or move to a company at the stage where your preferred one fits. Both are fine. Spending two years chasing a mismatch is not.

Using this in your next promo conversation

At startups and scale-ups the Staff rubric is usually vague, copied from a bigger company, or doesn't exist. So don't argue with a rubric. Name your archetype, tie it to something the company needs, and agree up front on what evidence will count.

"I've been thinking about what Staff should mean for me here, specifically.

Where I think we are: [stage], and the problem that keeps hurting us is
[concrete pain, e.g. 'every enterprise deal stalls on a custom integration'].

The work already landing on me looks like [archetype] work:
[2-3 real examples from the last quarter].

I'd like to lean into that deliberately. Over the next two quarters I'd
own [specific outcome, e.g. 'integration launches end to end, plus the
agent harness so the team can ship them without me'].

If I do that well, would you see it as Staff-level impact?
If not, what would be missing?"

The last question matters most. It turns a vague promotion into an explicit agreement, and if you and your manager see the company's stage differently, you find out while there's still time to adjust. EMs and founders hiring their first Staff engineer can run the same script backwards: write down the stage and the pain first, then the archetype, and only then the job description. I wish I had.

What happened to the Architect

He left about a year later, on good terms, for a scale-up whose product teams kept rebuilding the same plumbing. They needed exactly the document he'd written for us, and he did very well there. Same person, same strengths. The company's stage finally matched them.

Picking your archetype is half the job. The other half is explaining it so that people who don't watch you work every day can see why it's Staff-level. Day 20 covers that: writing the Staff-level narrative behind your archetype.

Extend your knowledge

• ▹Will Larson's 'Staff Engineer: Leadership Beyond the Management Track' and the archetype essays on staffeng.com. That's where the four archetypes come from, along with interviews with real Staff engineers in each role.
• ▹Tanya Reilly's 'The Staff Engineer's Path' (O'Reilly). Read the 'Three Maps' chapter on understanding your organisation and the 'Finite Time' chapter on choosing your work next to today's stage map.
• ▹For the harness work, start with Anthropic's engineering post 'Building effective agents' and the Claude Code best-practices docs. They cover context files, task decomposition and verification loops.
• ▹Exercise: write your three self-check answers. Then ask your manager the third question directly ('If you could clone one kind of senior person, what would they do all week?') and compare their answer with yours.