WTF?: What's the Future and Why It's Up to Us

7

GOVERNMENT AS A PLATFORM

MY FASCINATION WITH THE INTERSECTION OF GOVERNMENT and technology began with my friend Carl Malamud, a longtime advocate for technology in the public interest. In 1993, early in the history of the World Wide Web, Carl was helping Sun Microsystems give a demonstration of the capabilities of the Internet to the House Subcommittee on Telecommunications and Finance. After the demonstration, Subcommittee Chairman Representative Edward J. Markey (now a US senator from Massachusetts) told Carl that his subcommittee also had oversight of the Securities and Exchange Commission. Jamie Love, who worked with Ralph Nader on Internet matters, had been sending petitions to the subcommittee asking why SEC filings weren’t available online.

The initial reaction from the SEC, Representative Markey told Carl, was that the data wasn’t on the Internet because making it available was technically impossible, and, as Carl wrote in his colorful history of the event, “even if the data were available the only people interested in SEC filings were Wall Street Fatcats and they didn’t really need subsidized access to data they were willing to pay for.”

“If something is technically impossible, I get interested,” Carl wrote. So he met with the SEC and with Chairman Markey’s staff. The SEC wanted to know why in the world people would want to see the data in EDGAR (the database of the quarterly and annual filings of US public corporations). “I maintained that the Internet was full of lots of people—students, journalists, senior citizen investors—who were dying for access to this data. The SEC felt that only a few people would want to see EDGAR documents, and besides, the Internet ‘didn’t have the right kind of people.’”

Carl continued, “Now, this was a cheap shot, and I understood that what they meant was ‘there weren’t a lot of people, just a few researchers,’ but I couldn’t resist. ‘The right kind of people?’ I said, rising up in my chair. ‘I think the American people are the right kind of people.’”

And so the government open data movement was born.

Carl secured a small National Science Foundation grant, which he largely used to pay the licensing fee that the SEC’s “value-added resellers” charged to provide its data to Wall Street banks. Eric Schmidt, then CTO at Sun Microsystems, donated a couple of servers. Carl and his co-conspirator Brad Burdick formatted the data, put up the website, and in January 1994 launched a free version of the SEC’s EDGAR system on the Internet.

Carl was an activist, not an entrepreneur. “Our goal wasn’t to be in the database business,” he wrote. “Our goal was to have the SEC serve their own data on the Internet.” So, after operating the system for eighteen months, Carl announced that the service would be shutting down in sixty days unless the SEC took it over. Fifteen thousand people wrote to the SEC, proving Carl’s point. Minds were changed, and the SEC agreed to take over the site.

Over time, with public demand for company financial statements no longer subject to debate, entrepreneurs started to build improved versions. Services like Yahoo! Finance and Google Finance, which provide public access to the data from SEC filings, are direct descendants of the work that Carl did in 1993. He has continued his activism ever since. His current challenge is to make the full text of all laws, regulations, and standards incorporated into law by reference freely available on the Internet.

My interest in lessons from Silicon Valley for government came back to the fore in 2005. Amazon hadn’t yet revolutionized the industry by launching its cloud services platform, but the value of the Internet as a platform, and the nature of that platform, was becoming clearer to me. I had become convinced that the next generation Internet platform was a data platform, and I had noticed that government was the source of much of that data. The work that Carl Malamud had kicked off a decade earlier was just the tip of the iceberg. Google Maps, whose interactive JavaScript (“Ajax”) interface was one of the WTF? technologies of 2005, was, like all online mapping services, built using base maps licensed from the government. And when hackers realized that they could build “mashups” placing other data on Google Maps, government data was one of the first places they turned. Adrian Holovaty’s chicagocrime.org (now EveryBlock), which put crime data from the city of Chicago onto a Google map, was the second mashup ever created.

Google Maps fit perfectly with my thinking about Web 2.0. Unlike operating systems like Windows and Mac OS X or Linux, whose subsystems manage access to the hardware subsystems of a computer or a network, I was convinced that the Internet operating system would manage access to data subsystems providing services like confirming someone’s identity or determining their location. If these subsystems could be made easily accessible to developers, I was convinced that an explosion of innovation would happen. I was so convinced of this thesis that I had launched a new event on location-based services, called Where 2.0. In a perfect demonstration of “catching a wave” at just the right time, Google contacted me two or three weeks before the event to ask if I could fit them into the program. Google Maps hadn’t yet been announced, and it arrived just in time for its public launch to become a centerpiece of the event.

While applications could technically be built on top of other online mapping services like MapQuest, Yahoo Maps, and Microsoft Maps, developers had to apply for permission and pay an up-front licensing fee. My experience with open source software had taught me that there would be far more innovation and usage in the emerging mapping services landscape if those barriers to entry were taken down so the creativity of developers could be unleashed. So I called Microsoft and MapQuest (by then owned by AOL) to try to persuade them to make their APIs freely available, but without success. Instead they shut down hackers as “pirates.”

But Google got it. When an independent developer named Paul Rademacher deciphered the Google Maps data format, he realized that he could build new custom maps by combining data from multiple sources. He built a site called housingmaps.com that showed apartment listings from Craigslist on a Google map—and Google saw the opportunity. Instead of shutting down Paul’s hack, they celebrated it. They hired him, and opened up an API to make mashups easier. This was a transformative breakthrough that led to Google’s dominance in online mapping. As more and more developers built applications for Google Maps, the platform got more powerful and drew more users. It became the classic thick marketplace, where users came for the apps, and apps came for the users.

The same design pattern, by which hackers had taught a company about the power of platforms, happened when Apple introduced the iPhone in June 2007. The App Store is so central to our experience of the smartphone today that it’s easy to forget that the first iPhone didn’t have an app store. It had a revolutionary, beautiful multi-touch interface and included iTunes, the music player that powered the iPod, but like most other phones, it had a limited number of apps. Within days, though, hackers had found their way around Apple’s restrictions and had added apps of their own, a process that became known as “jailbreaking” (getting your phone out of application jail). In July 2008, in response to the spread of jailbreaking, Apple introduced the App Store as a formal mechanism for developers to add applications to the phone, and the smartphone world as we know it today took off. By the latest estimates, there are more than 2 million apps for the iPhone and they have been downloaded 130 billion times. App developers have earned nearly $50 billion in revenue.

A NEW MAP FOR GOV 2.0

The iPhone App Store was launched in July 2008; in November of that year Barack Obama was elected president and widely celebrated as “the first Internet president” because of the way he’d successfully used the Internet during his campaign. I was brainstorming with Eric Faurot, whose company, TechWeb, coproduced the Web 2.0 Summit with O’Reilly Media and John Battelle. I thought we should try to attract government innovators to our events to explore how the new administration could live up to the expectations of the first Internet presidency; Eric suggested instead that we bring a special version of the event to them. So that’s what we did, coproducing the Gov 2.0 Summit and Gov 2.0 Expo in Washington, DC, in 2009 and 2010. Jennifer Pahlka, who is now my wife, became TechWeb’s general manager for the project, and a crucial thought partner.

As I began developing the content for the new Gov 2.0 Summit, one of my first visits was with Eric Schmidt, then Google’s CEO, whom I’d known since the days that we both worked with Carl Malamud back in 1993. I knew Eric had spent a lot of time in Washington, and I thought he’d have good advice. He did, but it wasn’t the specific set of recommendations I expected. “Go to DC,” he said. “Talk to a lot of people, and tell us what you make of it. You’re good at it. That’s what you do.”

The idea that we should make “government as a platform” the centerpiece of our new event came to me in a conversation with Frank DiGiammarino, then a vice president at the National Academy of Public Administration and later a special assistant to Vice President Joe Biden involved in the administration of the 2009 Recovery Act. Frank explained to me that he believed one of the key roles of government was as a convener; once the government identified a problem, it shouldn’t try to solve it directly, but should instead bring together the parties it wanted to engage with this problem. Frank contrasted this idea with the old model of government, which NAPA fellow Donald Kettl had named “vending machine government.” While I didn’t use the metaphor in quite the same way as Kettl, I ran with it: We pay our taxes; we get back services. In the vending-machine model, the full menu of available services is determined beforehand. A small number of providers have the ability to get their products into the machine, and as a result, the choices are limited and the prices are high. And when we don’t get what we expect, our “participation” is limited to protest—essentially, shaking the vending machine.

This image of traditional government as a vending machine was the missing piece that helped make sense of everything I was exploring. A “Gov 2.0” meme had started to take hold in DC circles, but it was largely associated with getting federal agencies on social media, and social media was understood mainly as a way for politicians to get their messages out, and for citizens, another way to shake the vending machine. But to me, there was a far more profound opportunity, for government to run the Google Maps and iPhone App Store play.

We set out to redefine Gov 2.0 and draw a new map of how technology could reinvent government to be closer to the vision of our nation’s founders, a model in which, as Thomas Jefferson wrote in a letter to Joseph Cabell, “every man feels that he is a participator in the government of affairs, not merely at an election one day in the year, but every day.” In this model, government is ultimately a vehicle for coordinating the collective action of citizens. Jefferson was talking about governance—the creation of the rules by which we guide our society—but his participatory principle resonates with the ideas of open source software, and for that matter, of any successful platform.

To be clear, government as a platform most emphatically doesn’t mean outsourcing government programs to the private sector. It does mean strategically identifying what building blocks are essential for government to provide, and providing those services, but not so many that they crowd out opportunity for the marketplace participants.

I had read a remarkable paper called “Government Data and the Invisible Hand,” published in the January 2009 issue of the Yale Journal of Law & Technology by David Robinson, Harlan Yu, William P. Zeller, and Edward W. Felten. The paper argues that the government should get out of the business of building websites for citizens. If that call sounds familiar, you’ve probably heard it in the context of critics charging that government is not competent at building technology and would be much better off outsourcing everything to government contractors. But that’s not what these authors meant. Robinson and company instead wanted the government to provide free access to bulk data so that anyone who wanted to could use it to build multiple competing services, possibly supported by a variety of business models. That’s the difference between the vending machine and the platform.

This idea also echoes one of the “Eight Principles of Open Government Data” that Carl Malamud, Harvard law professor Larry Lessig, and I, together with a group of about thirty other open data activists, had published after a working group meeting in December 2007. One of those principles is that data should be published in formats that are not just machine readable but machine processable, so that the data could be reused for purposes not envisioned by its original producers.

Open data had become a key talking point of the new administration, but most people only thought of it as a tool of government transparency and accountability. A handful saw that there was a real opportunity to make data much more useful to citizens and society. They were drawing a new map, one I thought could navigate us to a better government. I saw a chance to reframe the dialog between liberals and conservatives that has so dominated political discourse in recent decades. Big government versus small government is in many ways beside the point. If government is successful as a platform, you could have small government and big services, just like Apple does with the iPhone. Apple didn’t build thousands of its own apps. Apple built a platform and a marketplace, and hundreds of thousands of developers piled on.

I brought Craig Mundie, then CTO at Microsoft, to the Gov 2.0 Summit, where he pushed forcefully for the idea that killer apps drive platform adoption, using the example of how Microsoft Office had been key to the success of Windows. As it turned out, the federal government already had some killer apps built on the platform of government data; we just weren’t calling them that. By 2008, GPS devices were in cars providing turn-by-turn directions, phone applications were telling us when the next bus was about to arrive, and services like Foursquare and Yelp were letting us know what restaurants were nearby. Few of the users of those services realize (even today) that GPS started out as a service built by the government. The US Air Force had originally launched GPS satellites for military purposes, but after a crucial policy decision made by President Reagan, agreed to open up the system for commercial use, much as Google decided to open up its Maps platform. No longer just an application, GPS became a platform, resulting in a wave of innovation from the private and public sector and a market now worth more than $26 billion.

Gov 2.0 started to mean something much more profound than getting federal agencies on social media. Washington insiders started talking about what we could achieve as a country with government functioning as a platform on which anyone could build.

CENTRAL PARK AND THE APP STORE

It’s easy to forget just how generative government interventions can be. Larry Page and Sergey Brin’s research project at Stanford, which led to Google, was funded by the National Science Foundation’s Digital Library program. Were the NSF an investor rather than a grant maker for the public good, that investment alone would have repaid more than the entire NSF budget for the years the grant was made. In fact, the market value of Google is greater than the entire amount of taxpayer dollars spent on the NSF since it was first founded in 1952.

The Internet itself was originally a government-funded project. So was the Interstate Highway System. Not to mention that the government funded the original computer and memory chip development that gave us Silicon Valley, the research behind Siri and self-driving cars, and actually provided much of the capital for building out Elon Musk’s bold ventures in electric vehicles, rooftop solar, and commercial space travel.

But government as a platform means far more than R&D funding. Would our cities thrive without transportation, water, power, garbage collection, and all the other services we take for granted? Like an operating system providing services for applications, government provides functions that enable private sector activity. We see this particularly at the local level, where government interfaces most directly with citizens.

On a visit to New York City in the fall of 2016, I went for a morning run in Central Park. It was beautiful in the early light, and equally beautiful to see the ways that New Yorkers use their park. Runners and bikers thronged the roads and paths, but there were also people just sitting quietly absorbing the view, taking in the dawn. And of course, there were the dog walkers.

The park is pretty clean—and on that Monday’s run, I came across a crew of maintenance workers who reminded me just why it is so clean. It’s not that New Yorkers look after the park. It’s that it is looked after for them. This oasis of natural beauty in the center of a great city is set aside and looked after for the benefit of its people. Forty-two million visitors enjoy the park each year.

As I ran through the park, I couldn’t help but think of the park as a metaphor for all that government does for its citizens. Our roads, our trains, our water and sewers, our universal access to electricity, heat, and telecommunications. Our schools. Our protection from fire and flood, from crime and from foreign enemies. Our rule of law. I know that many of these services cost more than they should, and accomplish less than they could. Some are tragically at odds with core American values—I grieve for police violence against people of color, unnecessary foreign wars, a rule of law that too often seems to favor the rich and powerful over the rights of all. Yet I also think of all the ways that government is the platform upon which our economy and our society are built, with many analogies to the way that iOS and the App Store are the platform for the Apple smartphone economy.

In the same way that it puzzled me that advocates for Linux were ignoring the Internet in building their narrative, it has puzzled me that those who celebrate the success of the great Silicon Valley platforms are critical of government for doing things that are understood to be essential when coming from Google, Facebook, Amazon, or Apple. The question shouldn’t be whether or not government ought to be doing these things; it should be how to help government do a better job of fulfilling its responsibilities as a platform.

As we’ve discussed, creating a thick marketplace is the first requirement of any platform. This is not a given. A thick marketplace requires both producers (in Apple’s case, app developers) and consumers. In the smartphone space, Apple and Google were able to build thick marketplaces, but Microsoft, for all its past success, was unable to do so. Not enough people bought their phones, which were late to market, and so app developers were unwilling to build new apps for Windows Mobile, which confirmed customers in their decision to avoid the phone.

What is the equivalent for government? For “thick marketplace,” read “flourishing economy.” We like to think that “the market” is a natural phenomenon, but the fact that there are poor countries with abundant natural resources and large populations and rich countries with neither abundant resources nor large populations teaches us that there is an art to creating a flourishing economy.

Where a technology platform must acquire users, a nation already has a captive set of “users”: its resident population. If the population or resources are small, the country must reach outside its borders for both, but in many cases, this local population is sufficient to bootstrap a robust marketplace, with plenty of consumers and plenty of providers of goods and services.

But there’s an important lesson from the wealth of nations: If the population doesn’t have enough money to buy goods and services on offer either from its own sellers or from those trading from other countries, the country remains poor. The marketplace is out of balance. This is the situation in much of the world economy today, where growth is slow, because wealth has become concentrated in too few hands and there aren’t enough buyers for all the goods and services that might otherwise be on offer. Let this go on long enough, and the entire marketplace withers. Producers of goods and services move on to other marketplaces. Nations rise and fall in wealth, just like technology platforms.

Getting a robust marketplace off the ground and keeping it often requires strong government intervention. In his book Bad Samaritans, Korean economist Ha-Joon Chang describes how South Korea used central planning and targeted investment in specific industries to build a highly successful economy. “Korea, one of the poorest places in the world, was the sorry country I was born into on October 7, 1963,” he writes. “Today, I am a citizen of one of the wealthier, if not wealthiest, countries in the world. . . . The material progress I have seen in my 40-odd years is as though I had started life as a British pensioner born when George III was on the throne.” This transformation was due in large part to forceful government management of the Korean economy, protecting its young industries and designing a deliberate ladder by which the country would focus on successively higher-value products. Recent work makes the same point about the early United States. In Concrete Economics, Stephen Cohen and Brad DeLong review the lessons of history, going back to Alexander Hamilton and identifying the role of government intervention in each great step forward in the American economy.

The rules of a technology platform can be loose, as they are with Google’s Android app ecosystem, or tight, like the iPhone’s more tightly managed platform. This is as true for nations as it is for smartphones. There’s more than one way to succeed in creating a successful platform.

GOVERNING PLATFORMS, PLATFORMS FOR GOVERNING

Technology platforms and government have much to learn from each other.

Government and tech platforms must each provide core services that the “apps” or other services rely on. Despite the prevailing belief that the United States economy is largely a “free market,” none of it works without fundamental infrastructure. In the 1930s, the Tennessee Valley Authority and the Rural Electrification Administration built dams and power distribution systems and established the idea that access to electricity was a fundamental right of every citizen. Telecommunications followed the same pattern, with a commitment to universal service enforced by the Federal Communications Commission. And of course, our national highway system, created in the 1950s, enabled interstate commerce and accelerated the growth of our economy. These are among the fundamental platform services of our country, just as the functions of access to the underlying processor, memory, sensors, and capabilities of the phone are platform services of the iPhone, and payment, distribution, security, discovery, and so forth are fundamental platform services of the App Store.

Each must also create and enforce a rule of law as part of those core services. If Google had let companies providing low-quality information dominate search results, people would have moved to Microsoft Bing or some other search engine, so Google has invested enormous resources in clarifying acceptable behavior and punishing bad actors. If the App Store lets you download an app that steals your personal information or your money, you will think twice before downloading another app, so Apple too has a robust security, quality assurance, and monitoring infrastructure to keep that from happening. The rule of law in platforms and in government is not just about justice and peace, it enables commerce; people don’t do business where they can’t rely on the rules being enforced.

Each must also invest in innovation to drive opportunity. The multi-touch interface of the iPhone was an innovation that paid off not only for Apple, but for many people who chose to build on or use the platform. In the same way, government investments in breakthrough innovation pay off in unexpected ways. The fundamental technology of digital computing was developed by the military during World War II, then placed into the public domain. IBM then used it to transform itself from a manufacturer of mechanical tabulating machines into the dominating, monopolistic giant of a new era. Similar wartime investments turbocharged the aerospace industry, plastics, and chemicals. During the Cold War, the military developed technologies such as the Internet and GPS satellites that, when opened up to the private sector, led to the digital world we know today.

More recently, initiatives such as the Human Genome Project and the White House BRAIN Initiative are pushing the boundaries of basic research in areas that may well be central to the next technology boom, the next platform, and the next economy once the digital realm we are so fixated on today fades into the background of the everyday, just like previous unicorn technologies.

Each charges for its services. On a private platform like the App Store, developers have accepted that 30% is the tax they have to pay to Apple for all the services it provides to the economy it supports. People also take for granted that platforms like Uber and Lyft take a cut from their drivers, and Amazon a cut from its resellers. So too, in a democratic society, people tax themselves to pursue common goals, to finance the platform upon which society builds. In a closed society, those in power extract rents from those who use the platform. But one way or another, we must pay. The question is how much, and whether we think what we get for what we pay is worth it.

And that’s why, for each, performance matters. If an app, or your phone itself, is slow, unreliable, or hard to use, you look for a better alternative. Over the recent history of the United States, we’ve seen a growing disdain for government and its role in our society. It is characterized as bloated, inefficient, and out of touch. Like any system that has grown by accretion for hundreds of years, our government processes, structure, and regulations are all in serious need of an overhaul. And in the 2016 election, frustration with that bloat contributed to an unprecedented change in direction whose consequences are just beginning to play out.

What the most frustrated citizens of our country likely don’t realize is that the mechanisms for reinventing the platform of our government for the twenty-first century have been quietly emerging.

CODE FOR AMERICA

After the first year of the Gov 2.0 events, Jennifer Pahlka, who was TechWeb’s general manager for our events partnership, became obsessed with an idea. She was spending half her time on our Web 2.0 event, with a front-row seat to the emergence of Facebook, Twitter, and the iPhone, and half her time on our Gov 2.0 event, inspired by the nexus of interest in government as a platform, but also learning for the first time how government builds and buys its software.

As Eric Schmidt had encouraged me to do, we were making the rounds in Washington and talking to a lot of people, and a lot of what we heard were stories of technology project failures, of systems many years (sometimes decades) in the making that either flat-out didn’t work or worked so poorly that users preferred the previous system, even if that meant everything still had to be done on paper. The contrast between the day-to-day practices of these two worlds could not have been more different. The conference was coming together as a meaningful place for dialogue between the two, but Jen wanted to do something about the discrepancy she saw.

We both saw the opportunity for government to improve by applying the basic practices of the consumer tech industry, but Jen also saw the human consequences. Before Jen worked in the tech media business, she had taken a job out of college working in a child welfare agency. She could draw a straight line from the failures of these technology projects to the children in the care of the state and the social workers and administrators charged with keeping them safe, whose software and systems worked so poorly. Too often, the systems made it harder, not easier, to take care of these vulnerable children.

Jen resigned from TechWeb in late 2009 and, funded by credit card debt and small planning grants from the Sunlight Foundation and the Abrons Foundation, started Code for America, a nonprofit that aimed to bring government’s technology competence up to par with that of the consumer tech world. She decided to start with cities, inspired by her friend Andrew Greenhill, the chief of staff for the mayor of Tucson, who pointed out that local government presented not only less red tape, but also more opportunity to touch the public. The cities that Code for America selected through a competitive application process would each get a team of programmers, designers, and others recruited from the consumer tech industry to do a year of service building apps.

Jen asked me to join the board of directors, and I enthusiastically agreed. Others turned out to be enthusiastic as well: 525 tech industry professionals applied to the program; we selected just twenty of them to work with four cities: Boston, Philadelphia, Seattle, and Washington, DC. The fellowship formally launched in January 2011 with a month of training, with the fellows going to their cities in February for onboarding.

Over the next few years, we helped local governments create a series of apps that, as first-year fellow and former Apple designer Scott Silverman said, were “simple, beautiful, and easy to use.” A school choice website in Boston; a system for tracking blighted properties in New Orleans; a crowdsourcing app for clearing snow from fire hydrants that, being open source, spread to numerous other cities and was used for other forms of citizen participation, such as clearing storm drains and, in Honolulu, reporting back on whether the tsunami sirens were operational. In Santa Cruz, the fellows built a portal for easier small business permitting; another group of fellows, working in their spare time, built an easy way to model new public transit routes for any city.

The speed with which the fellows could build and stand up new applications shocked city staff. The first version of the Boston school choice site was built in about six weeks. City IT staff later marveled that if they had gone through a normal procurement process, the site would have cost them $2 million and taken two years. Allen Square, the CIO of New Orleans, made similar comments about the blight tracking tool.

More important, the fellows’ work showed that it is possible to improve the performance of the platform of government. It’s not just that these apps cost less and are developed faster, it’s that they work for their users. In the case of the Boston school assignment app, the status quo was a twenty-eight-page brochure printed in eight-point type. It contained a lot of information, but like many government publications, it could not address any individual situation because each required calculating the distance from a child’s address to the possible schools, so it effectively couldn’t do the job its users needed it to do. The frustration parents felt trying to navigate the school selection process without these tools had led to a yearlong series of articles in the Boston Globe that followed the struggles of families trying to navigate the maze. The school choice app was a win not just for Boston families but for embattled politicians.

Building an app using consumer technology talent and user-centered practices (and without going through government procurement channels) was a powerful way to show that our government doesn’t have to be bloated, inefficient, and out of touch. Instead of bemoaning the inevitable state of government, Code for America promised everyone (not just our government partners and the programmers and designers who raise their hands) that government could work as the public expected it to. Our theory of change was that the apps would be taken over by the local governments we built them for, and that, being open source, they could be spread by volunteers, organized in a chapter organization called the Code for America Brigade. Unlike Teach For America, which scaled by recruiting tens of thousands of volunteer teachers, our goal was primarily to scale through code, like other open source and Internet applications.

The 2012 fellowship opened up new possibilities for impact. That year, four of the fellowship teams decided that they wanted to base a startup on the project that they’d developed. Following their year of service, the teams continued to develop their projects and sell them to other cities.

Ron Bouganim, a successful venture investor, volunteered to run an incubator and an accelerator for civic startups. After two years of that, he raised a venture fund, the Govtech Fund, specifically to invest in companies that bring twenty-first-century best practices to government technology. A number of the startups spun up by Code for America fellows have been acquired; others have received significant venture funding. Remix, the app that was started as a way for citizens to reimagine transit routes in their city, developed into a powerful tool for urban planners and was funded by top VCs who gave it a valuation of $40 million.

The vision of how government could become a platform by emulating the Apple App Store was off to a good start.

APPS TO OPS

In 2013, though, the Code for America project with the city and county of San Francisco opened our eyes to an even more transformative opportunity. San Francisco asked us to work on the Supplemental Nutrition Assistance Program, or SNAP, more commonly referred to as food stamps. This is a federal program that, like many entitlement programs, is administered locally by states and counties. The problem that the Human Services Agency of San Francisco brought to Code for America was this: People were signing up for SNAP benefits, but then, a few months into the program, they were falling off the rolls, and then having to reapply.

This wasn’t a problem that could be fixed with an app. The fellows were being asked to “debug” the operations of a government program. They asked if they could apply for food stamps (but not use the benefits), and began to work their way through the process as its normal applicants did, experiencing the process from the outside in.

The fellows tumbled into a world familiar to readers of Joseph Heller’s Catch-22, or viewers of Terry Gilliam’s Brazil. Letters arrived in the mail written in incomprehensible legal language, language that even agency employees couldn’t understand, let alone the intended recipients, for some of whom English might be a second language. Some of them might not even receive the letter, having no fixed address. Sometimes the letters were in another language—one English speaker received his letter in Chinese. Some of the letters setting an appointment for a follow-up interview, they discovered, were sent out after the date of the interview. Files requested during the application process were thrown away while the applicant was told they had been successfully filed, but at the agency it appeared that they had never been submitted.

The fellows were so energized by the project that one of them, Jake Solomon, didn’t want to quit when the year was up. He was joined by two other fellows who’d worked on projects in other cities, Alan Williams and Dave Guarino. They continued to work unpaid until the organization was able to raise funding to formally continue the project. Alan slept on Jake’s couch and went on food stamps himself, this time for real.

They discovered that the online application to the program was itself a stumbling block. Fifty screens long and taking forty-five minutes to complete even with the aid of a social worker, asking many questions that were irrelevant to a specific applicant, it was impossible to use on a mobile phone, even though about half of all online searches for the program come from mobile devices. Rather than realizing the possibility that a digital application could create branching sets of questions, the web application simply duplicated all of the questions on comprehensive paper forms.

Mainly as a way to collect data, the team created a user-friendly mobile application, GetCalFresh, that allows applicants to start the application, attach documents, and request an interview in less than eight minutes. This app was the key to their user research, because it allowed them to follow users through the process, keeping in touch with them by text message and, with their permission, tracking some of their data. But the app was also adopted by six other California counties, who found it superior to their existing online benefits application. It is currently being expanded to cover all fifty-eight California counties.

We had three important realizations as a result of this project.

The first was that twenty-first-century apps could only take us so far if they were built on top of a broken twentieth-century government platform. Simply putting a digital front end on a broken bureaucratic system often only makes the problem worse, because the digital system replicates existing processes without rethinking them from the ground up. Before we can build apps that really transform the experience of government for citizens, especially the neediest, we have to improve the underlying operations of government services. Just as the point of Uber ultimately isn’t the experience of the app you use on your phone, but the entire service that gets you seamlessly from point A to point B, the point of food stamps isn’t the online application process, but rather the ability to buy healthy food for your family. Our work on SNAP taught us that in too many government services, so much happens to users after the application that degrades or even prevents the delivery of the actual service.

The second realization was that understanding service delivery is the key to good policy making. In the course of their work, the Code for America teams encountered policies and regulations that seemed relatively innocuous, but that hindered the delivery of services and complicated matters for both the government office and the user. For example, the well-intentioned policy of adding questions to help register food stamps applicants to vote during the application process unintentionally creates confusion (and risk) for applicants who aren’t actually eligible to register to vote. Systems designed to help people in difficult circumstances instead end up imposing enormous burdens on them. Because policy makers so seldom get to see what users experience, they have limited insight into the real-world effects of their policies. But when users’ experiences can be made visible, the same iterative, data-driven practices that the Code for America teams used to create great apps can be used to develop or change policies and regulations to get closer to the intended outcomes.

It turned out that the apps we were building provided another way to improve government performance, by giving us insight into the processes behind them. Every Silicon Valley firm builds two intertwined systems: the application that serves users, and a hidden set of applications that they use to understand what is happening so that they can continuously improve their service. The Code for America team realized that their SNAP application app was a way to acquire users and then follow up with them to track and document their journey through the operations of the service. Once you can see what’s going wrong, you can work with government to fix it. Jen calls this strategy “apps to ops.”

Government can do better; it needs to reinvent itself more deeply, much like Amazon reconceived and rebuilt its e-commerce application into a cloud computing platform on which their own website now runs, along with thousands of other applications, or as Travis Kalanick and Garrett Camp rethought how taxi service could be delivered in the age of ubiquitous smartphones. In some corners, as we will see, government is doing just that.

Our third realization was brilliantly expressed in Jake’s account of the project, a Medium essay titled “People, Not Data”—that empathy, not just technology, is the key to successfully reinventing government services. Design and user experience, not just big data and programming, are essential skills. Most of all, government decision makers have to put themselves in the shoes of those they mean to serve.

This is particularly true of services for those who need the help of government the most. These are the services that well-intentioned lawmakers and their well-heeled donors are least likely to interact with. Noting that much of the reporting about the failure of healthcare.gov mistakenly characterized it as a one-time catastrophe rather than something that is endemic, Ezra Klein writes: “One privilege the insured and well-off have is to excuse the terrible quality of services the government routinely delivers to the poor. Too often, the press ignores—or simply never knows—the pain and trouble of interfacing with government bureaucracies that the poor struggle with daily.”

This realization led Code for America to change its focus to building better services for those who need them most. Code for America teams are now working to facilitate access to job training, to simplify communication for people trying to comply with the terms of their probation, and to make it easier for people with certain low-level, mostly drug-related felonies to remove them from their records so that they aren’t barred from jobs, housing, and other necessities. As of this writing, the state of California, together with philanthropic donors including Reid Hoffman and the Omidyar Network, is funding an ambitious project to help Code for America build scalable digital services that we can take nationwide.

Meanwhile, back in Washington, DC, where our government-as-a-platform story started, the same realizations and transformations have been playing out in the federal government.

THE UNITED STATES DIGITAL SERVICE

While the Code for America fellows team in San Francisco was first exploring the problems with SNAP, Jen and I took a trip to London to visit the United Kingdom’s Government Digital Service. While we were there, Jen got a call from Todd Park, at the time the CTO of the United States and a special assistant to the president. Todd had started a new program called the Presidential Innovation Fellows, loosely modeled on Code for America. He called to ask Jen to help him run the program, as Deputy CTO for Government Innovation.

She at first demurred, citing her commitment to Code for America. But Todd persisted. “Like water on stone,” was how Nick Sinai, her soon-to-be colleague, described it. Eventually she agreed. “I’ll come,” she told Todd, “but only if you’ll let me work on setting up a new unit like the UK GDS.”

The GDS is a special unit, at the time reporting directly to the UK Cabinet Office, the group responsible for the operations of government. It had been set up in 2011 under the leadership of Mike Bracken, the former head of digital for the Guardian. Mike had soon attracted top talent from Britain’s technology and digital media circles, and the GDS had been described by one prominent VC as “the best startup in Europe we can’t invest in.” Their complete redesign of the UK government’s web strategy, replacing thousands of conflicting websites with one simple, user-centered hub, had won design awards that normally went to cutting-edge tech companies and had saved the UK government 60 million pounds. That turned out to be just a start.

One of the first things that struck Jen and me as we entered the GDS office on an upper floor of an old office building high above a busy London street was a large sheet of butcher paper covering the picture window in the lobby. In the paper was a small cutout through which you could see the people on the street below. The cutout had a large arrow pointing to it, labeled “Users,” reminding everyone when they walked in just whom the unit was meant to serve.

The GDS had captured this reminder in the first of its ten GDS Design Principles, which have since become a kind of bible of digital government, spelling out the key rules for designing great digital services. (These rules apply equally well to commercial services.) The first principle reads as follows:

Start with needs—user needs not government needs. The design process must start with identifying and thinking about real user needs. We should design around those—not around the way the “official process” is at the moment. We must understand those needs thoroughly—interrogating data, not just making assumptions—and we should remember that what users ask for is not always what they need.

The second principle is also music to my ears, influenced by my own writing and speaking on Gov 2.0. It reads:

Do less. Government should only do what only government can do. If we’ve found a way of doing something that works, we should make it reusable and shareable instead of reinventing the wheel every time. This means building platforms and registers others can build upon, providing resources (like APIs) that others can use, and linking to the work of others. We should concentrate on the irreducible core.

The other principles also echo so much that we had learned from technology: Design with data; Do the hard work to make it simple; Iterate. Then iterate again; Build digital services, not websites; Make things open.

The Code for America board granted Jen a one-year leave of absence, and she joined Todd at the White House in June 2013. I traveled with Jen to DC and watched as she worked through the obstacles to setting up the new service, including where it would be housed, and wrote a guiding document called The Digital Services Playbook with Haley Van Dyck, Charles Worthington, Nick Sinai, Ryan Panchadsaram, Casey Burns, and others. She and her colleagues and allies decided to call it the United States Digital Service, in homage to the GDS, and lobbied tirelessly for its creation.

The vision that Jen and others were championing was gaining some traction, but still far from a sure thing, when in October 2013, healthcare.gov launched . . . and fizzled. Suddenly improving government technology was not a theoretical exercise but a national emergency. The Obama administration’s signature policy initiative was about to go down in flames because of the inability of the government to build a working website to process the applications.

A year and a half earlier, Tom Steinberg of UK nonprofit mySociety had offered a stark warning that now seemed eerily prescient: “[Y]ou [can] no longer run a country properly if the elites don’t understand technology in the same way they grasp economics or ideology or propaganda. . . . What good governance and the good society look like is now inextricably linked to an understanding of the digital.”

Certainly, the healthcare.gov crisis provided the urgency and justification for the USDS. It also provided its initial staffing and leadership. Todd Park had recruited two teams of talented technologists, primarily from Silicon Valley—one to patch together the dysfunctional website that had earned the administration such a black eye, and the second to build a much simpler version of the site using the best practices of a startup team rather than the antiquated technology procurement processes that had led to the disastrous first site. When the USDS was finally constituted in August 2014, Mikey Dickerson, the former Google Site Reliability Engineer (SRE) who had played a key role in the healthcare.gov rescue, became its first administrator.

It’s significant that the first leader of the USDS was an SRE. The unit already had in its DNA a deep commitment to user-centered service design, through its initial inspiration by the UK’s Government Digital Service and the Code for America team working on food stamps in California. But Site Reliability Engineering is at its core the practice of “debugging” the disconnect between software development and operations and building new connective tissue, and that is exactly what the federal government needed.

In its first two years, the USDS engaged hands-on with high-priority projects at federal agencies, including streamlining disability claim processing at the Department of Veterans Affairs, improving the visa processing system at the State Department, working with the Department of Education to help students make more informed college choices, and identifying security vulnerabilities in Department of Defense websites. In addition, it is working on modernizing procurement processes for digital services, and expanding the use of common platforms and tools. The USDS also now has branches at seven cabinet-level agencies—teams that operate using the USDS playbook, but who work directly within and for the agencies.

With all that the USDS has done to prove that government can be competent—even great—at technology, in the end the most valuable lesson we learn from this experiment with the US federal government is the same one we learn with local government and with national government in the United Kingdom. To succeed, platforms can’t just offer apps, or services. They have to effectively set and adjust the rules that govern the behavior of the platform participants.

We also learned that the practices that make good apps turn out to be very relevant for making good rules as well.

Take, for example, the regulations derived from a law called MACRA (the Medicare Access and CHIP Reauthorization Act of 2015). After the near-death experience of healthcare.gov, it was not surprising that the MACRA team wanted the Department of Health and Human Services’ Digital Service team to build the website that would implement this law, designed to allow Medicare to pay more for better care. But by now, leaders in the White House and beyond had learned an important lesson: As Cecilia Muñoz, head of the Domestic Policy Council under President Obama, said at a White House event on December 16, 2016, “Don’t wait till you’re building your website to invite the tech people to the table.” When the MACRA team approached Mina Hsiang, the head of the HHS Digital Service, about the project, Mina proposed something a little different.

What usually happens is that before regulators engage a tech team around a website for users (in this case, doctors and other providers of medical care), they spend many months of study and research, producing a specification describing in great detail the rules the web application will encode. Mina proposed that the team writing the regulations give them an early draft in about a fifth of the time it would normally take them, and let her team do an early version of the website based on that draft.

It’s normal practice for a tech team to test a site with users early in the development process; what was different this time was that the regulators could also see how users experienced and interpreted the rules they’d written, and change their language based on user behavior. They could then test the new language in a subsequent (still draft) version of the site, as the tech team put out new versions of the website to their test users. They did this four more times before the regulators called the rules final.

The MACRA regulators gushed that they’d just written the best rules of their career, having benefited for the first time from real-world feedback during the process.

At both Code for America and the USDS, we have learned one last lesson: As everyone in Silicon Valley’s fierce contest for the best people knows, talent is essential. Mikey Dickerson put it bluntly in a call to technologists to consider public service at the 2016 South by Southwest (SXSW) conference in Austin. “Some of you, not all of you, are working right now on another app for people to share pictures of food or a social network for dogs. I am here to tell you that your country has a better use for your talents.” He listed a set of urgent problems the government needs help with, and concluded, “All of these are design and information-processing problems, and all of these are matters of life or death to millions of citizens and all of them are things you can fix if you choose to.”

Choose. We hear that word again. The future depends on what we choose.

There are indications as I write that the work of the USDS will continue under the Trump administration. Better government is a nonpartisan issue. That being said, there are troubling signs of a different choice. The Trump administration has reversed many of the open data policies of the Obama administration, and has generally favored ideology over evidence. In its quest to “deconstruct the administrative state,” it is taking a wrecking ball to bureaucracy, but it isn’t clear what it will be replaced with. Without proactive leadership, it is likely to be replaced with more of the same.

We have an opportunity to reinvent government. We must not let the opportunity slip by.

Clay Johnson, one of the cofounders of election technology firm Blue State Digital, later the head of Sunlight Labs at the Sunlight Foundation, a government transparency organization, and after that a White House Presidential Innovation Fellow, likes to point out that Moore’s Law has an alarming consequence for government. If government’s slow, change-resistant technology procurement processes mean that it is five or six years behind the private sector, the three or four exponential generations of Moore’s Law that have passed will make its capabilities ten times worse.

And in classic “news from the future” style, that’s exactly what we see. Amazon can deliver packages within hours of your order; Google can tell you in near-real time that there’s an accident up ahead and to take a different route. Yet the VA takes eighteen months just to determine whether discharged soldiers are eligible for benefits.

Governments around the world, and in the United States at the federal, state, and local level, nonprofits like Code for America, venture funds such as the Govtech Fund and Ekistic Ventures, and an increasing number of commercial companies are working to bring the best practices of technology to government, closing the gap between what is and what could be. The flip side of every problem is an opportunity.

Abraham Lincoln said it well: “The legitimate object of government is to do for the people what needs to be done, but which they cannot, by individual effort, do at all, or do so well, for themselves.”

While it’s popular in Silicon Valley, which often leans libertarian, to deride the intrusive role of government, reinventing government to bring it up to date with the rest of society is one of the grand challenges of the twenty-first century.