DEV Community

Mikhail Savchenko
Mikhail Savchenko

Posted on Originally published at inite.ai

Hold: Why the Process Gets Frozen Before It Gets Measured

The stage nobody wants to pay for

Hold sits between the diagnosis and the measurement. It ships nothing. It produces no diagram anyone will put in a deck. It is, reliably, the first stage a client asks to skip, and the request is reasonable on its face: the problem is understood, the candidates are chosen, why are we not building.

Because the number that justifies the build has not been taken yet, and it cannot be taken against a moving target.

Processes move while you watch them

Every operation is being informally redesigned all the time. Somebody adds a check after a bad week. Two of four people adopt a shortcut. An exception path invented for one awkward client gets reused for nine more.

None of that is misconduct. All of it is invisible, because nobody announces it, and all of it lands in the middle of a measurement window.

The result is a baseline that is an average of two processes, weighted by how long each one happened to run, with no way to separate them afterwards. You will not know. You will find out after go-live, when the honest re-measurement makes the automation look like the thing that underperformed.

What Hold actually freezes

The definition, not the work.

  • Which steps are inside the workflow and which are outside it.
  • What counts as an exception, written down rather than understood.
  • Who may change either of the above while measurement is running.

Alongside that, the data-quality holes that would corrupt the measurement get closed: the field populated half the time, the two systems that disagree about the same record, the timestamp that records when someone got round to logging the work rather than when the work happened.

What breaks without it

The failure is not dramatic, which is exactly why it survives. The project proceeds, the build ships, and somewhere in month two the numbers stop agreeing with each other. The team remembers the old process being slower than the baseline says. The vendor remembers it being faster.

Neither can prove anything, so the argument is settled by seniority, and the honest answer - that the baseline was taken against a process that no longer existed - never gets said out loud because nobody has the evidence to say it.

The alternative is a fortnight spent on nothing visible. That is the trade, and it buys the one thing that makes the measurement afterwards worth taking: a process that will still be the same process when the numbers come back. The wider discipline this sits inside is in the audit before automation.

Where it sits

Hold is the second of six stages. The one before it decides what is worth measuring, and the way that decision is made is described in what the Break map shows. The whole sequence, applied to one deployment, is in the protocol end to end.

Top comments (0)