Your time to market is eight weeks. How would you find out where it actually goes?
Show the full answer Hide the answer
What is being tested
Whether you measure rather than assume, and whether you know that the answer is nearly always waiting rather than working.
The method
Trace a small number of real changes end to end, recording a timestamp at every state transition, from the decision to do it to the customer experiencing it. Five to ten changes is enough.
Record both elapsed time and touch time at each stage:
| Stage | Elapsed | Touch |
|---|---|---|
| Idea to prioritised | ||
| Prioritised to specified | ||
| Specified to started | ||
| Started to code complete | ||
| Code complete to reviewed | ||
| Reviewed to merged | ||
| Merged to deployed | ||
| Deployed to released |
The ratio between the two columns is the finding, and it is usually startling — under 10% touch time is typical.
What you will almost certainly find
The waiting is concentrated in one or two places, and it is usually somewhere nobody suspected:
- Prioritisation. Weeks in a backlog before anyone starts. Frequently the largest single block, and not an engineering stage at all.
- Review latency. A day per review round, and several rounds.
- Environment contention — waiting for a test environment or a deployment slot.
- Approval gates — a fortnightly board, a sign-off that takes three days, adding latency and usually no information.
- Batching — the change is ready on day four and ships on day thirty with the release train.
- Cross-team dependencies — waiting for another team's change.
Notice how little of that is writing code, which is where attention usually goes.
What architecture controls
- How many teams must coordinate for one change — the largest term, and a direct consequence of where boundaries were drawn.
- Whether teams can deploy independently.
- Whether changes can be released incrementally, which requires feature flags.
- Pipeline speed and trustworthiness.
What to do with the finding
Attack the largest block first, and re-measure. Optimising anywhere other than the constraint changes nothing — making the build 20% faster when changes wait three days for approval improves the total by nothing measurable.
Then repeat, because relieving a constraint moves it.
What a strong answer adds
That "more people" or "work harder" makes it worse. Adding capacity to a system whose problem is waiting increases work in progress, which increases queueing, which increases elapsed time. This is the same non-linearity that governs system utilisation, and it applies to organisations for the same reason.