The “50” in FWD50 comes from a tool we use to decide on content: What policies can change in 50 days? What platforms can be built in 50 months? What society do we want in 50 years?
This year, we’re looking at timeframes in a different way. The task of digital government modernization isn’t just “are our services available digitally?” It’s also a mindset that comes from the fact that digital is fundamentally different from physical.
Think of a rock. It’s permanent: Unless you actively try to destroy it, it’ll be there for a while. It’s also uncopyable: If I have the rock, you can’t have it as well. If I smash the rock in two, I can’t roll back time and put it back together perfectly.
Now think of a digital file. Unless you work to keep it there (by giving the machine electricity, backing up the hard drive, or paying your cloud bill) it’s gone. I can make a billion identical copies. And I can always restore an earlier version.
This seems obvious to anyone who’s ever kicked a rock or used the Internet. But we seldom think about what this means for our work. Governments still have a one-way process: Pass the law, get the budget, write the specifications, hire the contractors, and build what you promised to build (this is known as a Waterfall approach to project management, because it flows in one direction—and perhaps because it often mangles the things that go over it.)
There are better ways. If you’re building a table, and learn that the design is wrong, you adjust the original plan. But in most government departments, you just keep going. There’s no way for the people delivering the service to go back and change the policies even if they now know the policies are wrong. This is something Jennifer Pahlka talks about incredibly eloquently in Recoding America, and it’ll be a major theme of FWD50 this year.
Those who want to modernize government have to work in three timeframes of their own:
Turning the past into the present
There’s plenty of low-hanging fruit in the halls of government, and simply modernizing ancient systems or providing digital alternatives offers plenty to work on. In many cases, these systems are outdated because of folklore: The Paperwork Reduction Act in the US is often used as an excuse not to speak with end users, which means we design systems for the government process rather than the end user need.
Departments are starting to hire product managers, who advocate for the end users, but they’re still relatively rare. And without product managers, we don’t really understand the constraints and requirements of our users.
For example: Many people trying to qualify for food stamps have only a mobile phone; to use a desktop computer, they have to grab a time slot at a library; if their time runs out before they complete the form, they have to come back another day.
We need to stop valuing correctness over usefulness, and design for the user, not for the process.
Turning laws into implementation
Legislators write Byzantine laws that often take up tens of thousands of pages. This has to stop. There’s no way to hand someone a 70,000 page tax code and say “make this an app.” Some of these laws are intentionally complex. In other countries, filing taxes takes fifteen minutes for most people; in North America, it’s a Billion-dollar industry.
Any system that wants to stay organized needs to invest some of its energy into administration. A team of ten people is easy to coordinate with regular meetings; a team of a hundred requires dedicated managers; a team of a thousand has managers who just manage managers. The bigger a system gets, the more management it requires. The number of public servants in local government has, according to some studies, grown four times as fast as the population in those areas.
This is an immutable law of physics: Eventually, a system cannot pay for the cost of holding itself together. Entropy affects all things, even bureaucracies. The only way to solve this is to reduce complexity itself, simplifying laws. Part of legislation must be “is this implementable?” We need to get better at writing policies that can be turned into digital services.
Making the impossible possible
Technology advances at a breakneck speed. Government is a technology laggard, often with good reason: Embracing the newest tools can often exacerbate the digital divide. But that’s no reason to stay in the stone age when there are perfectly good tools to be had. We need to ask ourselves, “what’s now possible?”
Path Dependency happens when the conditions that created something tend to perpetuate that behaviour. The US was late to adopt PIN-and-chip credit cards because it pioneered credit cards, and everyone had those carbon-copy signature machines. By contrast, Africa did not have widespread land line telephones, so it was quick to adopt mobile phones.
Here’s a great example from Jen’s book: In order to qualify for government assistance, you need to authenticate yourself. That means filling in detailed forms with personal information like your name and social security number. If an applicant made even one error in these forms, they’d be referred to a much slower process. This was well-intentioned, of course: Governments need to protect such assistance programs from fraud.
Except that’s not how it works. You know who gets all the numbers and names exactly right? Fraudsters. They’ve bought fake IDs and they’re copy-and-pasting them. They don’t make mistakes. If anything, a mistake is a sign that you’re not fraudulent.
So a team modernizing such forms came up with a new solution: Take a photo of yourself, and a photo of your ID, and upload them. A facial recognition tool will check to see if they’re the same. Much easier and faster for the applicant; and it has the added benefit of making life miserable for fraudsters. Fraud actually went down, while successful applications climbed.
In another case, COVID test distributions revealed that the postal service’s database of residence wasn’t up to date. So developers gave users the option to flag that the data was incorrect—and updated the database far more quickly and efficiently than they would have if it had been a separate project. Being opportunistic helps us catch up to the future.
We’re going to be tackling these three topics at FWD50 in November. Whether you want to drag the past into the present, create policies that can become amazing apps, or find technologies that make new things possible, it’ll be a great conversation.