Power to the Public

The Promise of Public Interest Technology

Tara Dawson McGuinness, Hana Schank

• Publisher: Princeton University Press
• Year: 2021
• ISBN:
  9780691216638
• Topic: Politique et relations internationales
• Subtopic: Politique publique

"Worth a read for anyone who cares about making change happen."—Barack Obama A powerful new blueprint for how governments and nonprofits can harness the power of digital technology to help solve the most serious problems of the twenty-first century As the speed and complexity of the world increases, governments and nonprofit organizations need new ways to effectively tackle the critical challenges of our time—from pandemics and global warming to social media warfare. In Power to the Public, Tara Dawson McGuinness and Hana Schank describe a revolutionary new approach—public interest technology—that has the potential to transform the way governments and nonprofits around the world solve problems. Through inspiring stories about successful projects ranging from a texting service for teenagers in crisis to a streamlined foster care system, the authors show how public interest technology can make the delivery of services to the public more effective and efficient.At its heart, public interest technology means putting users at the center of the policymaking process, using data and metrics in a smart way, and running small experiments and pilot programs before scaling up. And while this approach may well involve the innovative use of digital technology, technology alone is no panacea—and some of the best solutions may even be decidedly low-tech.Clear-eyed yet profoundly optimistic, Power to the Public presents a powerful blueprint for how government and nonprofits can help solve society's most serious problems.

1

The Current State of Problem Solving

IN 2005, THE UNITED STATES Citizenship and Immigration Services (USCIS), the successor to the Immigration and Naturalization Service (INS) and the federal agency responsible for green cards and citizenship applications, began a project to digitize the nation’s immigration system.¹

At that time anyone who wanted to stay in the country for a long period of time, or those who wanted to become American citizens, would fill out a paper form and mail it to USCIS. Those applications would then be packed into boxes, put into the back of a truck, and driven around the country for processing. All forms requiring an interview made their way through the National Processing Center in Kansas City, and then back out to regional processing centers. As they were driven around the country, at each stop the applications grew into hundred- and sometimes thousand-page files, as immigration officers and others added evidence and interview reports and other documentation. There were several computer systems that handled individual tasks such as scheduling interviews with applicants, but for the most part the process of doing anything with USCIS—replacing a lost green card, renewing an expired card, or applying to become a citizen—occurred entirely on paper. USCIS had decided it was time to move over to digital, partially to keep pace with the rest of the world but primarily to speed up the processing time, increase security, and better serve applicants. For context, that same year, Apple rolled out three new iPods, the cities of San Francisco and Philadelphia began offering free citywide WiFi, and Google launched its geographic app, Google Earth.²

Eleven years and $1 billion later, USCIS had managed to digitize two out of ninety-four different types of immigration forms into a system called ELIS (Electronic Immigration System), named in a nod to Ellis Island. The first design of the system—ELIS 1—had begun during the George W. Bush administration, and seven years into development was such a dysfunctional mess that USCIS was forced to scrap it and start again.

The development of gargantuan technical systems often takes much longer than anyone expects and involves multiple types of failure. In 2011, the UK was forced to kill a £4.6 billion system that had been in development for nine years, meant to streamline the National Health System’s record keeping.³ In 2019, after nine years of work and at a cost of $2.2 billion, the Canadian federal payroll system’s migration to a new platform failed so spectacularly that thousands of Canadians went without pay for weeks.⁴

In government, technical failure often doesn’t result in prohibiting the companies responsible from bidding on or landing future contracts. After the failed rollout of a system for public assistance built by Deloitte, the state of Rhode Island renewed the company’s contract.⁵ Of course, big tech failures happen in the private sector too—Boeing’s disastrous development of the 737 Max is a recent, deadly example. But perhaps most crucially, unlike in the public sector, these failures typically don’t put people’s lives at risk (which is what drew so much attention to the Boeing failure). If Instagram goes down for a week, the rent still gets paid (unless you are an influencer who relies on Instagram for your livelihood), dinner still makes its way to the table, food and prescription drugs are still safe to consume, streets continue to be repaired, electricity still reaches your house, and so on.

The challenges ELIS faced only came to President Barack Obama’s attention when the lack of a functional system threatened to interfere with the implementation of his executive actions on immigration. The new policies, which included Deferred Action for Parents of Americans (DAPA)—a policy that would have granted work permits and protection from deportation for illegal immigrants whose children were U.S. citizens or green card holders—meant that USCIS would be processing an additional four million people in a system that at capacity could likely process only seven million a year.⁶ Obviously that was not going to work.

President Obama had already seen what happened when a policy his administration was intent on implementing ran afoul of technology with the launch of the Affordable Care Act (aka Obamacare). That launch had been devastating for government workers and citizens alike, as the site crashed under the user load, and failed time and again as users tried to shop for health insurance plans. Obama was not going to take the same risk this time around, so to ensure that ELIS would be able to handle the additional load, he dispatched a small technical team to take a look at what would need to happen at USCIS as they prepared to launch DAPA. (Welcome to a book full of stories about government, where there will be overabundant use of acronyms.)

Enter an Engineer

When software engineer Brian Lefler arrived at the bland USCIS office building a few blocks from Washington, D.C.’s Union Station, his expectation was that he would be writing code. He’d taken a leave of absence from his job at Google after hearing a pitch on how he could use his skills to help his country by Mikey Dickerson, who had been involved in the Healthcare.gov rescue and was in the process of recruiting people for the United States Digital Service (USDS). That sounded like an interesting opportunity, so he joined USDS, a cadre of experienced designers, engineers, researchers, and product managers embedded throughout the federal government. But after just a few days at USCIS, he discovered that a lack of quality code was not ELIS’s problem.

The office was filled with software engineers who were more than capable of doing technical work. But the engineers were staffed through contracting agencies, so they were not USCIS employees and therefore didn’t have anyone on the government side who could push them on the technical details. The federal career staff at USCIS were used to overseeing a paper-based process, but most were not experienced technologists. Although they were intimately familiar with the business processes and the legal and policy requirements, they lacked the skills and knowledge required to directly manage the development of a complex technical system. Without seasoned technologists on the federal team, questions about how to allocate engineers to tasks, prioritization of those tasks, and how system features should be implemented were inexpertly answered. Contracted engineers who needed these questions answered to move forward found themselves stuck.

Also missing was an incentive structure for contractors that led to speedy, solid development practices. Instead, contractors were beholden to corporate practices that had evolved over years of government bringing in contractors to build systems instead of investing in the capacity to do this in-house. As a result, the vast majority of government projects that require technical expertise are handled by private companies. And many companies, eager to lock these lucrative contracts in place for as long as possible, try to build in naturally recurring needs for their skills.⁷ Because there was no one on the USCIS side who could push back on ELIS from a technical perspective in the project’s early days, the contractor—IBM—had seized an undue amount of control over the design of the system. The contractor had designed ELIS so that it relied heavily on IBM products, even when those products did not benefit the processing speed or help people to use the system.⁸

“ELIS 1 was built to generate software licenses and sustain them in perpetuity, first and foremost. Then secondly to serve the agency’s needs,” observed Lefler. “It didn’t work. ELIS 1 was unquestionably worse than paper, and it was ultimately turned down.”⁹ When ELIS 1 was released, USCIS discovered that it slowed down the processing of immigration forms by a multiple of five.¹⁰ You read that correctly. The digital system took five times as long as paper to move applicants through.

When Lefler and a handful of others recruited by Dickerson’s pitch sat down at USCIS, ELIS 1 had already been scrapped, and work on ELIS 2 had begun. This was in large part thanks to the arrival of Mark Schwartz, who had been hired in 2012 into the chief information officer (CIO) role at USCIS from the private sector.

“I was looking around for what might be the next thing. At some point I was reading an article about how screwed up government IT was, and being the arrogant person that I am I thought, Well, I’ll just go fix it,” Schwartz remembers.¹¹

Schwartz recognized the problem with IBM’s efforts to build ELIS as “what usually happens with a monolithic waterfall project” and worked to extricate USCIS from the contract. “Waterfall” is an older methodology for building technology products, in which teams might spend years building a massive system and then release the whole thing with the flick of a switch, or what is referred to as “big bang.” Schwartz was experienced with a methodology known as “agile,” which has largely replaced waterfall as the go-to process for building technology. Agile allows teams to rapidly research, build, and test small portions of a system, adding on as they go, so that products can be released and improved upon quickly, rather than engineers spending years building one ginormous system. In line with modern thinking, Schwartz had begun to shift USCIS into an agile process. But moving an organization into a methodology that was largely new to them, on a project that they had been engaged in for years, was a bit like trying to turn a battleship loaded with elephants.

A lack of support from qualified staff made it especially difficult to change much of anything, says Eric Hysen, a product manager on the USDS team. “There was finally a realization that the old way wasn’t working, and there were some champions, but they didn’t have anyone to support them,” he explains. “You had Mark [Schwartz] shouting words like agile and cloud and dev ops, and his staff were struggling to figure out what those meant and trying to adapt contracts accordingly.”¹² It’s not that USCIS staff didn’t want to support the project, but they didn’t know how. They were missing the context and skills needed to undertake a successful project using a methodology that was foreign to them.

Not only were the USCIS staff and contractors scrambling to adjust to a new way of doing work, but the federal government itself continued to evaluate the project’s progress as though it were using a traditional approach rather than trying something new. The evaluations didn’t go very well. The reports from the Office of the Inspector General (an independent oversight body housed in each federal agency that ensures that agency work is efficient, effective, and lawful) on ELIS grew increasingly alarmist and combative as time passed and no massive system was launched. The reports dismissed the switch to agile, and continued to question why the entire system wasn’t being built in one mammoth effort.¹³

“It was like peeling back the layers of a hundred-layer onion, where every time there’s something that cements doing things in a way that was so out of date I’d heard about it in college, learning about the old days of computing,” Hysen said. “These were not even things that I did earlier in my career.”¹⁴

The shift from waterfall to agile was as monumental and confusing as if the office had been using pneumatic tubes to send communications, and someone had walked into the building with e-mail.

Digital Is Not Always Better

Part of ELIS’s problem was that the development timeline had stretched so long that the way technology was built shifted over the course of the project. In 2005, while a waterfall approach might have been considered slightly outdated, it wouldn’t have been ludicrous to employ. But by 2014, when Lefler, Hysen, and others joined the team, waterfall was a pneumatic tube. Even more problematic: while ELIS 1 was in large part doomed by the fact that there was no one on staff to help move the team over to agile, ELIS 2 faced an even bigger problem in the agency’s assumption that digital would unquestionably be better than paper.

This was taken as an article of faith, and it turned out to be disastrously wrong.

In some cases, based purely on the task someone was looking to complete, paper was superior to digital. Lefler sounded a bit awestruck as he recounted watching immigration officers work their way through immense case files, searching specifically for aliases that an applicant might have used. Some applicants use multiple names for cultural reasons, so this is an issue that comes up quite a bit, but immigration off...