The method

The assessment runs in seven steps and then repeats. The first is the one most often skipped.

1. Declare intent. Is the goal more output, lower cost, lower risk, or a mix? Agree the target and the time horizon with whoever sponsors the work.
2. Map the value stream. Trace a typical change from request to customer use. Record the elapsed time and the hands-on time for every stage, including stages outside engineering such as approvals, release windows and training.
3. Assess the eight dimensions. Gather evidence from repository and CI data, incident history, policy documents and interviews. See the dimensions.
4. Score and name the constraint. Score each dimension from 0 to 4, then state the single stage that currently caps end-to-end speed.
5. Design autonomy tiers. Decide which change types merge with no human, one human, or a review board, and what evidence each needs. See levels and tiers.
6. Sequence the interventions. Fix the binding constraint first. Plan in 30, 60 and 90 day steps, and expect the constraint to move.
7. Re-measure. Repeat quarterly and after any major model or tooling change. Check the predictions in your decision record.

Speed up the work, not the wait

A stage's elapsed time is hands-on time plus waiting time. AI shortens only the hands-on part. A change that sits two days in a review queue still waits two days when the review itself takes minutes.

So the whole-path check applies a speedup only to hands-on time. If the path takes E days, stage k has t hands-on days and w waiting days, the work gets s times faster and a process change cuts a fraction r of the waiting:

speedup = E / (E − t + t/s − r·w)

With r = 0 this is Amdahl's law. Example: coding is 30% of the path and becomes 3 times faster, nothing else changes: 1 / (0.3/3 + 0.7) = 1.25, not 3.

Today

After

CodingOther hands-on workWaiting

1.25×faster end to end

With coding 3× faster, a change that took 100 days takes 80.

Coding is

30% of the path

Waiting is

45% of the path

AI makes coding

3× faster

Process cuts waiting

not at all

Amdahl's law: only the part that gets faster gets faster. The assessment does the same calculation from your own stage timings.

If hands-on time is not known, treating the whole stage as work gives an upper bound, and the assessment labels it "at most". Waiting is usually the larger share, which is why the constraint is found from where work waits, not from where it is done.

What an engagement produces

1. A value stream map with waiting time per stage.
2. A scorecard for D1 to D8 with the evidence behind each score.
3. A one-paragraph statement of the binding constraint.
4. A draft autonomy tier policy.
5. A 30, 60 and 90 day sequence of interventions.
6. A baseline metric set with targets. See metrics.
7. An executive readout that frames the output-versus-cost choice.

Who it is for

Who	Question it answers
CTO or engineering leader	Where does speed stall between a finished change and a customer using it?
Delivery or platform lead	Is the platform ready for agent-scale volume, or is it already the constraint?
Risk, security, compliance	Which changes can run with less human review, and what evidence makes that safe?
Finance or business sponsor	Take the gain as more output or lower cost, and is the system ready for either?
Team lead	What should my people spend their time on now that code is cheaper?

Next: using the assessment.