Atoms aren’t bits
Digital government isn’t just about using computers—it‘s about a different way of building
It’s easy to dismiss modernization as simply moving physical processes into digital formats: making a paper form into a PDF, or sending an email instead of posting a letter. But this is digitizing, not becoming digital, and it misses the point:
Atoms are not bits.
Bits are free to create and destroy. You can make perfect copies of them. You can transmit them instantaneously. We take these things for granted in the modern world, but their impact is astonishing: they make things like the undo button and real-time collaboration possible.
Many government leaders still treat bits like atoms, and their modernization initiatives fail as a result.
Let’s look at just two of the ways that digital services made from bits are different: software is separate from hardware; and software can be constantly updated.
Software is separate from hardware
A Canadian citizen has to log into different portals for tax, benefits, passports, grants, and dozens of other government services (largely due to the Privacy Act of 1983 that prohibits departments from sharing data—which is why you need to update your address in dozens of places if you move.)
But if you think a citizen has it bad, spare a moment for government employees. In one department, an inspector needs to log into 20 different tools to do their job. That’s because when the government built these 20 systems, each tool was monolithic. That meant 20 separate computers, 20 separate operating systems, 20 different applications, and 20 different logins.
30 years ago, if you were packing for a trip, you might bring a camera, a flashlight, an alarm clock, a map, a walkman, a GPS, a voice recorder, a measuring tape, a wallet, some envelopes and stamps, and a calendar.
Today, you pack your phone.
This is the magic of digital: The separation of hardware from software lets one system (your smartphone) perform many functions.
It’s more than just convenience, however. These functions build atop one another: Your phone lets a map and GPS work together, so you know where you are. Your camera and email work together, so you can send your friend a photo. Your alarm clock and calendar work together so you don’t miss a meeting.
The separation of hardware and software reduces the complexity of the systems and increases convenience but also makes new things possible.
Imagine going on vacation with ten phones: One takes photos; one has a GPS; one has a calendar; and so on. That seems absurd, but thanks to how government procurement works, it’s the reality for many public servants. The government tends to buy whole, turnkey systems rather than extending existing ones, which makes their tools complex, inconvenient, and limiting.
Software can be constantly updated
If you’re building a bridge, it’s hard to deliver half a product. You have to finish the whole thing before it’s useful. That means defining the entire bridge up front, testing and validating the engineering, hiring the construction team, buying the materials, diverting traffic, and spending years building it. This is known as waterfall project management: Each step logically flows into the next, like a series of waterfalls.
This model makes sense when there’s no useful partially-built version. It also works when there’s no way to update what you’re building: If you launch a ship, you can’t really update the hull once it’s afloat. Atoms are hard to change once they’re in place.
Bits, on the other hand, are easy to alter. As I write this, Google Maps is at version 25.46.1.8304747750. That means there have been 25 major releases on the iPhone alone.
The first version of Google Maps was simply a draggable map. It was already useful. Since that time, Google has added navigation, street view, favorites, congestion reporting, and hundreds of other features.
There’s another important lesson here: humility. Google couldn’t anticipate that we’d have easy access to satellites on our phones, or that it would have a fleet of cars able to photograph every street. If you can’t be sure what the future holds, the best strategy is to learn by doing.
Bridge and ship builders don’t have this luxury: they can’t afford to get it wrong, so they have long, cautious, safety-laden plans and extensive testing. But because bits are easy to change, software is built iteratively. It gets updated. In software, we learn by doing.
This also means that the updates are never done: Google will constantly be updating Maps. Unlike a bridge or a battleship, there won’t be a day when the engineers and builders end their work.
Now imagine you’re trying to convince the public that they should support a project. “We don’t know what it will be like when we’re done and it will never actually be finished,” is a horrible pitch for any politician. Citizens want predictability and closure, not constant learning and adjustment.
Yet that’s the reality of software, and the government modernization initiatives that do work recognize it. They deliver the smallest possible valuable thing (something startups call the Minimum Viable Product) and then learn from it. Leaders need to have the courage to explain this to voters, and then quickly deliver results.
Software can adapt to you
A paper form must contain every possible answer. That’s why a tax document or passport application says things like, “to be completed if you were born in Canada” and “if Yes, go to section 5.”
It’s impossible to rewrite a paper form as a user is filling it out. But doing that with an online form is trivial. This means less wasted time, fewer errors, and a simpler process. That’s why Lisa Fast made getting the form right a priority when her team tried to modernize passports in 2013.
Done right, this means everyone gets a government app that’s tailored to their specific circumstances: a grant application that tells you what grants to apply for; a license renewal that describes what documents you need;
Digital government is a new way of working
Digital systems aren’t replacing atoms with bits—they’re changing how they work because atoms aren’t bits.
They’re less complicated, because they can perform many functions (like your phone) instead of requiring separate systems for everything.
They’re more convenient. Just as Google Maps can remember your address, and Uber Eats can remember your favorite foods, a digital system can store information so you don’t have to enter it every time, and guide you through a process that’s tailored to you.
Perhaps most importantly, they make new things possible. Ukraine’s digital government app became an important national security took in the face of Russian aggression; Estonian businesses save several days a year because the country’s services are online; a UK citizen living abroad can verify their identity by touching their phone to the biometric chip in their passport.
If you want to understand how digital changes the world, consider how people meet their partners today: https://www.pnas.org/doi/full/10.1073/pnas.1908630116 or that the average human born in 2000 will spend 17 years of their lives in a world of bits, not atoms.
Despite this, most government leaders treat digital projects and physical projects the same way. We build software the way we build bridges: everything defined up front, budgets set, schedules and deadlines promised. No software company would ever build this way, and yet it’s how government builds software.
Building software is a well-understood skill. There are plenty of proven techniques for delivering small, iterative improvements quickly and learning as you go. There are hundreds of books on Lean Startup, Agile project management, continuous deployment, and more.
Digital approaches mean different things matter more:
A desire to learn instead of a comprehensive plan.
Humble curiosity rather than expert confidence.
Defining the smallest, simplest new thing you can deliver instead of shipping the final projects.
Measuring what you’ve improved instead of the total cost.
Making cheap prototypes you can throw away instead of worrying about mistakes from the start.
Describing the budget as “what it will cost to understand” rather than “how much it will cost to build.”
This thinking has yet to truly find their way into government. From budgeting to procurement to management to delivery, we don’t know how to think digitally. Across all the conversations I’ve had in the last decade, this is the consistent, central truth: Atoms aren’t bits, and until our leaders understand the difference, modernization will fail.