2026-10-03
October 3, 2026 · Issue 113
Will Larson's four archetypes were never a menu to pick from. They were a description of what an organization of a given size needs, and that changes under you.
Most of the arguments about Staff archetypes assume you choose one. You are a Tech Lead, or an Architect, or a Solver, or a Right Hand, and your career strategy is to get good at the label and find a company that pays for it. Read the source again and that is not what Will Larson wrote. In his archetypes guide, Architect and Right Hand roles tend to appear only as organizations reach roughly 100 and 1,000 engineers respectively, Solver roles show up early in companies that prize individual ownership, and over a "thirty or forty-year career" you have time to sample every one. The archetype is a function of the org, not a personality type.
That matters for TPMs more than for anyone, because our role is the one most often defined by the organization's current pain rather than by a ladder. Alex Ewerlöf makes the sharpest critique of the framework in "Staff archetypes can be anti-patterns": when an archetype hardens into an informal title, it narrows scope, and the best Staff-level people are versatile enough to move between modes as the situation demands. You do not have to accept his whole case to take the point. The risk is not that the archetypes are wrong. The risk is treating a season as an identity.
The practical question for your next promotion packet, your next job search, or your next reorg is therefore not "which archetype am I?" It is "which archetype is this organization short of right now, and can I credibly be that?"
Start with Larson's definitions, because the details are what make this useful. The Tech Lead guides approach and execution for one or a few teams and holds the team's context and cross-team relationships; he notes you need roughly one for every eight engineers, which makes it the most common archetype and the most accessible first Staff role. The Architect is responsible for the success of a specific technical domain. The Solver goes deep into knotty problems that leadership has flagged as priorities and, typically, moves on once they are resolved. The Right Hand extends an executive's bandwidth in a large organization, operating, in his phrase, "with the borrowed authority of a senior leader" on problems that are never purely technical and span business, technology, people, culture, and process.
Now map a TPM onto that. The TPM who runs a single launch train for one org is a Tech Lead in everything but name. The TPM who is parachuted into a stalled migration, drives it to done, and is reassigned is a Solver. The TPM who sits next to a VP, owns the operating rhythm, and carries the VP's authority into rooms the VP cannot attend is a Right Hand. Same title, three different jobs, three different promotion cases.
Here is the career insight that follows. Each archetype has a different unit of evidence. A Tech Lead's case is the sustained delivery of a team. A Solver's case is a short list of hard problems, each with a before and after. A Right Hand's case is the leverage on the executive: decisions that closed faster, escalations that never happened, programs that survived a reorg. If you assemble the wrong evidence for the archetype your org is short of, you will be told you lack "scope" or "impact" and never learn why.
The second insight is about timing. Because Architect and Right Hand roles emerge as organizations scale, a TPM joining a 150-person engineering org should not expect a Right Hand seat to exist, and a TPM who has outgrown a Tech Lead seat inside a 2,000-person org may find the Right Hand seat is the only one with headroom. Moving between companies is often a way of changing season without changing yourself.
The third insight is where Ewerlöf's critique earns its keep. If you present yourself as only one archetype, you become easy to slot and easy to replace. The more durable position is to be demonstrably competent in two adjacent modes, say Solver and Right Hand, which is also what the AI-era writing on the role keeps arriving at. Aadil Maan predicts the PM/TPM boundary will blur and that "Jira ticket wrangler" positions will fade; the surviving work is judgment, systems thinking, and measurable results, which is exactly the Solver and Right Hand profile.
So the exercise is diagnostic, not aspirational. Write down the three most expensive unresolved problems in your org. Ask which archetype each one calls for. If the answer is mostly "someone with an executive's authority to resolve a cross-org conflict," the shortage is a Right Hand. If it is "someone to take a knotty migration to done and leave," it is a Solver. Then ask whether anyone is currently filling that seat, formally or not. A shortage with no occupant is the cleanest promotion case you can make, because you are not asking for a bigger title, you are proposing to fill a hole leadership already feels.
One caution. Larson's guide is written about engineers, and the mapping to TPM is mine, not his. Treat it as a lens, not a ladder, and check it against how your own company actually levels the role.
Try this week. List your org's three costliest unresolved cross-team problems, label each with the archetype it needs (Tech Lead, Architect, Solver, Right Hand), and share the list with your manager as a question: "Who owns these, and which of them do you want me to take?"
What it is. A running document of your own accomplishments that you update regularly and use as the raw material for performance reviews, promotion packets, and conversations with your manager. Julia Evans described it in a June 2019 post.
When to use it. Always, but it pays off most before promotion cycles, when you change managers, and when you need peers to write feedback that is specific rather than vague.
How to run it:
When NOT to use it. Do not treat it as a performance-review essay to be polished once a year; its value is that it is captured while the details are fresh.
As Evans puts it: "You don't have to try to make your work sound better than it is. Just make it sound exactly as good as it is!"
Where Is Technical Program Management Heading in 2026? — Aadil Maan (Dec 2025) argues the role is converging with product management and that AI compounds for TPMs who experiment and demand ROI; a useful prompt for what to put in your own career plan.
The AI-Ready Technical Program Manager — Omer Hashmi (March 2026) lists technical fluency, strategic decision-making, communication, ownership, and navigating ambiguity as the core skills; a handy checklist for self-assessment, though thin on evidence.
Staff archetypes can be anti-patterns — Alex Ewerlöf pushes back on archetypes as titles; read it as a counterweight before you let a label define your search.
"AI isn't powerful because it's magical. It's powerful because it compounds."
— Aadil Maan, "Where Is Technical Program Management Heading in 2026?" (December 2025)
Don't miss what's next. Subscribe to Critical Path: