The Four Staff Archetypes

"This taxonomy is more focused on being useful than complete."

Will Larson wrote that sentence about his own list of Staff roles. Larson is an engineering executive who interviewed many Staff and Principal engineers for his book Staff Engineer: Leadership Beyond the Management Track, and he found that their work fell into four recurring patterns. He named them the Tech Lead, the Architect, the Solver, and the Right Hand.

The list is useful because the same title covers very different jobs. Four Staff engineers at the marketplace from the previous lesson hold the same level, and their weeks look almost nothing alike. This lesson describes each archetype through one of them: what the engineer owns, how the work is measured, and what usually goes wrong.

What an Archetype Is

A Staff archetype is a recurring pattern of Staff work, defined by what the engineer owns and where the engineer spends time. It is not a title. A job posting says "Staff Software Engineer" for all four, and few companies name the archetypes at all. Most Staff roles still lean clearly toward one of them, and a role that mixes two usually has one that dominates.

Notice that the four differ mainly in what they own: a team, an area, a problem, or an executive's priorities. Each kind of ownership leads to a different scope, a different way of measuring results, and a different typical failure.

The Tech Lead

A Tech Lead guides the technical approach and execution of one team, or of a small group of closely related teams. In Larson's words, the role "guides the approach and execution of a particular team," and "Tech Leads are the most common Staff archetype."

At the marketplace, the Staff engineer in checkout leads three teams with 22 engineers between them. The engineer sets the technical direction for checkout, breaks each large project into pieces the teams can deliver, and reviews the riskiest designs. The engineer also works with the engineering managers and the product manager on what the teams build next. A Senior engineer can lead one team's project. The Staff Tech Lead is responsible for how three teams build, over several quarters.

The work is measured by the results of those teams: whether checkout delivers its plan, how often it causes incidents, and how quickly its engineers can change it. Larson notes that Tech Leads "default to delegating" projects across the team while remaining "the person defining their team's technical vision." The common failure is the opposite habit, in which the Tech Lead keeps the most interesting work and the team waits for one person.

The Architect

An Architect is responsible for the direction, quality, and approach within one critical technical area, across every team that works in it. Larson describes the role as "responsible for the direction, quality, and approach within a critical area," and notes that it "tends to evolve in relatively large companies."

The marketplace's Architect owns API design. The company runs about 180 services, and any of them may expose an API to partners or to other teams. The Architect writes the API guidelines, reviews each new public API (about 12 a quarter), and owns the policy for retiring old versions. The Architect does not own any of the services; the teams do. The Architect owns the rules that keep them consistent.

This work is measured over years, by the health of the area. The measures include how long a partner integration takes, how many breaking changes reach partners, and how often teams must rebuild a poorly designed API. Larson writes that Architects "dedicate their energy to maintaining an intimate understanding of the business' needs," because an area's direction is only correct if it serves what the business will need. The common failure is an Architect who writes rules without the teams that must follow them, so the rules are ignored.

The Solver

A Solver works on one difficult, high-priority problem at a time, stays with it until it is resolved, and then moves to the next. Larson's description is an engineer who "digs deep into arbitrarily complex problems and finds an appropriate path forward."

The Staff engineer from the previous lesson worked as a Solver on the scheduler project. Before that project, the same engineer spent two quarters on a database that was close to its storage limit. After the scheduler project, leadership asked the engineer to take on a search system whose cloud costs had doubled in a year. The problems are unrelated, and each one is usually chosen by leadership because it is urgent and nobody else can resolve it.

A Solver is measured by problems resolved, and Larson's phrase for the role is one that "goes deep into knotty problems, continuing to work on them until they're resolved." The common failure comes at the end. A Solver who leaves a problem before a team owns the result leaves behind a system that nobody understands, and the problem returns within a year.

The Right Hand

A Right Hand extends a senior executive's attention, using the executive's scope and authority to work on the organization's most complicated problems. Larson calls it "the least common of the archetypes," and describes it as one that "extends an executive's attention, borrowing their scope and authority."

The marketplace's Right Hand works with the VP of Engineering, who is responsible for all 400 engineers. The Right Hand attends the VP's staff meetings and runs the yearly review of each group's technical plans. When a problem crosses several groups, such as a reliability problem that involves payments, search, and the platform group at once, the Right Hand leads the response. Few of these problems are purely technical; most combine technology, organization, and timing.

The work is measured by whether the executive's priorities advance. The common failure is structural rather than personal: the authority is borrowed, so it ends when the executive leaves or the executive's priorities change.

Comparing the Four Archetypes