Why is it so hard to build government technology?
It’s been a long, challenging year for government technologies. Some have failed massively, requiring endless patches by governments, business, and the informal volunteer corps who have come together to fill the holes.
Developers had to build apps that could identify potential covid exposure without invading people’s privacy. Notoriously janky unemployment websites were crushed under the weight of massive job loss. And we needed new data pipelines to compensate for America’s uniquely fragmented healthcare industry.
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.”
People are completely right to be incredibly pissed off when it doesn’t work that way. But this is how the system was designed. America has an obsession with federalism and delegating power down to progressively smaller authorities. You really wanted that, you built for that. This is what you get.
Tracking data across states’ many systems
Madrigal: Last year, the federal government paid $750 million dollars for a bunch of antigen tests to send to states. It came with an app, so you could show your test result on your phone. But there wasn’t a way for places doing the tests to report the results to the government. There weren’t even “lot” numbers on the tests. States had to build their own tracking systems. They put numbered stickers on the tests, so sites could report which ones actually got used.
The US Digital Service eventually built a test record system called SimpleReport, which I’ve heard works pretty well. But to date, we still have no idea how many antigen tests have been done in the United States. Not even a rough approximation. It seems like the kind of thing you’d want to track.
Shifting city workers and residents to remote services
Dragoman: When [Philadelphia] went into lockdown, we worked with an independent board at the city that negotiates with residents and businesses on payment plans for overdue bills. It’s an essential service—if people can’t get a hearing, they could lose utility access, their business license, or their homes.
We got everyone laptops, but existing processes relied on paper-based workflows and in-person interactions. There is a physical paper file with all the letters, information and communication about a petition, and a physical paper calendar that staff use to manage scheduling. The only pre-existing tech was a system that spits out acknowledgement and decision letters to be mailed to residents.
To replicate that with Excel and Word files, we had to train folks on Sharepoint. Step one, open up Sharepoint. Step two, create a document. When the office reopened, some cases were entirely on paper, and some were entirely online. We had to completely redesign the workflow so staff could function.
Considering technology for people in crisis
Harrell: Most unemployment systems were set up to assume there’s a strong employment market, and people applying for benefits are probably trying to game the system. When we suddenly had 25% unemployment, the systems couldn’t easily shift to just getting people money.
Hwang: We recently worked with a state on their new family and medical leave policy. To make sure people receiving benefits actually needed it, they wanted people to recertify weekly that they still needed benefits. We had to help the legislators understand it would cost caseworkers time, it would mean families with infants would have to prove every week that they still have a newborn.
We asked them what, specifically, they were trying to prevent, and convinced them to change the language to limit who had to recertify. There’s a lot of complexity. Sometimes you have to celebrate getting one bullet-point changed in a draft regulation.
Surviving a crash test
Madrigal: Relying on technology to increase access to government services isn’t going to work when there are policies intended to restrict the use of aid by making it difficult to access. There’s leverage right now to change those policies, but first we have to be honest about what they’re for.
Hwang: Senator Ron Wyden recently introduced a bill to modernize unemployment benefits—reading it was pretty amazing. It’s a really tech-literate piece of legislation. They’re actually thinking about building more technical capacity within the agency, and trying not introducing administrative burdens. We’ve underinvested in adapting to the modern environment. Without technical literacy in-house, we’ll keep seeing failed roll-outs and broken promises.
Hon: You can’t think of this as “building computer systems during covid.” You’re delivering government during covid, and you can’t deliver government without technology. Covid has been a crash test for government systems. To actually fix the failures, and keep them from happening again, technologists have to be part of the department, not just be there to make sure the printers work, or if there’s an IT project.
Understanding what people truly need
Dragoman: If you want to fix problems with vaccine delivery, you have to go to vaccine sites and interview the workers and the people getting vaccines. You have to look at the Post-Its around the computers, all the one-page documents that have been copied a million times to explain the program. All the work-arounds these brilliant people have figured out so they can actually do their jobs.
Then invest in people who can take those lessons and really implement them. If governments care about being inclusive, they also need to pay attention to how government information is communicated. Not just in different languages, but acknowledging what somebody may be experiencing. If somebody is in crisis, you can give them a five page document, but they might not read or understand it.
Harrell: Now, more than ever, do whatever you can to understand your users’ needs. And serve them well.
This story is part of the Pandemic Technology Project, supported by The Rockefeller Foundation.