Method
Four steps, in order, and what each one refuses to be.
How I work
- 01
Measure what you have
Cycle time, lead time, release cadence, defect rate, and how long a change waits before a human trusts it. Most organizations cannot answer these on demand, which is the first finding.
- 02
Build one thing that ships
A single gate in the path your teams already use, with agent output held to the same standard as human output. One, not nine — a gate nobody uses is a document.
- 03
Get it adopted
The engineering change is small; the organizational change is not. Teams adopt what they helped design and what does not punish them, so both of those are engineered on purpose.
- 04
Hand it over
Your engineers reproduce the measurement without me and the gate survives a release cycle. If it cannot, it was never yours.
The dip comes first
A new gate slows a team down before it makes them faster. Plan for it, name it in week one, and do not judge the change while you are inside it.
The metric I refuse to optimize
Lines of code accepted per engineer. It rises fastest by making verification weaker, which is the thing I am hired to make stronger.
One thing I got wrong
An early gate counted pull requests merged. Two quarters later we had more changes, each smaller and harder to review. The measurement did exactly what I asked and not what I wanted.