RACE Programming
Audio brief · 2 min
Practice Guide · Staffing

Staffing to client speed

The accordion moves both ways. Staff up when the client accelerates. Staff down when the client slows. Fixed org charts are a Scrum artifact; RACE Programming staffing follows throughput.

Why

Why staffing must follow throughput

In Scrum, teams are staffed at a fixed headcount and sprint capacity is adjusted to fit. In RACE Programming, the delivery unit is the Executable User Story (EUS), and the number of EUS the client can approve per week determines the throughput the engagement actually needs.

Overstaffing at low EUS/week creates idle Pit Crew: engineers waiting for specs that aren't coming. Understaffing at high EUS/week creates bottlenecks: clients approving prototypes faster than Pit Crew can execute. The accordion model matches staffing to the signal that matters: client speed.

The numbers in this guide are reference points, not absolutes. Calibrate the brackets to your team's measured throughput after the first two weeks of execution.

What

Two modes, one accordion

Every engagement runs in one or both modes simultaneously. Discovery mode and Realization mode require different staffing configurations.

Discovery mode

The client is defining requirements and validating prototypes. Pit Crew is not yet executing. Only Pit Wall is active, authoring EUS, building prototypes, interfacing with Team Principal.

EUS / week
Pit Wall staffing
Note
< 3
50% of one person covers all Pit Wall roles
Bus factor risk. Two people at 25–25% each if available.
3–5
100% one person, or 2 × 50% (preferred)
Two-person split reduces bus factor. Use if available.
> 5
100% AI Product + Forward Deployed Engineer for most of their time while the frame forms
Dedicated roles required. Single-person Pit Wall is saturated at this pace.

Transition

Discovery ends when the frame of the solution is set: the business and technical answer to the client's problem, in the prototype the Team Principal accepted, the Executable Product Roadmap and a plan by phases. That is the trigger to build the Pit Crew. The Pit Wall brings it in and onboards it, working from transfer notes kept since day one, then steps back. The shift is gradual, not a handoff in one move: AI Product stays with the engagement, and the Forward Deployed Engineer reduces their time to part-time oversight, mostly on architecture.

Realization mode

The client has approved the Executable Product Roadmap. Pit Crew is executing Executable User Stories. Pit Wall keeps authoring EUS and interfacing with Team Principal alongside Pit Crew execution; the Forward Deployed Engineer is part-time here, mostly on architecture and oversight.

EUS / week
Pit Crew staffing
Note
< 3
50% Pit Crew Quality Engineer + 2 Pit Crew Software Engineers (part-time)
Forming Pit Crew: fractional allocation, full roster.
3–5
50% Pit Crew Quality Engineer + 2 Pit Crew Software Engineers
Standard single Pit Crew configuration.
5–10
100% Pit Crew Quality Engineer + 2 Pit Crew Software Engineers
Full Pit Crew (QE + 2 SWEs). Dedicated Quality Engineer required at this throughput.
> 10
Same full Pit Crew; raise the share of the backlog the machinery clears
No second Pit Crew, no extra people: the Forward Deployed Engineer grows the machinery, with a RACE Engineer part-time and on request.

Never add people inside a Pit Crew, and never add Pit Crews under one Pit Wall. When capacity is insufficient, raise the share of the backlog the machinery clears. See How RACE Scales.

These bands count human headcount only. Every Pit Wall and Pit Crew also works with the Silicon Software Engineer, the AI agent. Not a staffing line; it multiplies what the humans deliver, which is why throughput scales without adding people to a crew.

Who

Role responsibilities at each staffing level

Pit Wall at < 3 EUS/week (50% one person)

  • One person covers Forward Deployed Engineer + AI Product functions.
  • Authors EUS, builds prototypes on synthetic data, interfaces with Team Principal.
  • Maintains context record: domain glossary, decision rationale, architectural constraints.
  • Risk: bus factor is high. If available, split across two people at 25–25% to reduce single-point-of-failure risk.

Pit Wall at > 5 EUS/week (dedicated roles)

  • AI Product: EUS authoring, Gherkin acceptance tests (owned here; the Quality Engineer automates them), EPB management, client comms.
  • Forward Deployed Engineer: architecture decisions (ADR), EARS NFR, prototype build oversight. Most of their time while the frame forms; part-time after the transition.
  • Pit Wall responsibilities at this pace include: presenting 2-3 implementation alternatives per prototype review (never one option), diagnosing and removing Team Principal review friction, and maintaining the running execution record across stories and releases.

Pit Crew Quality Engineer role

  • Validates every Pit Crew engineer output against EUS Gherkin criteria, applying senior Test Lead judgment on AI-generated code.
  • Authors and automates acceptance and functional tests. Exploratory and smoke testing. Test data and environment management.
  • Sets guardrails AI agents cannot modify to make tests pass, the Chinese Wall principle.
  • At < 3 EUS/week (50% allocation), one person covers Pit Crew Quality Engineer + partial execution.
  • At > 5 EUS/week, a dedicated full-time Pit Crew Quality Engineer is required.
How

Reading the signals to move

Signals to scale up

↑
Approved stories miss their Pit Stop. Pit Crew can't execute EUS fast enough: bring it to full allocation, then raise the share of the backlog the machinery clears.
↑
Pit Crew is idle waiting for EUS. Pit Wall is saturated: add Pit Wall capacity or increase Pit Wall allocation.
↑
Team Principal approves > 2 prototypes per week consistently. Client is accelerating: increase EUS authoring and raise the share of the backlog the machinery clears to match.

Signals to scale down

↓
Team Principal approval rate drops below 1 EUS/week for 2+ weeks. Client-side slowdown: reduce Pit Wall allocation. Don't hold excess spec capacity.
↓
Pit Crew completes all EUS before new ones arrive. Execution capacity exceeds Pit Wall output: reduce Pit Crew allocation rather than open a parallel stream on the same backlog.
↓
Client enters a review or budget freeze. Pause Pit Crew execution. Keep Pit Wall at minimum to maintain context continuity for resumption.

Each Pit Wall reads its own signals. A staffing change is a change in team composition, which belongs to leadership and line managers. The TPM carries the signals across teams, keeps the sponsor's expectations in step with the change, and brings the decision to leadership with a date for it. A client budget freeze is the Team Principal's call; the TPM turns it into the new plan for the teams it affects.

The accordion is not just a growth model. Scaling down when the client slows matters as much as scaling up when they accelerate. Holding excess capacity is a cost the engagement cannot absorb.

How to measure

Throughput signals to track

EUS/week approved
Prototypes reviewed and approved by Team Principal per week (two-week rolling average)
Primary accordion input signal
Pit Wall idle time
Hours Pit Wall spends waiting for Team Principal feedback (vs. authoring EUS)
Scale down if > 30% of Pit Wall time is idle
Pit Crew idle time
Hours Pit Crew is unblocked but waiting for new EUS
Scale up Pit Wall if Pit Crew idles > 1 day/week
Pit Stop pass rate
% of Pit Stops shipped with UAT green and no rollback or hotfix
Target: > 70% in the first 3 Pit Stops · > 90% by month 2
Prototype acceptance rate
% of prototypes accepted by Team Principal on first presentation
Target: > 80% first pass by month 2
The principle
Calibrate the EUS/week brackets to your team's actual measured throughput after the first two weeks of execution. The numbers here illustrate the logic, and the logic is what matters: staff to throughput, not to headcount targets.

See the Greenfield guide for the six scaling stages from day one. The Brownfield guide covers the transition path when an existing team is converting. For full role and artifact specifications, see the Framework overview.

FAQ

Frequently asked questions

How should you staff a RACE Programming engagement?
Staff to client speed, not to a fixed org chart. The accordion model maps EUS/week throughput to Pit Wall and Pit Crew allocations in two modes: Discovery (defining requirements) and Realization (executing Executable User Stories). The numbers are reference points; calibrate to your team's measured throughput.
What is Discovery mode vs. Realization mode?
Discovery mode: the client is defining requirements and validating prototypes. No Pit Crew execution yet, only Pit Wall is active. Between them is the transition: once the frame of the solution is set, the Pit Wall brings in and onboards the Pit Crew, and the Forward Deployed Engineer moves to part-time oversight. Realization mode: the client has approved the EPR and Pit Crew is executing Executable User Stories. Both modes can run at once for the same client when it has separate products: those are separate engagements coordinated by the TPM, not streams of one backlog.
When do you scale Pit Crew staffing up?
When EUS/week throughput exceeds the current Pit Crew capacity. Signals: approved stories miss their Pit Stop, Pit Crew is idle waiting for EUS, or Team Principal is approving more prototypes than Pit Crew can execute. Bring the Pit Crew up to full allocation; past that, raise the share of the backlog the machinery clears. Never add people inside a Pit Crew and never add a second Pit Crew under the same Pit Wall.
Can staffing go down as well as up?
Yes. The accordion moves both ways. If a client slows (fewer EUS/week approved), scale staffing down. A client at 2 EUS/week does not need a full-time AI Product; 50% of one person covers Pit Wall at that pace. Holding excess capacity is a cost the engagement cannot absorb.