RACE Programming
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 Stints.

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 + 50% Forward Deployed Engineer
Dedicated roles required. Single-person Pit Wall is saturated at this pace.

Realization mode

The client has approved the Executable Product Roadmap. Pit Crew is executing Stints. Pit Wall keeps authoring EUS and interfacing with Team Principal alongside Pit Crew execution.

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
Add a second Pit Crew (each: QE + 2 Pit Crew Software Engineers)
A Pit Crew never grows past 2 SWEs: add a Pit Crew, don't expand one.

Never add people inside a Pit Crew. When capacity is insufficient, move to the scaled form: one Pit Wall serving 2–5 Pit Crews.

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 scenarios, EPB management, client comms.
  • Forward Deployed Engineer (50%): architecture decisions (ADR), EARS NFR, prototype build oversight.
  • 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 Stints.

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

↑
Pit Stop Demo frequency drops below weekly. Pit Crew can't execute EUS fast enough: add Pit Crew capacity.
↑
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 Pit Crew execution capacity to match.

Signals to scale down

↓
Team Principal approval rate drops below 1 EUS/week for 2+ Stints. 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 or redirect to a parallel stream.
↓
Client enters a review or budget freeze. Pause Pit Crew execution. Keep Pit Wall at minimum to maintain context continuity for resumption.

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 (rolling 2-Stint 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/Stint
Pit Stop pass rate
% where staging UAT passes on demo day
Target: > 70% in first 3 Stints · > 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 Stints. 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 Stints). 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. Realization mode: the client has approved the EPR and Pit Crew is executing Stints. Both modes can run simultaneously on different streams of a large engagement.
When do you scale Pit Crew staffing up?
When EUS/week throughput exceeds the current Pit Crew capacity. Signals: Pit Stop Demo frequency drops below weekly, Pit Crew is idle waiting for EUS, or Team Principal is approving more prototypes than Pit Crew can execute. Scale the Pit Crew; never add people inside an existing Pit Crew.
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.