This is the second story in a series reflecting on how organisations can deliver complex change by building momentum and trust.
When senior leaders face a transformation of scale - whether it’s dismantling legacy technology, shifting how an entire organisation operates, or completely redesigning the customer experience - their default instinct is to think big. They commission a comprehensive, multi-year plan. They want a roadmap that promises to fix every feature, appease every stakeholder, and replace the entire architecture in one triumphant “big bang” launch.
In my experience this all-or-nothing mentality is precisely how large programme failures are born. When you try to deliver everything at once, you starve the organisation of a critical currency: trust. A multi-year roadmap requires stakeholders and users to run on blind faith for months, or even years, before they see a single shred of value.
In my previous post, I talked about how essential momentum is to outpacing complexity. But how do you build that momentum in the first place when the mountain ahead looks too steep to climb?
The answer requires immense leadership discipline: you must break the problem down into small slices so that you can deliver value early. Delivering a small, tangible piece of the bigger picture is the single most effective way to build the credibility needed to sustain a massive transformation.
Between 2013 and 2015, I saw firsthand how this approach worked during the Government Digital Service (GDS) “25 Exemplars” programme - a mandate to modernise the UK government’s top 25 citizen-facing services in just 400 days. Sitting right near the top of that list was the DVLA’s Vehicle Management service.
The multi-million transaction paper beast
If you have ever owned a car in the UK, you have held a V5C vehicle logbook. For decades, that physical piece of paper was the absolute center of gravity for vehicle administration. Whether you were buying a car, selling it, part-exchanging it at a dealership, changing your address, or scrapping the vehicle entirely, it required filling out the paper logbook and dropping it in a postbox.
Once it arrived at the DVLA in Swansea, a civil servant had to manually open the mail, process the update on the legacy database, and print and post a replacement logbook back out to the keeper of the vehicle. It’s slow, labour-intensive, and generated an astonishing volume of paper - handling over 20 million transactions a year.
Vehicle Management isn’t just a single thing; it’s a sprawling ecosystem of workflows serving an incredibly diverse user base, from individual drivers to massive commercial car dealerships, fleet operators managing hundreds of thousands of cars, and authorised scrap dealers.
If we had tried to build a digital system that catered to all of those transactions and all of those users on day one, the complexity would have choked us. More importantly, the organisation would have lost faith in our ability to deliver before we ever wrote a line of code. We had to find a way to slice the problem thin to show tangible progress.
Just start somewhere
The most common objection I hear from leaders at this stage is: “But where do we start? How do we know we are picking the right piece?”
The truth is, there is rarely a single right or wrong place to start. Every service, department, and organisation will have different pressures. The critical element is not finding the perfect starting point; the critical element is simply choosing a slice and starting.
At the DVLA, our first strategic slice was to separate the needs of large organisations from the general public. We carved out a high-volume service aimed specifically at companies that managed a huge number of vehicles. This became View Vehicle Record, which allowed corporate fleet managers to easily view and check their massive inventories online without generating a single piece of paperwork. (We also carved out Personalised Registrations as its own standalone challenge for a later date).
By launching this service early, we proved to internal stakeholders that we could securely expose legacy data to users. We didn’t solve the whole problem, but we bought ourselves immense credibility.
Finding the thinnest transactional slice
That left us with the core transactional problem: the millions of annual requests to actively change a vehicle record. To find our first thin slice of this massive web of transactions, we looked at the data to find where the highest volume intersected with the lowest relative complexity.
We focused on the lifecycle of buying and selling a vehicle. Within that space, peer-to-peer sales between private individuals are messy and carry high fraud risks. But there was a much cleaner, commercial subset: ‘disposal into trade’ - the process of somebody selling or part-exchanging their car to a registered motor trader.
Car dealerships were the perfect initial users for our first transactional slice. They were professional, comfortable with technology, well-known to the DVLA, and deeply incentivised to eliminate paper delays. The sooner a dealership can officially register ownership of a car, the sooner they can legally and confidently move it through the trade, send it to auction, or sell it on. Waiting weeks for a paper V5C to clear through the post was a massive drag on their business and finances.
By narrowing our initial delivery entirely to disposal into trade, we could focus on a clean, B2B workflow. The goal was simple: allow a dealership staff member to process a part-exchange online in minutes while the customer was still sitting at the desk.
When you ruthlessly limit your scope to a single, thin transaction type, your speed of delivery accelerates dramatically. And speed breeds momentum, which in turn breeds trust.
The timeline from my weeknotes at the time tells the story of this progression. We kicked off discovery and inception in June 2013, diving into the data to understand the landscape and isolate that first crucial slice.
Looking back honestly, the gap between discovery and actual construction was still far too long. Although we wrapped up our analysis in the summer, we didn’t enter our Alpha phase until early February 2014. That intervening period was entirely eaten up by internal approvals, business case validations, governance, and the friction of bringing in the right delivery capability. It’s a classic pain point that slows down almost every large change initiative, long before a single line of code is ever written.
However, once we cleared that hurdle and actually started building, the momentum was undeniable. Just two weeks into Alpha, we already had a working prototype to test with real users and were actively exploring how to plug it into the DVLA’s legacy systems. By March, we were going through our formal service standard assessments, and by April, we were already moving onto our Beta.
We went from a blank sheet of paper in development to a real, working Beta service integrated with legacy systems in a matter of weeks. Every time we passed a milestone at that pace, the skepticism inside the building began to evaporate.
Pragmatic trade-offs over perfection
Slicing a problem thin also requires making pragmatic trade-offs that can horrify traditional technologists but are vital for maintaining momentum.
The most prominent example during the Vehicle Management project was our decision to let the digital service “go to sleep” at night. The DVLA’s legacy systems relied on heavy overnight batch processing; they literally could not handle real-time database updates 24/7.
A traditional transformation roadmap would have halted the entire programme for three years to fund a massive, high-risk mainframe replatforming just to ensure 24/7 database availability. We took a different path. We accepted the constraint of the legacy system, built the digital transaction layer to mirror the mainframe’s operating hours, and put up a “closed” sign at night.
I’ve written before about why some DVLA digital services don’t work at night, and the lesson remains unchanged: it is always better to deliver a service that provides massive value for 12 hours a day right now, than a perfect service that doesn’t exist for five years. By choosing the thin slice, we chose to deliver value early, keeping the momentum and building institutional trust.
Establishing the delivery flow
Once that first slice was live and motor traders were eagerly adopting it, we didn’t just stop and congratulate ourselves. We used the momentum and trust we had built to establish a continuous delivery pipeline.
We moved directly onto the next sequential slices of the service: buying a vehicle from a dealership, managing private sales between individuals, and handling changes of address for the registered keeper.
Instead of treating these as entirely separate projects, we established a rolling flow. As one part of the service was being delivered and rolled out into Live or Beta, the team was actively taking the user data and operational lessons from that launch to inform the Alpha and Discovery phases of the next piece. This continuous feedback loop meant that our delivery capacity grew stronger and more efficient with every slice we shipped.
The strategy is delivery
The lesson for any leader steering a major change is simple: the risk of a transformation is directly proportional to the amount of value you defer to the end. If your roadmap says you won’t deliver anything tangible to a real user or stakeholder for eighteen months, your strategy is broken because your organisation will run out of patience and trust long before then.
Stop trying to fix the whole system at once. Find your version of disposal into trade. Find the slice of your transformation that allows you to test the riskiest assumptions. Build a prototype in weeks, not months. Put a live service in front of people, show them that progress is real, and use that hard-earned credibility to unlock the next phase of your journey.
Momentum is built on a foundation of trust. And trust is built by delivering one thin slice at a time.
