Throughout it all, politicians, engineers, and public health officials had to keep people’s information safe—and, perhaps even more of a challenge, convince the public they were succeeding at it.
What would it take to actually make government technology work well in the US? What are the basics of a healthy technological infrastructure that can work for the residents who need it?
We asked five experts to help us understand why it’s so hard to build good government technology, and for their advice on how to create a healthy technological infrastructure for the people who rely on the outcomes.
A fractured landscape of data
Cyd Harrell: “Government” in the US means a lot of different things. After the federal government, we’ve got 50 state governments, 3,000 counties—which play different roles in different parts of the country—and 20,000 municipalities.
So many different parties own pieces of the data needed to identify whether you, in a particular location, are eligible and can get an appointment at a place with a stock of vaccines. Not just governments, but hospitals, clinics, and drug stores, they all need agreements to share that data, and to make their systems work together, which they almost certainly don’t.
After all that, web design—and accounting for people who don’t have web access—may actually be the easy part.
Alexis Madrigal: A lot of the time, the actual technology isn’t that complicated. The problem is the system underlying the tech. When the federal government wants data that states don’t normally produce for their own work, someone has to put that data together. During an emergency, when everyone has shit to do, it’s not a priority. Without a national healthcare system, there’s no way to easily track tests or overall cases.
Legacy processes and systems, new vendors
Sha Hwang: I call working with legacy systems “software archaeology.” It’s like homes built before city infrastructure existed—they weren’t built to connect to city plumbing or a power grid. You have to find the one person who’s been maintaining the system for 30 years, updating a spreadsheet that’s a million rows long with a crazy color-coding system.
For new systems, there’s a phrase you hear a lot: government buyers want “one throat to choke” if something goes wrong. Big vendors like Deloitte and Accenture will bring in all the people needed for a project. But by outsourcing the potential blame, agencies also cede all the technical expertise. They get locked in. If the system fails, they have to rely on vendors who dug the hole to get them out of it.
Dan Hon: No one gets fired for hiring Deloitte or IBM. And when vendors keep getting the same kind of work they’ve done badly, there’s no incentive for them not to build a shitty system. Government requests for proposals are often written so they only fit one or a few vendors. You might see a yes or no box for, “Vendor must have worked on a healthcare system that serves over 500,000 people.” I don’t care whether that system exists, I want to know whether people who have to use it hate it.
Liana Dragoman: A lot of services are designed around how government works, as opposed to the needs of residents. If you’re trying to get a permit to use a soccer field, you shouldn’t need to know which specific department within Parks & Rec can give you that specific permit. Residents just want to go to the city website and fill out the form.
What’s one significant mismatch you’ve seen between public needs and government tech?
Navigating a system that’s complex by design
Hon: There’s a lot of regulatory complexity in vaccine distribution. But on the website or in the app, the experience is condensed down to, “Why can’t I find out if I’m eligible for a vaccine? I just want an appointment.”