Will Larson’s Staff Engineer book lays out four archetypes for senior technical roles—patterns within the staff track itself:

  • The Tech Lead guides a single team’s approach and execution.
  • The Architect owns technical direction across a broader area.
  • The Solver parachutes into gnarly problems wherever they arise.
  • The Right Hand extends an executive’s reach across complex orgs.

It’s a useful model for thinking about the fork in the road at senior engineer—management track or technical track—and what the technical side actually looks like at scale.

The archetypes assume a stable game. You pick your lane, cultivate the relevant skills, and compound over decades. Mai-Lan Tomsen Bukovec at AWS did exactly this. Twenty years of going deep, still energized by the technical details, coordinating enormous human and technical capital while staying hands-on. The existence of that path is reassuring.

But the game might not be stable anymore.

Escalator

Here’s the comfortable narrative: LLMs let engineers operate at higher abstraction levels. You stop thinking about logger implementation and start thinking about logging architecture across a suite of services. You’re climbing the stack—less interested in the line-by-line, more focused on system-level concerns. This feels like growth.

Here’s the twist: who’s actually doing the climbing?

Maybe engineers aren’t climbing the stack. Maybe they’re being carried up it. And at some point, the thing carrying you doesn’t need you riding along anymore.

Rather than asking “which future is true,” it’s more useful to think in phases. These aren’t alternative worlds—they’re sequential.

Phase 1: Staff engineers supercharged. LLMs handle implementation, humans handle direction. You orchestrate agents, maintain quality, bridge the gap between business intent and technical execution. Deep knowledge plus taste makes you more valuable, not less. This is now through near-term.

Phase 2: The squeeze. AI automates what staff engineers do—iterating on specs, architectural reasoning, system-level thinking. The role gets a temporary boost (like AI-first engineers now), but it’s not durable. Implementation commoditizes, then specification commoditizes. Picking up pennies in front of the steamroller.

Phase 3: Orgs flatten. Models reach a level where all you need is a founder. No managers, no middlemen, no career ladder—at least not for software engineering as a rarefied function. A million startups glistening away.

The question isn’t which phase is “true.” You might live through all three. The question is: how long are you along for the ride?

If you’re optimizing for Phase 1, you double down on technical depth—become the supercharged Staff engineer who can orchestrate agents and maintain taste at scale. This is the obvious play right now.

But Phase 1 is temporary.

If you’re positioning for Phase 2, you start building the skills that survive the squeeze: coordination, politics, accountability, product judgment—the human layer that’s harder to automate. This might mean drifting toward management even if you’d rather stay technical.

If you’re positioning for Phase 3, you need founder disposition: risk tolerance, audience, the ability to operate without organizational scaffolding. That’s a different muscle entirely.

The mistake is treating this as a single bet. The real question is: which transitions can you actually make?

Can you harvest Phase 1 gains while building Phase 2 skills? Can you develop Phase 3 optionality without abandoning your current position?

The Larson archetypes—Tech Lead, Architect, Solver, Right Hand—describe roles in a stable org structure. But org structures aren’t stable. The abstraction stack isn’t stable. The question “should I go Staff or management?” assumes a world where both tracks persist.

The better question: what survives the transitions?

Some candidates:

  • Taste—knowing what’s good, what’s overengineered, what to build
  • Accountability—being the name on the decision when it matters
  • Political skill—building consensus, navigating ambiguity, absorbing org pain
  • Founder disposition—the ability to operate without a ladder

Notice what’s not on the list: “technical problem-solving.” That’s exactly what’s getting automated.

This is regretful. I came into tech because something about the culture felt right in a way I couldn’t explain. Then it turned out that building things and solving problems for real people was genuinely enjoyable—the dopamine of a clean solution, the satisfaction of making something work. If that’s what gets eaten, there’s a real loss, not just a neutral transition.

The uncomfortable answer might be that the durable positions require absorbing social complexity, not technical complexity. The thing that survives is the thing many engineers specifically fled from.

None of this is certain. Expert error bars on AI timelines are wide on the 18-month scale but narrow on the decade scale—most serious observers say 5-15 years, not 50 or 100. You plan your career maybe five years at a time. That puts you inside the transformation window, not before it.

You’re not planning for stability with occasional disruption. You’re planning for the middle of a phase change.

The question isn’t “Staff or management?” The question is: how long are you along for the ride, and what do you do when it ends?