Operations

Measure the routine before you improve it

The obvious candidate for improvement is usually the one you notice, not the one that costs you.

Improvement work has a bias built into it: you fix what is annoying. Annoying and expensive are different properties, and they overlap less often than you would think.

Count it in production first

Before rebuilding a process, find out how much it actually runs. Not how much you think it runs — how many times last month. Two questions settle most arguments: how often does this happen, and how long does each one take?

The answers are frequently uncomfortable. The workflow everyone complains about turns out to run four times a month. The one nobody mentions runs eleven times a day. Effort follows attention rather than volume, and attention is a bad guide.

The second measurement nobody takes

There is a running cost as well as a build cost, and it is the one that goes unexamined because it arrives in small amounts. Anything metered grows quietly, because the thing that increases the bill is the same thing that signals success: more use.

Do the arithmetic once for each automated routine — what a month of it costs — and put a hard ceiling on anything usage-based, so a runaway process becomes a stopped process rather than a surprise invoice.

Change only what the data asks for

The discipline that follows is uncomfortable but simple: touch what the measurement says is expensive, and leave alone what merely bothers you. A change that makes something feel better without moving a number is not an improvement. It is redecoration with extra risk.