RACE Programming
Audio brief · 2 min
Practice Guide · Measuring a RACE rollout

If your team measures with DevEx

A measurement playbook. For each of the three DevEx dimensions: what to measure under RACE Programming, where to pull it from, what to target, and what to watch. DevEx is the most diagnostic lens on a rollout, because it moves before your delivery numbers do.

During a rollout, the TPM, who organizes the transition, brings these readings into the cross-team status rhythm and the risk register. The numbers stay with the teams that produce them.

The three dimensions, instrumented

Feedback Loops

  • Measure: median time from spec to a passing Definition-of-Done gate, and Inner Cycle frequency.
  • Source: CI logs for gate results, Inner Cycle logs for cadence.
  • Target: gate feedback in minutes; the Inner Cycle running Spec, Build, Align twice per day.
  • Watch: if gate feedback takes hours, the Definition of Done is not automated enough. That is what slows the agent's self-correction.

Cognitive Load

  • Measure: the context a person must hold to move an Executable User Story. Proxies: the return-for-clarification rate on an EUS, and the number of systems touched to complete it.
  • Source: board transitions plus the EUS structure itself.
  • Target: an EUS is self-contained; a Pit Crew engineer can execute it without hunting for context. Everything as Code keeps that context machine-readable.
  • Watch: a rising clarification rate means load is leaking upstream, and the spec is not yet minimum-sufficient.

Flow State

  • Measure: uninterrupted focus blocks per Pit Crew engineer, and stories re-scoped after the Pit Crew pulled them.
  • Source: focus or calendar tooling, plus board changes to stories already in progress.
  • Target: long focus blocks and zero re-scopes of stories in progress.
  • Watch: re-scoping a story after the Pit Crew pulled it means the Pit Wall is not buffering the client's changes. Fix the boundary, not the schedule.
The tell

DevEx moves before throughput

Delivery metrics move slowly and are easy to game; developer experience moves first and honestly. If a RACE Programming rollout is real, you will see it in DevEx before the delivery dashboard: feedback loops tighten, the context load per story drops, and flow stops being interrupted. If DevEx does not move, the framework is not installed yet, whatever the dashboard says.

DevEx measures the experience. RACE Programming is built to improve all three dimensions on purpose.

Read the framework → · All practice guides →

FAQ

Frequently asked questions

How does the DevEx framework apply to RACE Programming?
DevEx defines three dimensions: feedback loops, cognitive load, and flow state. RACE Programming has a design decision behind each. Feedback loops are the median time from spec to a passing Definition-of-Done gate, tightened by the twice-daily Inner Cycle. Cognitive load is the context a person must hold to move an Executable User Story, lowered by minimum-sufficient specs and Everything as Code. Flow state is uninterrupted focus, protected by role boundaries and a settled spec for every story the Pit Crew pulls.
How do you measure cognitive load in RACE Programming?
Use the rate at which an Executable User Story is returned for clarification and the number of systems a person must touch to move it, as proxies for the context they must hold. The Executable User Story is designed to be minimum-sufficient so the agent builds without re-interpreting context, and Everything as Code keeps state machine-readable, so a rising clarification rate is your signal that load is leaking upstream.
How does RACE Programming tighten feedback loops?
The Inner Cycle runs Spec, Build, Align twice per day, and the four-gate Definition of Done gives a deterministic pass or fail in minutes, so the Silicon Software Engineer self-corrects against the gates rather than waiting for end-of-sprint review. Measure the median time from spec to a passing gate; the target is minutes, not hours.
How does RACE Programming protect flow state?
Measure uninterrupted focus blocks per Pit Crew engineer and count events where a story is re-scoped after the Pit Crew pulled it. The Pit Wall buffers the Team Principal changes so the Pit Crew executes against a settled spec, so re-scoping a story in progress is a boundary breach and the thing to correct.