How to break the waterfall in government
.avif)
Imagine you're trying to apply for a permit or submit paperwork on a government website. But the site is slow, confusing, or broken. You might ask yourself: why does it feel like every other website just works, but the government's doesn't?
t’s not about money. And it’s not about a lack of developers. The real issue is how government builds technology. Think of it like constructing a house—except every decision is made upfront, the ground conditions are unknown, and the builders aren’t allowed to deviate from the blueprint, no matter what they discover along the way.
This is the “waterfall” model. It works like this:
- Policy staff define the requirements—in detail—without talking to developers or users. These documents function like architectural blueprints.
- Technical teams do a quick feasibility check but rarely influence the core assumptions.
- Private contractors are hired to build exactly what’s on the page, even if they immediately see it won’t work.
The result: software that looks fine in planning documents, but collapses when it meets reality. Because when developers discover unexpected issues—like legacy systems behaving differently than expected, or requirements that contradict user needs—they have no way to adjust. Everything is locked in.
By contrast, modern tech companies don’t operate this way. They work iteratively. They release early prototypes, test them with real users, and refine based on feedback. They adapt when something fails. They fix problems when they’re still small and cheap. Most importantly, they prioritize whether what they're building actually works for the user.
To fix how government builds technology, three changes are essential:
- Break the waterfall. Involve tech teams and users from the start. Build lightweight prototypes early. Test with real users. Adjust quickly. Don’t lock in plans before seeing what works.
- Build internal teams. Don’t outsource entire systems to private vendors. Keep institutional knowledge inside the government. Hire engineers and designers into public service. Use external suppliers only for targeted tasks—not for mission-critical infrastructure.
- Create better working conditions. Skilled engineers want to work on meaningful problems. But they need autonomy, tools that work, and decision-making structures that support good engineering. That means less rigid hierarchy, fewer procurement bottlenecks, and room for experimentation.
This model works. The UK’s Government Digital Service (GDS) has shown how. GOV.UK replaced hundreds of disconnected sites with a single platform that’s fast, clear, and user-focused. It saved the British government billions while improving services for millions.
We don’t need more money. We need to stop treating software like civil engineering. Software isn’t static. It evolves. What we need are flexible systems, grounded in user needs, maintained by teams who understand them.
This shift—from fixed blueprints to living systems—is the first step toward public services that actually work. It reduces waste, increases public trust, and makes life easier for everyone. The tools exist. The knowledge exists. Now the structure needs to follow.