What’s in it for me? Lead digital projects that actually launch, scale, and last.
Most large organizations struggle with digital change not because they lack talent or resources, but because their systems are designed to resist it.
Legacy contracts, rigid hierarchies, and outdated processes all create pressure to maintain the status quo.
At the same time, public expectations keep rising.
People want faster, simpler, more reliable services – and they don’t care how hard that is behind the scenes.
Real progress comes from building small teams that deliver working services quickly, using data to guide decisions and actively clearing the obstacles that slow things down.
Rather than focusing on abstract planning or large-scale reform, effective digital change grows through consistent execution and practical problem-solving.
In this Blink, you’ll learn how smart digital teams get started, how they earn trust through delivery, and how they build the authority to change large systems from within.
You’ll also see what it takes to keep that momentum going – and why lasting change depends on changing how institutions work, not just what they build.
Large organizations often revisit how they work only when something stops working.
Real change starts when the old ways fail
A failed system, a collapsed service, or a major public failure can highlight long-standing problems and bring urgency to decisions that have been postponed.
This kind of disruption can clear the way for a different approach – one based on building services that actually work for users.
To begin real change, four conditions help the effort take hold: a clearly recognized failure, senior political support, a team with the right skills, and a focused goal.
Without these, attempts at improvement tend to fade or get lost in bureaucracy.
In the UK, these conditions came together in 2011.
After years of oversized IT contracts and weak online services, the government created the Government Digital Service – GDS – to improve the way it delivered digital services.
Francis Maude, the minister in charge, made the initiative a top priority.
He backed the team with the authority to make decisions across departments.
The GDS hired people with experience in civic tech and digital product delivery, including developers, designers, and user researchers who’d spent their careers building tools for real users.
Their job wasn’t to write strategy documents.
They were expected to deliver.
The team set one clear goal to start: replace thousands of disjointed government websites with one, usable site for public services.
That became GOV.
UK.
The project delivered quickly and showed that better services could be built inside government.
Early results created the momentum to expand.
A strong start mattered more than a wide scope.
The team chose clear problems they could actually solve and avoided distractions that would slow them down.
Once the basic conditions are in place, the next step is to decide what to do first.
Let’s look at that next.
You don’t have to fix everything to get started
One of the first challenges digital teams face in big organizations is pressure to fix everything at once.
The problems are piling up, the system is creaking, and people expect instant solutions.
But trying to solve everything immediately is a trap.
A better approach is to start with something small and useful – and make it work really well.
When the GDS got going, it was surrounded by major IT disasters and long-running policy failures.
It would have been easy to get drawn into those.
But instead, the team focused on showing they could deliver one thing, fast, that users would actually notice.
That early example was the alpha version of GOV.
UK – a prototype built in just 13 weeks.
It replaced a chaotic patchwork of government websites with one clean, functional site.
It wasn’t perfect, but it worked.
And that mattered more than anything else.
The trick was resisting the pull of familiar habits – long planning cycles, big launch events, committees debating theoretical risks.
The team set clear principles for how they’d work: start with user needs, release early, improve constantly, and be open about progress.
These ideas came directly from what had already worked in practice.
That’s also why they published them publicly – to signal to others that this way of working was real and possible.
There’s a strong temptation in large institutions to wait for perfect conditions before making a move.
But most of the time, it’s the first move that creates better conditions.
It builds confidence, attracts good people, and gives skeptics something concrete to evaluate.
Choosing the right starting point matters.
And the best early projects are simple, visible, and fast to deliver.
In the next section, we’ll look at how this focus on early delivery builds momentum – and why going public at the right time makes a difference.
Quiet delivery builds the strongest reputation
New digital teams often face a lot of internal attention before they’ve had a chance to build anything.
Leaders want announcements, media teams want headlines, and departments want their priorities on the roadmap.
The safest move is often the least exciting one: keep your head down and get something working before stepping into the spotlight.
Holding off on publicity gave the GDS space to build trust.
Its early successes – like shipping the GOV.
UK prototype and the e-petitions site – were delivered without fanfare.
This was deliberate.
Avoiding a big launch helped the team avoid becoming a target before they had anything to show.
It also meant that when they did go public, they had proof of delivery, not just promises.
Inside government, where flashy initiatives often disappear without results, that counted for a lot.
As the team grew more visible, new risks came with it.
Expectations increased, and different groups tried to influence the agenda.
The core delivery team didn’t try to manage all of that themselves.
They were supported by a second layer – a group of experienced insiders who understood how the system worked.
These were people who could untangle bureaucratic obstacles, handle difficult stakeholders, and quietly clear the path so the delivery teams could focus on shipping.
The team called them bureaucratic hackers.
They were essential to making early wins possible.
Moving too fast without this kind of support can derail progress.
But when delivery teams are protected from politics and paperwork, they build confidence inside the organization and momentum for bigger change.
The first real tests of a digital team happen after those early wins.
That’s when leadership expectations grow, and outside interest sharpens.
In the next section, we’ll see how teams handle that spotlight – and what it takes to turn credibility into long-term influence.
Shipping something that works changes the conversation
Once a digital team starts delivering real services, everything shifts.
People inside the organization begin paying closer attention – not just to what’s being said, but to what’s actually being built.
And at this point, credibility becomes the team’s most valuable resource.
Not branding, not vision decks, but working services that users can see and use.
This is also the moment where many well-meaning efforts stall.
A lot of teams get caught in what looks like innovation but never reaches users.
There’s a difference between running workshops and actually replacing a clunky service with something faster and clearer.
What matters now is follow-through.
Prototypes and experiments are useful, but they have to lead somewhere real.
That’s how digital teams earn permission to do more.
When the GDS was getting started, it chose a public-facing service with high visibility but manageable risk: the e-petitions platform.
It was greenfield – meaning there was no major legacy system to untangle – and it gave the team a chance to prove that they could build a digital service that scaled to national demand.
Within weeks of launch, thousands of users were submitting petitions, and some led to parliamentary debates.
The service was public from the start, giving users direct access and showing that large-scale digital delivery could be visible, responsive, and effective.
At the same time, the team avoided taking on too much.
They picked services that could be built and improved quickly.
They stayed close to user needs and released working versions early.
That approach helped them sidestep the expectations trap – where teams get stuck promising more than they can deliver.
Momentum came from that simplicity.
By focusing on a few visible improvements, they avoided being dragged into abstract innovation and instead built trust through practical execution.
When teams prove they can deliver at scale, pressure grows to take on bigger systems.
In the next section we’ll look at how they can build the authority to take that step – and win the power to change more than just the front end.
Authority comes from what you can stop, not just what you can build
After early wins, digital teams often face a tougher question: can they influence how the rest of the organization works.
It’s one thing to launch a new service.
It’s another to stop bad ones from being built.
And that’s where real authority starts to matter.
Most large institutions are full of legacy systems and expensive contracts that run on autopilot.
Changing that means shifting power.
For the GDS, that shift began with a clear mandate to review digital spending across departments.
After demonstrating success with early services, the team made a direct appeal to top ministers for more control.
They asked for the right to challenge big IT decisions – and they got it.
That mandate marked the beginning of broader influence.
The GDS built new tools while also shutting down outdated ones.
The team reviewed major tech investments across government and had the authority to stop those that didn’t meet quality standards.
Their focus was on using public money responsibly and making sure services met the needs of users as well as operational goals.
That influence grew through the credibility the team built by delivering quickly and being transparent about results.
With that foundation, they were able to push for practical changes such as shorter contracts, open standards, and rebuilding in-house technical skills.
Alongside proposing better approaches, they focused on clearing the path so others could adopt them as well.
A central mandate only works if it clears the way for better delivery at scale.
And the better a team gets at spotting and fixing structural blockers, the more it’s trusted to lead.
In the next section, we’ll see how digital teams use data to decide what to tackle next – and why targeting high-traffic, high-cost services is often the smartest move.
The smartest fixes start with the biggest numbers
Many digital teams begin by focusing on what’s broken or outdated.
But the more effective strategy is to start with what’s big.
That means looking for services with the highest user demand or the greatest cost to deliver – because that’s where even small improvements make the biggest difference.
The GDS didn’t just rely on gut feeling to decide what to work on.
It created a tool called the Transactions Explorer, which tracked data on hundreds of government services.
It showed how many people used each service, how much it cost to process, and how many steps it took to complete.
With that information, the team could see at a glance which services were ripe for redesign.
One example was registering to vote – a high-volume task with a clunky process.
By rethinking it from the ground up, the team built a simple digital service that millions of people could use easily in just a few minutes.
The data helped with prioritization and gave the team a clear way to measure progress.
When they launched a redesigned service, they could track if it was faster, cheaper, or easier to use.
That helped keep focus on user outcomes, not just internal milestones.
It also gave ministers and senior officials something concrete to support.
Instead of vague claims about modernization, they could see real numbers improve.
This kind of approach helped build a culture of smart decisions grounded in evidence.
It allowed the team to justify their choices and argue persuasively for change without getting pulled into abstract debates.
Once teams know where they can make the biggest impact, the next challenge is sustaining that work.
In the final section we’ll look at what happens after the early momentum fades – and how to make digital change last.
Real progress means rethinking how the whole system works
Delivering great digital services is only the first step.
What comes next is harder.
Once the early wins are in place and the most visible fixes are done, the real challenge is making change stick.
That means shifting the deeper structures – things like funding models, performance frameworks, and the way risk is managed.
Without that, even the best digital teams can burn out or stall.
The GDS faced this exact moment.
After building a strong track record, the team started to run into barriers that weren’t technical at all.
Some departments still relied on decades-old procurement contracts.
Budget decisions were made on annual cycles that didn’t match how digital products evolved.
Success was measured by compliance and delivery of fixed outputs, not whether users could actually get what they needed.
These problems required new ways of thinking about accountability, control, and value.
One of the most important shifts was helping decision-makers understand delivery teams as long-term assets – not temporary project groups.
That meant building stable teams that could improve services over time, instead of spinning up new contractors for every new feature.
It also meant treating digital work as operational infrastructure, not one-off initiatives.
Sustaining that kind of progress takes leadership that understands what good delivery looks like and why it matters.
It takes space to experiment, adapt, and iterate – especially when things change.
And it requires constant attention to the basics: hiring well, giving teams clear missions, and protecting the conditions that allow them to keep delivering.
What begins as a focused push gradually becomes standard practice.
Lasting change takes hold when digital work becomes a normal part of how the organization operates.
This approach helps institutions stay responsive, improve continuously, and build long-term capability.
Final summary
The main takeaway of this Blink to Digital Transformation at Scale by Andrew Greenway, Ben Terrett, Tom Loosemore, and Mike Bracken is that meaningful digital change happens when delivery comes first.
Real progress doesn’t come from top-down strategies or long planning cycles – it comes from building small, empowered teams that solve real problems, prove what works, and earn trust by delivering results.
When those teams are backed by strong leadership and protected from bureaucracy, they can shift the tools an organization uses and how that organization works.
The most successful efforts start small, target services with big impact, and use data to guide decisions and measure progress.
Over time, this way of working becomes the standard for how things get done.
That shift is what makes digital transformation sustainable.
And once it takes root, it creates organizations that are more agile, more capable, and more focused on what users actually need.
Okay, that’s it for this Blink.
We hope you enjoyed it.
If you can, please take the time to leave us a rating – we always appreciate your feedback.
See you in the next Blink.