Large transformation programmes fail quietly for eighteen months. A small slice in production fails loudly in three weeks, which is the useful kind.
The instinct with a broken operation is to fix all of it. Map every process, design the target state, agree a roadmap, and start a programme. It is the version that gets approved, because it is the version that looks serious in a board pack.
It is also the version where nothing is real for months. Requirements drift, the people who described the process move on, and by the time anything is deployed the business has changed shape underneath it. The programme does not fail dramatically. it just gets quietly rescoped until it is a smaller thing delivered late.
A slice is one painful workflow, taken end to end, and put into production beside the manual process. Not a prototype, not a pilot in a sandbox. Live, with real data, doing real work, while the old way keeps running until people trust the new one.
It has three properties worth insisting on. It is small enough to ship in weeks. It is complete. a thin vertical through every layer, not a half-built horizontal one. And it produces a number the business already cares about, so success is not a matter of opinion.
If the first thing you ship cannot be evaluated by someone who does not work in technology, you have not sliced it properly.
Shipping something small teaches you things no workshop does. You find out where the data is actually dirty, which integration has undocumented behaviour, which exception nobody mentioned because it is normal to them, and how the team really uses the tool versus how they described using it.
Every one of those discoveries would have been a change request in a big programme. Here they are just the second slice.
Trust is the constraint, not capability. People do not stop doing a task by hand because a system exists; they stop when they have watched it be right for long enough. So we run new automation in parallel deliberately, with the output visible, until the manual version is obviously redundant.
On one support automation, the team kept answering enquiries manually for two weeks after the system was live, comparing. Then they stopped, without being asked. That is what adoption actually looks like. nobody announces it.
Slicing has a commercial consequence worth stating. Each slice can be priced before it starts, because it is small enough to estimate honestly. You are never signing an open-ended engagement on the strength of a diagram, and we are never quietly absorbing scope to protect a fixed price on something nobody understood yet.
If the first slice goes badly, you have spent weeks and you own the code. That asymmetry is the point. It should be cheap to find out whether working together works.
