Designing the Solver Track: A Staff Engineer Operating Model for High-Value, Time-Bounded Work

The informal fast track most engineering organisations end up with

In most engineering organisations past a certain size, a second track quietly forms next to the standard SDLC: work that is too strategic to wait, too uncertain to schedule, too narrow to staff a full team for. The pattern repeats independently of industry — executive sponsorship, one or two senior engineers, a runway measured in months, and a small set of recognisable outcomes. Most of these tracks fail not because of execution but because nobody wrote the operating model before the first project entered the lane.

This pattern has a name in the literature, although most organisations arrive at it before reading the literature. In Will Larson’s StaffEng work, the role at the centre of this lane is called the Solver: a senior engineer who roams between hard problems under executive sponsorship, without a fixed team. The rest of this post treats Larson’s archetype as the starting point and works through the operating model the lane needs to function, together with the conditions under which it should not be built at all. If you are reading this from inside such a lane, or you are being offered a place in one, the rest of this post is written for you.

Larson’s four archetypes and why Solver is the rarest

Larson’s StaffEng taxonomy names four common archetypes of Staff-plus roles: the Tech Lead, the Architect, the Solver, and the Right Hand. Each implies a different operating model, not a different title for the same work. If this is the role you are being offered (exec-sponsored, single project, no fixed team, defined exit), the next sections describe the shape you need to write down before you continue.

The Tech Lead “guides the approach and execution of a particular team,” partnered with one to three managers in a focused area. The Architect “is responsible for the direction, quality, and approach within a critical area,” combining technical constraints, user needs, and organisational leadership. The Solver “digs deep into arbitrarily complex problems and finds an appropriate path forward,” sometimes lingering in an area for years and sometimes bouncing from hotspot to hotspot as leadership directs. The Right Hand “extends an executive’s attention, borrowing their scope and authority to operate particularly complex organizations.”

Larson adds two observations about the Solver that the rest of this post leans on. The role “is most common in companies that think of individuals, rather than teams, as the atomic unit of planning and ownership”; that framing explains why the role emerges in the first place. And Solvers “generally stop working on problems once they’re contained, which can create the feeling of transience and requires a soft touch to avoid infuriating the teams left behind to maintain the ‘solved’ problem.” That sentence is the entire argument for a written handover protocol.

Solver is the least common of the four because it requires sustained executive sponsorship without sustained team membership, and most organisations cannot organisationally hold that shape for long. It is the most misapplied because the failure modes only become visible six months in, by which point the role has already calcified.

There is a hybrid case worth naming. A Solver who stays in payments, or identity, or ML platform for two years is operationally indistinguishable from an Architect except in reporting line. Gergely Orosz at Pragmatic Engineer observes that in practice the same person frequently rotates between these archetypes. The taxonomy treats them as distinct because the operating models genuinely differ; reporting structure and time-boundedness do most of the work in telling them apart.

Three failure modes of unframed fast tracks

The Bimodal Trap. Gartner’s 2014 Bimodal IT framework split delivery into Mode 1 (predictable) and Mode 2 (exploratory); industry post-mortems through 2018 to 2020 documented the predictable failure, and Simon Wardley characterised the framework as guaranteed to get you into a mess. The smaller-scale version is what happens to you: your lane gets seen as the “cool team that ships,” the standard SDLC gets seen as the “team that maintains,” and that perception erodes both you and the rest of engineering. You stop being a peer to the engineers outside the lane; they stop reviewing your work as peers.

The Indispensability Trap. You become the only person who understands three concurrent strategic projects. Removing you from any one of them carries unacceptable risk. Promotion conversations stall, usually phrased as “we need you doing what you’re doing.” Compensation may keep pace; scope and title do not. Twelve to eighteen months is the typical window before the Solver leaves; the strategic work leaves with them. If you are inside this trap and have not already had the title-scope conversation, you are running the clock down on yourself.

The Pet Project Lane. Without written entry criteria, your work shifts with the sponsoring executive’s mood. You move from M&A integration architecture to a CEO pricing experiment to a board-visible AI demo, and none of it graduates to a receiving team. From outside the lane your work looks unaccountable. From inside it looks unbounded. Both perceptions are correct, and both corrode the role.

Each failure mode traces to the same root cause: the organisation invented the lane before it wrote the operating model. Entry criteria, decision authority, review process, knowledge artefacts, and exit conditions were never specified, so the lane defaulted to whatever the sponsoring executive wanted that quarter.

The handbook: an operating model in eight sections

The remedy is unglamorous. The eight sections below are the framework you propose to your sponsor before you agree to continue, or before the next project enters the lane. Each is intentionally about half a page in a finished document. A forty-page handbook will not be read; eight short sections covering the right surface area will. The point of writing this down is not paperwork; the point is that you and your sponsor can disagree about a specific call later without renegotiating the role itself.

4.1 Role definition

Solver is a Staff or Principal individual-contributor role that takes single-project assignments from a defined sponsor (VP Engineering and CTO, or the local equivalent), operates outside team allocation for the duration of the project, and exits to a defined receiving team or to the next assignment. It is not a permanent reporting structure and not a free-floating internal consultancy. Time-bounded and assignment-bounded are the two non-negotiable properties.

4.2 Entry criteria

Three quantitative thresholds the organisation must agree on before any project enters the lane. Reasonable defaults to adapt to local context: business value above a stated bar (for example, more than two million euro of annualised impact, or a strategic-tier dependency in the company’s planning artefacts); bounded duration (six-month target, nine-month hard ceiling); and uncertainty high enough that the standard SDLC’s discovery-to-spec gap would consume more than forty percent of the timeline. Below the value bar, the work goes to the standard track. Above the duration ceiling, the organisation should spin up a team rather than extend a Solver assignment. Low uncertainty also belongs in the standard track. All three conditions must hold for the lane to open.

4.3 Decision authority

Three tiers, written down so the Solver and the sponsor stop renegotiating boundaries every Monday.

The matrix removes the most common Solver friction: ambiguity over what the Solver may decide alone versus what requires escalation. With the lanes named, both sides can disagree about a specific call without disagreeing about the process.

4.4 Quality framework

Every non-reversible decision gets an Architecture Decision Record in Michael Nygard’s format: title, context, decision, status, consequences. One designated reviewer from the receiving team or the platform team signs off on every pull request. The Solver writes; the reviewer approves; the Solver merges. AI-assisted first-pass review is permitted to accelerate the reviewer’s work, not to substitute for the reviewer’s sign-off. In regulated contexts this section gets re-read more than any other; section 5 treats that case directly.

4.5 Knowledge artefacts

Three outputs are mandatory at project exit. First, the ADR set covering every non-reversible decision the Solver made. Second, an operational runbook the receiving team can hold: how to deploy, how to roll back, what to watch in observability, the known failure modes and their first responses. Third, a domain document that explains why the system looks the way it does, surfacing the model the Solver carried in their head while the work was happening. Without all three the project is not done. The artefacts, not the code, are what survive the Solver leaving the project.

4.6 Handover protocol

The receiving team’s representative joins from week one, not at the end. The pattern is an embedded observer: a named engineer with calendar time allocated, attending design discussions, reviewing pull requests, and shadowing operational decisions. A formal handoff event, not a Slack message, transfers ownership; the three artefacts are presented and acknowledged. A calendar-bounded support window follows, typically thirty days, during which the Solver is available at reduced priority for questions. After that window the Solver is fully released.

4.7 Success metrics

Two axes, neither sufficient alone. Delivery: did the project meet its time and value criteria? Influence: did the artefacts and patterns propagate? A Solver who delivers but produces no influence is failing the role. A Solver whose patterns propagate but who never ships is also failing it. The influence axis is measured concretely: ADRs cited by later projects, runbooks adopted unmodified by the receiving team, patterns picked up by other teams. The delivery axis is measured against the entry criteria the project signed up to, not against whatever leadership wishes had been delivered instead.

4.8 Career path

Solver is a station, not a destination. The default rotation is two to four projects across one and a half to three years, then an exit: to Architect for domain depth, to Right Hand for executive scope, or back to a team as Tech Lead. Exit conditions are written before entry. Successor development is a named obligation: during their tenure the Solver mentors at least one engineer toward Staff scope. Without exit conditions the indispensability trap returns by a slightly different route.

Special case: regulated industries

If your sponsor’s enthusiasm for the lane includes “you can move faster because we trust you,” read this section twice. In SOC 2, BaFin, or HIPAA contexts the Solver track does not get trust as a substitute for control. You cannot review-and-merge your own code regardless of seniority, and the asks below belong in the handbook before you accept the role.

SOC 2 CC8.1 (change management) requires authorised changes with documented review and approval; a Solver who reviews their own change is performing self-approval, which auditors flag as a finding. BaFin’s MaRisk AT 7.2 requires segregation of duties (Funktionstrennung) between development and approval for systems supporting regulated business; the BAIT circular extends the same expectation to IT specifically. HIPAA’s §164.308(a)(3) workforce security standard requires policies and procedures ensuring appropriate access, supervision, and authorisation; a lone Solver authorising their own production changes does not satisfy it.

Three patterns are worth bringing as concrete asks. A designated external reviewer, named in the project charter (the receiving team’s tech lead, or a platform or security engineer), signs off on every pull request. Risk-tiered review keeps cost manageable: low-risk changes (config, docs, internal tools) follow the standard one-reviewer flow; high-risk changes (data layer, authentication boundary, money path) require two reviewers, one from outside the project. Post-merge audit covers unavoidable urgency: you merge, the designated reviewer audits within twenty-four hours, and the deviation is logged in the change record. This last pattern needs explicit compliance approval before it is used; it is a deviation from CC8.1, not an exception to it.

When the Solver track is the wrong answer

Before you accept the role, run this disambiguation on the work itself. The practical question is one sentence: is the work going to recur in a different form next year, or is it a singular project with a defined end? Recurrence points to Architect: domain-bound, ongoing ownership, with a roadmap and a team. Singularity points to Solver: project-bound, exits to a receiving team. An Architect role miscast as a Solver assignment becomes the indispensability trap, because the work is in fact recurring; what looked like a project was a domain. If your work is the former, push back and ask for the Architect framing instead.

Three patterns are worth refusing outright. Solver-as-retention: the role is being offered to keep you from leaving, not because the work justifies it; the failure modes accelerate because the work was never the point. Solver-as-scoping-placeholder: leadership cannot decide which team should own a problem, so it sits with you indefinitely. Solver-as-peer-company-mimicry: a similar company has one, and yours is reaching for the same shape without writing the operating model. If any of these is the actual reason for the offer, decline.

The career angle: what this means for Staff aspirants

Writing the handbook is itself Staff or Principal scope work. Codifying an operating model for a previously ad-hoc role is cross-organisational, multi-stakeholder, durable-artefact work, which is the shape of contribution promotion committees recognise at L7, E6, Staff, or equivalent levels. That fact is what makes the handbook a leverage instrument; it is also what makes it risky to publish casually.

The risk is structural: write the handbook, ship it, watch someone else get hired into the role you designed. The mitigation is sequencing. The handbook conversation and the title-scope-compensation conversation must close together. Not the handbook first and the compensation conversation next quarter, not the handbook now and “we’ll get to the rest after we ship this project.” A working sequence looks like this. First, pitch the operating model to the VP of Engineering and the CTO as a problem to solve, not as a job application. Second, secure verbal alignment that the work is real and the role needs a definition. Third, propose to write the handbook and propose your role within it in the same conversation. Fourth, land the handbook draft and the role-and-compensation letter in the same week.

If leadership refuses to sequence the conversations, if the handbook conversation gets “we’ll get to your title and scope after we ship this project,” that refusal is the indispensability trap forming in real time. The right move is to decline to write the handbook until the conversation is sequenced. Drafting the operating model in advance of the title-scope-compensation conversation, on the promise of getting to it later, removes your only piece of leverage. The handbook unwritten is leverage; the handbook published is published.

The compensation conversation has to cover the right surface area too. Scope and title must keep pace with the work, not only base salary. Equity refresh and the rotation timing belong in the same conversation: if the role is two to four projects across one and a half to three years, the refresh grant and the vesting cliff need to land on that arc, not on a generic annual cycle. Exit conditions are a written precondition, not something to negotiate when you want out. The rotation pattern, typically two to four projects then exit to Architect, Right Hand, or Tech Lead, is named in the handbook before you sign, with the trigger conditions for early exit (sponsor change, project kill, indispensability signal) listed explicitly.

Successor development is a near-term obligation, not a far-future bullet. During your tenure you mentor at least one engineer toward Staff scope, by name, with calendar time blocked, not as a slogan in the handbook. This is partly how the lane survives your eventual exit, and partly how you avoid becoming the only person who can hold the shape. A Solver who cannot point to one or two engineers they pulled up during their tenure is, by definition, the indispensable Solver.

The handbook is the leverage, not the proof of work. Once it is published as the organisation’s operating model and other people operate inside it, the original author’s role inside it is decided. Authoring the handbook does not entitle the author to the role. It gives them credible standing to negotiate for it before publication, which is a different and more reliable form of advantage.

From informal fast track to a written operating model

The recommendation is the same one section 4 opens with, now directed at you. Write your operating model before the next project enters the lane, while you still have negotiation leverage. Eight sections, half a page each, co-authored with a VP-level sponsor whose name is on the document, closed in the same week as the title-scope-compensation letter.

What this post does not solve is the upstream question. The handbook does not create executive sponsorship, and it cannot manufacture the strategic-tier work that justifies the role. Without that work, the operating model has nothing to operate on. The handbook is for engineers already standing in a lane the organisation invented for them, watching it degrade because nobody wrote down how it runs.

References

• StaffEng: Staff Archetypes (Will Larson) — Primary source for the four-archetype taxonomy (Tech Lead, Architect, Solver, Right Hand). Verbatim definitions used in this post.
• Lethain.com: Staff Engineer book index (Will Larson) — Larson’s personal site indexing the essays that became the book; complementary to the StaffEng pages.
• StaffEng: Staff Engineer book page (Will Larson) — Book-format treatment of the archetypes plus career-path discussion.
• Pragmatic Engineer: What is a Staff+ Engineer? (Gergely Orosz) — Source for the “Solver and Architect overlap in practice” framing used in section 2.
• Pragmatic Engineer: Software Architect Archetypes (Gergely Orosz) — Parallel treatment of architect-style roles; useful for the Architect and Solver disambiguation in section 6.
• Michael Nygard: Documenting Architecture Decisions (2011) — Origin essay for the ADR format. Sections: Title, Context, Decision, Status, Consequences. Foundational reference for section 4.4.
• Joel Parker Henderson: ADR templates (GitHub) — Canonical templates extending Nygard’s format; a practical reference for the quality-framework section.
• Simon Wardley: Bimodal IT, the new old hotness (Bits or pieces?) — Wardley’s critique of Gartner’s Bimodal IT framework. Cited in section 3 (Bimodal Trap).
• Simon Wardley: Two-speed IT, the more I look the worse it gets — Wardley’s follow-up extending the bimodal critique; supporting reference for the Bimodal Trap argument.
• Gartner glossary: Bimodal — Gartner’s own glossary entry defining Bimodal IT (Mode 1 / Mode 2). Cited for completeness; this post sides with the critics.
• BaFin Circular 06/2024 (BA): MaRisk (German) — Current MaRisk circular; AT 7.2 covers IT in risk management, including segregation of duties between development and approval.
• BaFin Circular 10/2021 (BA): MaRisk (English) — English version of the previous MaRisk edition; AT 7.2 IT segregation clauses cited in section 5. Regulated readers should consult the current German edition for working language.
• BaFin Circular 10/2017 BAIT: Supervisory Requirements for IT in Financial Institutions (English PDF) — BAIT circular extending MaRisk AT 7.2 with IT-specific requirements; the better citation for IT segregation of duties in section 5.
• eCFR: 45 CFR 164.308 Administrative safeguards — Authoritative current text of HIPAA §164.308, including the (a)(3) Workforce Security standard cited in section 5.
• AICPA: Trust Services Criteria for SOC 2 — AICPA SOC 2 TSC landing page; CC8.1 (Change Management) is the clause cited in section 5.