The outdated and sorry state of government technology
PERSPECTIVE | What Hawaii’s false missile alert revealed to us
Essay by Hana Schank and Sara Hudson.
Last weekend, people across Hawaii spent 38 minutes thinking they were going to die because a government worker selected the wrong option on a missile alert interface. Multiple images, including several from the governor’s office , later circulated showing an interface similar to the screen the employee would have been using. They all shared the same quality: outdated, confusing, problematic design.
We don’t know if the system in Hawaii was ancient or simply poorly designed, but we know that no user-experience designer worth her salt would create a giant list of links or a drop-down menu for a lifesaving function. It’s the design equivalent of installing a hand-cranked engine on a Tesla or communicating with Alexa via smoke signals.
The incident in Hawaii exposes a problem far larger than a single confusing screen: Government is not good at buying, building and using technology. So maybe the most shocking part of this story is that mistakes like this don’t happen more frequently.
As former government technologists, we’ve worked as contractors and in civil service at federal and local levels, including buying and building out New Orleans’s emergency response systems. Over the past six months, we’ve also conducted in-depth interviews with people in and around government working to improve its technology and modernize its processes.
Failures across the public sector keep technology outdated, poorly thought-out and hard to use.
Government doesn’t apply — and often doesn’t even know — the best practices that make modern technology excel.
Technologists in the private sector have to ensure that their products are simple, effective and intuitive, or else users will turn to a competitor. But when it comes to government, users don’t have a choice. You can’t go somewhere else to pay your taxes or ask for the pothole on your street to be repaired. Without competitive pressure to deliver better technology, the goal for most federal, state and local entities is simply to get the thing launched by a certain date. No one gets extra points for making it exceed expectations.
Too often, government designs systems like it’s 1998, when PalmPilots were the hot new technology and people still communicated via beeper. Even worse, some government systems actually were designed in 1998 — or earlier — and have been patched continuously since. A 2016 congressional hearing on the oldest systems running at the federal level unearthed a benefit-tracking system used by the Department of Veterans Affairs that dated back 50 years and was written in COBOL, the technological equivalent of Old English. When a system at the State Department crashed in 2015, leaving the United States unable to process visas for 13 days, an inspector general’s audit noted that the system was one of many “functioning well beyond their designed lifespan.”
The potential for disaster is real. A state’s child welfare system could go down. A payroll system could fail (as the federal system in Canada recently did), leaving workers without paychecks for months. A failure within a database used by police, firefighters or paramedics could have immediate and fatal consequences.
Government systems aren’t built this way because of lack of funds, or laziness, or broken promises, or stupidity. Many within government care deeply about the state of its technology. But to improve it, they have to overcome massive, systemic hurdles.
First, speed and size. The public sector buys software and systems the same way it orders battleships. An agency can spend years gathering requirements, after which it gives the contract to one of a handful of companies with the resources to handle such a massive order. Many of these companies have been involved with failed government systems in the past. But because it is so hard to meet the requirements to become a government contractor, few companies qualify, and the usual suspects continue to get new work. Oracle was largely responsible for the humiliating launch of HealthCare.gov in 2013, yet afterward it still received millions of dollars a year in federal contracts.
Because of their enormous scope, these projects often take years to complete.
By the time they launch, the technology is old.
U.S. Citizenship and Immigration Services spent three years gathering requirements for a system that would digitize immigration forms; the system was outdated before anyone even began building it.
After more than 10 years and a cost of more than $1 billion, only three forms have been digitized, the system crawls and often stops working, and many of the civil servants who rely on it say they wish they could go back to paper processing.
The odds are high that the alert system in Hawaii was created using this type of process, because this is how most federal, state and local technology gets built. Decades of budget cuts have reduced the number of government employees across the country, so when an agency needs a large technology project, it has neither the resources nor the expertise to do it in-house. These projects therefore go to contractors. The team working on replacing the State Department’s failed visa processing system, for instance, consists of 135 federal workers and more than 1,000 contractors.
But the companies that land these contracts often aren’t known for modern software development. In 2017, the U.S. government paid Lockheed Martin nearly $7 billion in IT contracts, making it the second-biggest federal technology contractor. The company — best known for building planes and missile systems — doesn’t even list user-facing technology as a line of business on its website. While many of these firms understand how to build such systems, and do so for their private-sector clients, the teams they send to work on government contracts often act like junior varsity. Some of the fault lies with the way government contracts are written, specifying outdated processes or solutions. But many contractors are perfectly happy perpetuating the status quo. Last fall, for instance, Oracle was scorned by the tech community for warning the White House, in response to a request for comments on modernizing government, against standard best practices such as open-source technology and against developing any kind of in-house technical expertise.
Even worse, once a contractor builds a system for one government entity, it often resells it to others. Because there is little work involved in a resale, these companies can charge less, and states take comfort in using the same system that another state does. Which means it’s likely that Hawaii’s alert system is being used in other states.
The second barrier to improving government technology is a lack of expertise. The staffer who procures an emergency alert system one month may be responsible for buying office supplies the next month; he or she is expert in writing contracts, not in technology. Government lacks workers with technical expertise who sit at the intersection of what agencies need and what they buy. As a result, officials who don’t know better can spend absurd sums of money on ludicrous technology. And contractors — who do know better — line up to take advantage: In 2016, the Transportation Security Administration spent $47,000 on an app whose sole purpose was to generate an arrow to point airport travelers left or right in a security line.
Many inside government know that this process is broken, but trying new things means taking huge — and public — risks.
In our interviews with people working to revamp civic technology, we heard time and again that those who try something new and fail aren’t seen as brilliant visionaries. They’re seen as liabilities. We’ve worked on projects where the fear around a new technology was palpable; where leadership worried aloud about how the project would play out in the press or pushed back for fear of a failure that might land them in front of Congress. “It’s tough to innovate in government because you get accused of wasting taxpayer money and get beat up in media,” Brendan Babb, Anchorage’s first chief innovation officer, told us. “But we have to give people the space to have new ideas.”
Some government employees are trying. Innovation and digital-service teams have reshaped procurement in California, New York City and St. Paul, Minn., opening contracts to new competition and soliciting proposals that rely on modern design and development. Hiring teams at every level are starting to bring in specialists who don’t ordinarily populate their boxy office buildings: ethnographers, user researchers, human-centered-design specialists, data scientists. These innovations typically happen because someone at the top — often the mayor — reaches a breaking point, demands change and gives agencies carte blanche to take risks. In other cases, a crisis (as in Hawaii) triggers a reassessment of what’s possible and a commitment to do better.
Some local leaders are taking on small, low-cost, high-impact efforts rather than enormous systems development projects.
Gainesville, Fla., created a Department of Doing that puts license and permit applications under one roof, so a new business owner has to go to only one place to get started. When Syracuse, N.Y., couldn’t afford a system to track infrastructure projects, the city turned to Google Sheets to coordinate across agencies. And at the federal level, the U.S. Digital Service and an agency called 18F are working to improve the new immigration system, developing modern design standards for use across federal agencies and introducing new contractors with experience in modern technology development.
These are small steps toward technologies that put users first and support civil servants working to keep the country running. Technology is the engine of government; it allows people to apply for affordable housing or become citizens or file taxes. Without a rethinking of how the public sector handles it, every state risks a failure far more catastrophic than 38 terrifying minutes.
