On slowness

There is a common wisdom, repeated mostly by people who have never shipped software inside an operation, that digital transformation projects fail because they are too slow. They say — you have to move fast. You have to pilot. You have to break things.

We think this is a misdiagnosis.

Most of the failed transformations we have inherited did not fail because they moved too slowly. They failed because they moved fast on the wrong question. They built an app before they understood the handover. They digitized a form before they asked whether the form should exist. They launched a dashboard built on numbers that nobody at the operation trusts.

Slowness, done right, is not the absence of speed. It is what you do early so you can move quickly later. We sit at the dispatch desk before we draw the dispatch screen. We spend three weeks learning how the shift foreman radios in a tally before we write a line of code that replaces the radio. We write down every exception — every time the foreman says "normally we do X, but last week we had to do Y" — because the exceptions are the system, whether the old one or the new.

This is not a pitch for craftsmanship. It is a claim about where the value compounds. The team that understands the operation fully will produce software the operators will use. The team that does not will produce software the operators will abandon.

The studio bills slowly and ships quickly. We think that is the right order.