Why Government Is Failing in the Digital Age and How We Can Do Better

 “Inside government…,” notes Jennifer Pahlka, former U.S. deputy chief technology officer, “the digital revolution played out very differently. Even as our expectations about the immediacy and accuracy of services have skyrocketed, the implementation of laws has become anything but easier. The famous slowness of bureaucracy is a key reason but all too frequently what now widens the gap between policy intentions and actual outcomes is the messy task of implementation through digital technology, and the ways government makes working with that technology uniquely complex.  Recently, Jen Pahlka joined me on The Business of Government Hour (https://bit.ly/3N5GaBc) to discuss her new book and the many insights she outlines in the book. 

“My use of ‘coding’ in the title is a bit of a bait-and-switch,” acknowledges Pahlka, “I use the term ‘coding’ in the title because I want people to fundamentally recode how we think about government more than the actual typing of lines of code into a computer. I’m trying to make the point that more coders are certainly helpful, but they’re not going to do us all that much good if we don’t have the disciplines of design and product management as core competencies in government.  Here’s an excerpt of our conversation. 

Starting with a Story. I see positive changes happening in government. I also see barriers to those changes scaling. It’s about outlining a different approach to implementation. Maybe it would be helpful to start with a story. In the book, I tell the story about the team at the Centers for Medicare and Medicaid Services (CMS) that picked up the ball after healthcare.gov. The Medicare Access and CHIP Reauthorization Act of 2015 (MACRA) was the next significant law that came down from Congress that impacted CMS. The team wanted to get it right this time.  They had learned an enormous amount from the punches taken over the healthcare.gov launch. 

MACRA was designed to pay doctors more for better quality care.  The impetus behind it was to improve the quality-of-care Medicare patients receive while reducing cost. The doctors were so frustrated, and the only thing that they hated more than the systems they were using was the thought of having to use a new system that might be just as confusing. Here are two instances that illustrate how government can work better: 

The first task should have been simple to tell the doctors about the program and how it works. A doctor could participate as an individual or as part of a group. The various policy teams working on the regulation defined “a group” differently. In fact, there were nine different definitions, and none were simple.  The team charged with the website implementation pushed back acknowledging that to keep doctors engaged requires simplification. In the end, the policy and delivery team decide on two definitions rather than nine. Streamlining the definition of a group reduces the complicated nature of the program and helps doctors better understand the program.

Another example involved assessing whether doctors were exempt from the law. The CMS policy team insisted that all doctors go through the program for the first year then determine if the doctors were under the threshold for eligibility. Going in this direction, although technically accurate, would put a tremendous onus on the doctors. After much negotiation, the delivery team convinced the powers that be to let them exempt doctors based on the prior year’s data. 

Through a bunch of changes and much negotiation, the CMS delivery team developed software that made sense to those who were to use it.  When the site launched: it was on time, under budget, and doctors found it so easy to use. This story illustrates that coding isn’t the main reason why program websites may fail. Sometimes how the law is interpreted can compromise its successful implementation. It is often better to honor the intent of a law so you can implement a program that does what the law intended. 

From Digital Pioneer to Digital Laggard. In the early days of computing, the U.S. government dominated the nascent industry. What other entity had such a need to count, to store information, to process data?  By the mid-60’s the U.S. government purchased over 62% of the output of the entire U.S. computer industry. In fact, the field of user experience design has its roots in the military with the design of new aircraft during WWII. By the mid-20^th century computers became a commodity and by the 21^st century cutting edge computing in the U.S. had become largely the domain of the private sector. In that time, the U.S. government went from being a digital pioneer to a bit of a digital incompetent. 

Two things happened around the same time. The first was that digital technology got caught up in the outsourcing boom. With the passage of various laws (Federal Workforce Restructuring Act) and guidance such as OMB Circular A-76 (which formalized the distinction between functions that are ‘commercial’ and ‘inherently governmental’), the message became: if someone outside the government can do that job and cheaper were giving it to them.  At this time, the digital revolution was taken off with the rise of the internet etc. digital technology was coming of age. It was coming of age at a time in government when technology wasn’t considered inherently governmental work. 

One of the things I want people to take away from this story is that some parts of technology development really are inherently governmental. The government has extensive processes and procedures in procurement of digital work but lacks the requisite digital competencies. Government knows how to acquire technology. What it needs to acquire are capabilities. Treating software as just another commodity overlooks the fact that in some cases this software can be an integral part of the mission critical services an agency provides. 

There is also a tendency I have found operating in government that places policy development over implementation. The mindset derives from this sense that implementation is sort of second-class work and that the important people in government do policy and the people who do the implementation of that policy are less important. Interestingly, in the UK government context, there are the intellectuals who develop the policy and what they call the "mechanicals" who implement the policy as developed. In the U.S, context, Healthcare.gov illustrates the pitfalls when policy development and implementation don’t work together. It’s really time to recognize that policy and implementation cannot be very neatly separated if we want both to work. 

Vendors are very important to the ecosystem. I am in no way saying that we should not outsource, or we shouldn’t have great relationships with our vendors. We do have to reexamine this notion that core competencies in digital don’t belong in government. 

Moving Beyond the Waterfall. Though the term waterfall does relate to a software development approach, for me it is a way of thinking that is much bigger than tech. It is a hierarchical way of developing something that is centered on a top-down cascading approach. In tech terms, it is the notion that delivery teams are to fulfill all requirements, not exercise judgment or make active design choices, and that information flows down, requirements flow down, power flows down, insights flow down. In agile software development, that’s not what happens. The agile method follows more of a circle of build/measure/learn, (allowing one to fail iteratively while also pushing changes frequently).  However, my point is that the opposite of waterfall is more about empowering public servants to make program design choices that result in government that makes sense to people. Clay Shirky said that the waterfall methodology amounts to a pledge by all parties not to learn anything while doing the actual work. I say whether it’s software development, policy, or operations, in government we must always be learning while we do the work. It is where those developing government policy work with and learn together with those doing its implementation. 

The book is filled with stories that further illustrate the distinction I am making between these two approaches. A sure sign of a waterfall organization is how people within it treat data.  In an agile, empowered organization, data is a useful tool for adjusting courses. The people in the organization not only have access to the data and the ability to understand it but have the power to decide what to do based on it. In a waterfall organization, on the other hand, data functions less like a compass and more like an after-the-face evaluation, a grade you get that says how well or poorly you did on something that’s already happened.  For people stuck in a waterfall framework data is not a tool in their hands. It’s something other people use as a stick to beat them with. 

Distinguishing Product Management from Project Management.  Product management is distinct from project management.  In Recoding America, this is an incredibly important distinction. There is value in both disciplines, and both need to work well together. Project management is the art of getting things done. Product management is deciding what to do or not do in the first place. Project managers are hugely important, and good ones are extremely valuable to making government work for people. However, we can collect hundreds of formal requirements and start building software for each of them, but besides generating lots of work have we made any real decisions. This is also how we end up with a 212-question SNAP application or a website that only works on computers in a specific building. 

The art of product management is finding elegant ways to give users what they need. Product management as an official discipline is rare in government, but it’s not just that there’s no job classification for it. In the most extreme cases, it seems like it simply cannot exist here: not only are implementers not empowered to make choices, but those above them don’t seem even willing to consider the option. 

Making Technology that Works. During my tenure at the White House, I wanted to set up the U.S. Digital Service (USDS) inspired by an agency established in the U.K. government.  We were doing sort of these proto-USDS projects. One of them was with the Veterans Administration on the veterans’ benefit management system. I had two folks help me do a discovery sprint over a couple of weeks to figure out what’s going on and identify opportunities for change. On the very first day, we were there with this person who in the book I call Kevin, who was a very high-level person at the VA at the time. He was there to help us understand the challenges that we were supposed to help fix. I kept asking him questions about the system: why certain choices were made over others.  Kevin kept saying those were not his decisions and that we needed to ask the businesspeople. 

Eventually, I asked him why he wasn’t willing to discuss the business choices. He said that he spent his career teaching his team not to have an opinion about business requirements. He said, “if they tell us to build a concrete boat, I’ll build a concrete boat.” I think he meant if you want to give him 6,700 requirements and tell us to take ten years to go build them, he’ll do that, even if, at the end of that, the boat won’t float as it’s so burdened down with complexity and requirements. I should say there are concrete boats in real life that float. I think the metaphor still stands. When I asked him why, he said, because that way, when it fails, it’s not their fault. It was devastating to hear that response. Especially given what veterans are facing today, they need their benefits, and they need unencumbered access to those benefits. 

Digital Literacy and Policymakers. Though it would be great if all members of Congress were digitally literate and well-versed technical matters, I think it’s more important for them to shed waterfall thinking.  They need to have the right people at the table when they’re making decisions and they listen to them. They don’t need tech knowledge. They can just borrow that tech knowledge. Unfortunately, most policymakers don’t invite implementers or technologists to the table when they’re drafting law or policy. They tend to talk to them afterwards when it’s too late to change the law and how it gets implemented. it. Digital literacy is nice, but a more critical change would be to ensure that technologists and implementers are at the table when developing and crafting laws.  

0:00 Opening

0:38 Why Recoding America

4:58 Agile vs. Waterfall Mindsets

7:58  A Call to Federal Service

11:18 Why Federal IT Implementations Fail

15:09 Accessing On-line VA Benefits 

18:24 Getting Policy Implementations Right

19:05 Shedding the Waterfall Mindset