Digital Transformation as a Sequence of Reversible Bets
Most digital transformation stories that go wrong share a common shape. A leadership team decides the business needs a new system, a large project is scoped in one go, and by the time anyone checks whether it works, the old process has been switched off and the staff have stopped using the workaround that kept things running. The change is hard to undo, so problems that appear in month four get patched rather than fixed. This article takes a different angle: treating each transformation step as a bet that can be reversed, measured and paused. This is general operational guidance, not a recommendation of any particular product or vendor, and it is written for UK founders and operators who want change that holds up under real working conditions.
Why reversibility is the underrated design goal
When people plan digital change, they usually optimise for the destination: the target system, the end state, the savings projected in a slide. Reversibility rarely appears on the plan. Yet it is often the most useful property a change can have, because it determines how much you can learn before you are committed. A reversible step lets you find out what you got wrong while the cost of being wrong is still small.
A practical test is to ask, before any step starts, what state you would return to if it failed. If the answer is 'we would need to rebuild the old process from memory', the step is not yet ready. If the answer is 'we would switch the new tool off and the spreadsheet is still there and up to date', the step is reversible in the sense that matters. Keeping the previous method alive for a defined period is often the cheapest insurance a small business can buy, and it costs little more than discipline.
Cutting a transformation into checkable slices
A workable slicing rule is to change one flow of work at a time, and to define that flow by its inputs and outputs rather than by the tool used to run it. For example, 'quote approval for orders over a set value' is a better slice than 'move everything to the new CRM'. The slice has a clear start, a clear finish, and a set of people who will notice quickly if it breaks.
For each slice, write down three things before starting: the success measure (for instance, the number of quotes that stall awaiting approval), the duration of the trial, and the condition under which you will stop. Keep the success measure simple and observable. Avoid measures that depend on the vendor's own dashboard, because you want evidence that does not come from the party selling the change. Set the stop condition in advance, so that the decision to continue or pause is not made under the pressure of sunk cost.
Mapping the seams before you cut
Most transformation trouble happens at the seams between steps, where one person hands work to another, or where data moves from one system to the next. A process that looks clean on a diagram often depends on someone quietly re-keying a figure, checking an email, or remembering an exception. These undocumented actions are the first things to break when the flow changes.
Before a slice goes live, walk through a real recent example from start to finish and note every handoff, every place a human adds judgement, and every file or field that is touched. Ask the people who do the work, not only the manager, what they do when something is unusual. The list you produce is usually longer than expected, and it becomes your test script: each item is something the new arrangement must still handle.
A practical checklist for each reversible step
Use the following questions as a plain checklist before approving any digital change. First, what is the single process being changed, and where does it start and end? Second, what is the old method, and who will keep it available during the trial? Third, what measure will show whether the change is working, and where will that number come from if not from the vendor? Fourth, how long is the trial, and what date will force a decision? Fifth, what is the stop condition, written down and agreed by the person who will have to act on it?
Sixth, who has administrative control over the new arrangement, and who can change or remove access if a role changes? Seventh, can the data created during the trial be exported in a usable form if you decide to leave? Eighth, which seams were identified in the walkthrough, and has each one been tested? Ninth, who is the named owner who will make the call at the checkpoint? If you cannot answer any of these in a sentence or two, the step is not yet ready to start, and that gap is worth closing first.
Keeping a record so the next decision is easier
Transformation rarely ends with one project. Teams make dozens of smaller decisions over a year, and most are forgotten within a few months. A short decision record for each slice, noting what was tried, why, what was measured, and what was decided, turns those experiences into institutional memory. It also helps new staff understand why a process looks the way it does.
Store these records somewhere the whole team can find, and review them at a fixed point each quarter. Patterns tend to emerge quickly: certain kinds of change keep stalling at the same seam, or a particular measure consistently fails to predict success. Those patterns are far more useful for planning the next round than any single vendor claim, and they help you get better at judging evidence over time.