Citizen Digital Series: How the US Government Can Do Better in the Digital Age, With Jennifer Pahlka

U.S. government services need to undergo some serious changes so that they can optimally function for Americans. These changes include putting thoughtful design into services and writing policies that are actually implementable. Eric spoke with Jennifer Pahlka, founder of Code for America and deputy chief technology officer under the Obama administration, to learn more about her new book, Recoding America: Why Government Is Failing in the Digital Age and How We Can Do Better. In the book, she breaks down how to modify the U.S. government so that it can successfully serve Americans in the digital age.

Auto-Transcript

Eric Egan: Hi everyone. Welcome to Citizen Digital, an ITIF web series where I speak with experts in the United States and around the world to explore how digital technology can improve citizen and customer experience. My name is Eric Egan. I'm the policy fellow for digital government at ITIF. And with me today is Jen Pahlka, founder and former executive director of Code for America, deputy chief technology officer under the Obama Administration, co-founder of the US Digital Services and among many other things now book author with her new book, Recoding America: Why Government is Failing in the Digital Age and How We Can Do Better, coming out June 13th. Jen, thanks so much for joining.

Jennifer Pahlka: Thanks for having me, Eric. Looking forward to this.

Eric Egan: Yeah, so I mean there's a lot of things I can ask you about just from your book alone, but before I throw some questions at you, maybe you could just share a little bit about yourself, how you came to work in this space and how you got to work on so many important digital initiatives in government.

Jennifer Pahlka: Certainly didn't intend to end up in this space. I worked in child welfare actually my very first year out of college and fell into tech media actually. So it was the event called Web 2.0, which used to be quite a big meme in the tech industry during which we realized that maybe the best application of the principles and values of Web 2.0 would be government, and that's really what inspired me to do Code for America and that was the beginning of my journey, not just working with government but also inside government.

Eric Egan: Oh, really cool. I mean, I'm a policy person who was a math teacher before I got into gov tech, so there's probably more of us than we think.

Jennifer Pahlka: Sure.

Eric Egan: So yeah, this web series is really about customer experience, citizen experience with digital government. So one of my first questions I ask guests is if they can share their own definition of citizen or customer experience with government and the role that you believe digital technology in particular plays in that experience.

Jennifer Pahlka: Yeah, I mean I think citizen experience or customer experience is pretty simple. It's what the person who you hope will use your service experiences. I think the difference that becomes very meaningful is how do you know? If you believe that if people inside your department like using it that it's a great experience, have you tested it with people who are not in the department who don't know what some of these terms mean? And I think really what we should think of as the key of FCX is user research and really disciplined user research and from the beginning of a project, not at the end. All the way from the beginning, before we're actually developing things, all the way through and on an ongoing basis to understand how needs are changing and how we might meet them.

So I think really the question is are you getting outside your building? I do also want to say though that people in government, the people who are going to administer services, who have to process claims, whatever, they are also customers and they need good tools. And then the last thing I'd say I guess is that in sometimes the best customer service, excuse me, customer experience is no customer experience. I tell a story in the book about clearing criminal records where a team of Code for America spent a long time trying to figure out how to streamline a very burdensome multi-step paperwork process. And there are many places where you could have said, oh, let's make this digital, let's make this question clearer. And the reality is that none of that needed to happen at all and throwing it all away and saying, we're just going to change this person's record because what they did is no longer a crime is a fantastic customer experience and it doesn't involve any interaction by the customer at all.

Eric Egan: Yeah, that's a good point. You're already hitting on a few of the questions I have queued up for you, but maybe the next one I'll go with is you spent some time on this in your book, can you speak to the relationship between complicated policy and complicated procedures kind of producing complicated tech and government and the challenge of transforming policy into usable services for citizens and customers or no services to your point? And I'm kind of thinking about the points that you make and some of the examples you share in your book where you talk about the distance between policy intent and implementation.

Jennifer Pahlka: Yeah, I mean I think your audience probably knows this better than most, but the general public has very little understanding of how complex the policy that governs these services can be. I've been doing this for 13 years and I'm still sometimes shocked by it. I remember well when my colleague Marina was telling me about working in the employment development department in California during the pandemic where we were trying to clear a backlog of 1.2 million claims people who had applied for their unemployment four months earlier and weren't getting it. And she was talking to one of the claims processors who kept saying, oh, I'm not sure if I know the answer to your question. I've not been here that long. I'm the new guy. And she finally asked him how long he'd been here and he said, oh, I've only been here for 17 years.

The folks who really know this policy have been here for 25 years or more. And that's not because somebody sat down and decided to make something so complex that it takes 25 years to learn. It's because it accumulated over decades. I mean, in the case of UI, I think these policies go back to the Social Security Act of 1935 or 1939. So that's a really long time to have change upon change sort of accrete and accumulate, which of course is why the technology also has accreted and accumulated in layers rather than being designed to fit the purpose at the moment. I really think that there's an opportunity to help the public understand that as much as we think we may have starved government by design and certainly that isn't sort of ideological viewpoint for many. We have also starved government of design. We have not really designed services, and I think that is the big opportunity for service delivery is just true, thoughtful design and the political will to get that design done.

Eric Egan: Yeah, and I know you mentioned in your book as well, the days are kind of gone where you think about technology being a tool for policy delivery, but that's really, you have to think about delivery and implementation and technology upfront when you design policy. So it's really kind of bringing policy and tech close together. I had a professor, David Eves who you know, who said that he got annoyed by the term digital government because that's not really... Government itself has to be digital, right? So it's this concept of it being separate really has to go away.

Jennifer Pahlka: Yeah. I'll just add to that from... Since I mentioned clearing criminal records without any customer experience at all, one of the things we found out in that is that if you want to automate the expungement of criminal records, you have to have people with technology and design skills at the table when the expungement laws are being written. And that is very counter to the culture of government, which is hierarchical, and the people who do the delivery are at the bottom of a very large waterfall process. So it's just not thought of, it's not done, but when you get them in the room to help write law and policy that is actually implementable by saying, if you write it this way, it will be possible to automate it. If you write it the other way, your magic words of law will have no impact. It's really important that we sort of not just collapse that, but to create a circle. A build, measure, learn cycle where different people are at the table and there's so many opportunities for that far beyond record expungement.

Eric Egan: So you've mentioned user research and design already, and your book often mentions the importance of good product management and service design in developing government technology particularly given the overwhelming focus of project management in federal I.T. Your points about the PMP, kind of the project management practitioners certification were kind of funny to me because that was a world I was kind of caught up in. Can you share why these disciplines, product management, service design, user research are so important?

Jennifer Pahlka: And I think this is probably something that a lot of your listeners can really move the ball forward in terms of educating government partners. I can't tell you the number of times I've talked to people and said, I want to talk to you about product management. And they say, oh, absolutely. It's very important to have good project management. I mean, they don't even hear the difference.

Eric Egan: Yeah, they're too similar sounding.

Jennifer Pahlka: It's fine. I mean it's no knock on them, but let's help them politely and supportively understand that project management is the art of getting things done. It is incredibly important. I love a good project manager more than anything. But product management is the art of deciding what to do in the first place. And the sort of default method of building services in government is find all the requirements, in fact, exhaustively find all the requirements, everything anybody thinks this system needs to do, throw it all in one giant bucket over the course of several years and then task someone with doing all of them in a sort of undifferentiated, unprioritized way. And that's not product management. So it doesn't result in a product that's usable, it results in a big project that people end up being frustrated with. So it's really about saying what is the most important way to meet the need here rather than doing everything everybody thought needed doing?

Product managers have a tough time because they have to essentially say no to people. We're not going to get that in the first version of this product. But they can also say, let me understand what need you're trying to serve here and maybe there's another way to serve it. Or let's launch the project without that now and let's add it in the second phase or find out what users think. There's a lot of different answers that are not actually a no, but can lead to more well-designed, simpler, streamlined services that work better for people.

Eric Egan: Yeah. I think one of your examples from the book, kind of a happy example, people talk about Healthcare.gov all the time and what a debacle it was. I've written about it, but one of the first pieces I wrote when I joined ITIF was focused on how surprisingly good COVIDtest.gov was, and you mentioned that as well. What elements of product management, service design, user research, these kinds of things that you're talking about, what made that so successful?

Jennifer Pahlka: I think it's trade-offs. You can absolutely imagine the conversation in government that would've led to COVIDtests.gov being a far larger project, having way more features, taking a lot longer to build. Think of all the things you could have been in there. They didn't ask for healthcare, they didn't ask for health insurance information. They didn't ask for household size. I mean, there's the long list of things that if you think about it, someone could have said, we need this. And there could have been... There was one data lookup. We were checking against the master address database of the postal service, but we weren't checking to see if you were insured. We weren't checking to see if you were vaccinated.

So there are things that they clearly decided not to do in service of the things that they did very well. The thing scaled, right? There were millions and millions of users on it all at the same time, and it performed really well. It launched in two languages, I believe, and they shipped third language the next day. So accessibility, scalability, reliability, ease of use, delight of customers were the things that they decided to go for. And they were able to explain to the people responsible for this that they could achieve those things if they didn't do these other things. And I think it's a great lesson for those who might have said, oh, but we need X, Y, and Z then to see that in fact we really didn't need X, Y, and Z and the trade-off was worth it, but it can be hard to force those trade-offs.

Eric Egan: Yeah, that's fair. I know we have a lot of kind of doers in our listener group. So I was curious to get your thoughts on... You're kind of hitting on it now with COVIDtests.gov, but in looking at customer facing digital services in government, what's your ideal team look like? So you mentioned agile as well in your book. There are things like scrum masters, there are project managers, there are product owners, there are discovery analysts. It doesn't have to use the specific terms, but what's your ideal team look like when you're building a product?

Jennifer Pahlka: I mean, the main thing is that it's cross-functional and that you have dialogue across those functions. I think it's critical that you have a good internal product leader, and I'm sure many of your listeners have experienced not really being able to get the answers and decisions they needed from their clients because there was a sense that we were outsourcing the whole thing and all of the decisions. And really you do need your government partners to make timely decisions so that you can get those trade-offs and have a usable product. But I think very often we've thought of cross-functional as sort of like we need designers and developers. Well, it's much more cross-functional than that. It's policy, it's the lawyers, it's the compliance folks, it's certainly user researchers. I heard a story recently from James Stewart who works for Public Digital, he used to be part of the government digital service team in the UK about working on universal credit, where before they wrote a line of code, they had the policymakers answer the phones of people who were calling about their needs.

So putting them directly in the role of essentially customer support as a way of doing user research so they could start to see what they were thinking of in terms of a policy would actually play out with real people who needed the service and challenge their assumptions. That's an even more deeply cross-functional team than I think we're doing today. And I think we ought to be heading there where it's not just the user researchers who are responsible for understanding the needs of the user, but they're just sort of a conduit to the whole team for that.

Eric Egan: You mentioned in your book you have several good examples of civil servants, career civil servants who as were saying, people with decades of experience within a single agency who spent their whole careers working for maybe even a particular department or sub agency within those agencies. And all these changes have... I mean, this is something I've experienced when you have agile transformation, you have people coming in with these fancy new kind of terms and approaches to developing software. And personally I knew many agency product owners that were nervous being in such a role or felt that they weren't tech-savvy enough, that they couldn't be empowered.

How important is it to demystify tech for people working in government? I mean particularly as there's a strong argument you made that tech should be simple in government and good and clean and efficient. And I guess one other thing to think about is bringing to your point about cross-functional teams and it not just being a tester and a developer working together, but how do you bring program people and tech people more together and demystify things and power civil servants, including upskilling existing civil servants and that kind of thing?

Jennifer Pahlka: I don't think it's as hard as people think. I think once you start doing it, it can be pretty accessible that getting over that hump of fear and doing it in a way that doesn't sort of drive people away is so important. Fundamentally, I think you have to reframe it and you reframe it around the goals of the project and meeting the needs of the users. So I tell a story in the book about this fantastic team at the Centers for Medicare and Medicaid Services, CMS after Healthcare.gov. They get handed the implementation of a law called MACRA, Medicare Access Chip Reauthorization Act, and they want to knock that one out of the park because their reputation was a little bit bloody by Healthcare.gov. And they do, and part of how they do it is things like having the whole team in a big long hallway and having the policy people explain all the choices that they're having.

In this case doctors, who are the people who use the service will make, and seeing that, well, if there's 10 choices here and then there's 10 choices here and then there's 10 choices here, you suddenly have a million choices that you're asking your user to make. And you go from the framework of let's give flexibility to our users because that would be the best thing for them to, oh my god, we are completely overwhelming them. But the policy people, of course, want the best, but they couldn't see that until somebody went and drew it on the wall. Is that tech? It's a tool of tech. It's a tool of good service design and it just involves markers and walls. There's another time where they used sticky notes to show all the dependencies between the choices that they were asking the doctors to make and could see that they were inconsistencies.

We're asking them to tell us an answer to this question that relies on them getting this data and they're in the wrong order. They don't have the data when we're asking them to make the choice. And being able to put that up on the wall means that they can find that before it gets coded into the system. It's a lot less work. I mean, you're going to catch the problem. Let's just catch it before the product ships. I think when people realize that getting involved with a tech team is going to involve sticky notes and markers, they're a lot less intimidated than when they think someone's going to ask them to write a line of code or rattle off some weird programming thing. It's not helpful to do that. They don't need to know that. But there are a lot of tactics and strategies of tech teams that are incredibly accessible.

Eric Egan: Yeah, that's a good point. I chuckled when you talked about that part in your book and the value of whiteboards and post-its because as someone who was a scrum master myself with a government client. The times I used the whiteboard was probably my most frequently used tool throughout the various projects I worked on, which was both surprising and effective. And at the end of the day, it's at pencil and paper and it still does the job. I do want to talk inevitably about procurement.

Again, another area of interest for ITIF listeners, but the notion in your book that the federal government has developed a capability to procure rather than develop really resonated with me. I mean, the federal I.T procurement process is notoriously burdensome and counterproductive to working in the digital era. There's a great deal of risk aversion. I think you mentioned this earlier, over-prescribed requirements and even a tendency also as you mentioned to over deliver on products that customers haven't even really asked for. This is a hard... It is a big question, but how does I.T procurement in federal government or in government broadly get better and more specifically serve customers better, which is ultimately the goal?

Jennifer Pahlka: I mean, you see great products coming out of the same procurement processes that develop terrible products. So would I like procurement to change? Sure. But what is the difference between the team that uses that procurement process to create something great and the one that doesn't? I think it's culture. And so I have this concept in the book that culture eats policy. You see, our elected leaders are rule makers constantly saying, oh, there must be something wrong with the rules. Let's change the rules. I mean, we have given agencies dozens of other transaction authorities and other ways to get around these things and they don't use them or they use them badly because of a risk aversion. Because if something went wrong, would somebody come back and say, why did you use an OTA here? Why didn't you do something more thorough? And there's a fear that they'll get in trouble.

I really think we have to... I mean, I'm open to any procurement experts ideas about how to change procurement, and I think that a lot of the vendors would agree that these rules don't really help anybody. It's just that they've learned to play the rules. And anytime the rules change, it can be uncomfortable. But I don't think things like protests really help anybody. They're just part of the game that people play. They delay projects, they delay services to people, they make our services cost more, but changing that one thing is not going to suddenly make everybody feel like procurement is easy. So I really think that the powers that we need to think about how they change that risk aversion and it's part of their responsibility to understand how they contribute to that risk aversion.

Eric Egan: Yeah, and I know you also made the point in your book about the way the federal government thinks about procuring technology kind of has to change it. Maybe they can't get to the point that in the commercial space where they're doing continuous development, but incremental kind of development and procuring with that kind of expectation instead of it being... To your point, it's like waterfall procurement still, even if you have an agile organization, if you're trying to procure a half a billion dollar system, which these often are, and it's all for one, and you're trying to do it on a particular timeline, you're already setting it up to kind of fail, especially if you include all the requirements. You don't give whatever the team that's developing that enough leeway to understand what the product... Who the user is, what this should look like.

Jennifer Pahlka: I think what you're saying is that procurement's downstream of funding, so we fund things in a big bang way. The track record for that is pretty poor, but in terms of the costs to the taxpayer and the outcomes, and we do know that when we do things in a more incremental way where we're able to learn while we're doing it and not be forced to say, oh, I know exactly what this FTE is going to be doing on this thing 10 years from now, which is of course solution. I think we all participate in what are essentially group lies.

Here's a project budget and plan that it projects 10 years out and we believe that this is what will happen. None of us believe that that's what will happen, and none of us believe that that's the right way to do it, but we think that that's the way to win the game, so we do it. But I think again, we need the rules of the game to change to say, let's fund a discovery sprint and then let's fund a pilot and then let's fund a first phase of this, and all along the way, let's focus on what we have learned in each of those phases and how we're going to apply that learning rather than let's spend seven years developing requirements for something that's going to get built 15 years from now. It does not work.

Eric Egan: Yeah, I've been on a project like that too. So we only have a few minutes left, but I did want to kind of ask you something about in terms of looking kind of toward the future of digital government in the US. Your book references, and I pointed to this in my own writing, automatic or no touch services that other countries have developed. That have kind of really advanced the notion of digital government, digital services and parts of Europe as well. Is the US headed in that direction at all? What are the barriers in... I know federated structure complicates things a lot, but are there positive movements? Is it ever a thing that we can do?

Jennifer Pahlka: Certainly, records clearance is an example. During the pandemic, there was some automatic service delivery, food benefits for kids in school or out of school, for instance. I think advocates would point out that we do a lot of automatic "service delivery". For instance, those who've gotten the criminal records cleared will tell you, well, putting it on my record was quite automatic. So we're certainly capable of it. I look at the IRS right now, I'm so excited that they not only responded to Congress's request for a study on direct file, but actually have a prototype of one that they provided with the report to say, it's not just words here, but let's have some working code.

And while direct file is not currently planned to have any pre-population of your data in it, it's possible that it could go there and you could have a dramatically easier experience for Americans trying to file their taxes. That will depend on the political environment. It will depend on the team's ability to get traction with the sort of novel and I think very promising approach that they're taking. And things like that I think open up the door for sort of sense of what's possible and then other agencies tend to follow.

But I do go back, I think to what I said earlier, which is it is absolutely possible to share data across agencies. It's just very hard. The legal barriers are much more difficult as we all know, than the technical barriers. Technical barriers can be sometimes too difficult, but when there's a concern that there might be a law in question here, you are very likely to run into somebody saying, it's better to be safe than sorry, and let's take these extra steps and these extra steps and these extra steps, which means it's just really, really hard to get the project to get it done. And so I do think it does, like everything else, come down to, it depends, and it's kind of... Ball’s kind of in our court to keep pushing for it and to support our colleagues, whether they're in a vendor, inside government or advocates outside who are defining this conversation to say, what are the trade-offs we're making?

I have Jasmine Latimer in the book at the end who worked on records clearance saying, I get that there's potential harm in sharing data, but there is clear visible harm in making people fill out the same information and forms over and over again, and we can't pretend that this is not weighing against each other. In the end, we all have to make some trade-offs and we have to stop saying, it's always better to be safe than sorry, it's sometimes better to be safe than sorry. And we all own responsibility for that culture and supporting our colleagues to make bolder decisions.

Eric Egan: Nice. That's a lovely note to end on I'd say. I want to thank you again for joining us, Jen. I really appreciate it. And I highly encourage listeners to pick up a copy of her book, Recoding America: Why Government is Failing in the Digital Age and How We Can Do Better. And also don't forget to subscribe to ITIF on YouTube for other great content and tech and innovation policy and stay tuned for more episodes of Citizen Digital. Bye now.

Jennifer Pahlka: Thanks for having me, Eric.