Why Government is Failing in the Digital Age

All right, TGIF everyone! Welcome back to GovTech's In Case You Missed It. It's great to be back from a 2-week vacation with the family overseas, uh, and wow, the world did not slow down while I was out, and Joe kept In Case You Missed It going. So good to see you again, Joe.

Happy to see you again too.

So we've been totally pumped for today's episode. You know, Joe kind of teased it out on Twitter earlier this week. Today we have an incredible, incredibly exciting episode for you. I mean, as you know, Technology plays such a critical role in the way that everything is delivered in government, from the federal government down to your small town utility. Technology touches everything. And even though there's a new wave of innovation and excitement with new public sector leaders, there's legacy technologies and processes that sometimes hold back agencies from unlocking their true potential. But there's hope, and our guest today has just written a new book that will help you understand how to unlock this potential. She was a driving force of civic innovation even back when I was in government, and she's here today to shed some insight on this for you all. So let's welcome to our virtual stage Jennifer Pawlka, the former Deputy Chief Technology Officer of the United States government, founder of Code for America, a nonprofit that believes government can work for people in the digital age, and she's the author of Recoding America: Why Government Is Failing in the Digital Age and What and How We Can Do Better, and she's here today to discuss her book thesis. Jennifer, thanks so much for joining us.

Thanks, Dustin.

so much for joining us.

It's a delight to be here. Good to reconnect with you, Dustin, and hi, Joe.

All right, so maybe just to start, I kind of mentioned some of your past, but just to help our audience, you know, understand everything that you've been involved in, maybe provide a little bit of background on some of your public sector experiences and how they shaped your viewpoint on recoding America's government as a need.

I've had the real privilege to work across sort of all levels of government, which I think came in handy when we're trying to figure out what's common across them. Code for America, as you know, started back in 2010, really our first class of fellows was 2011. And that was a great opportunity to get to understand the challenges and opportunities of cities. Now that organization works a lot actually with states and some with the federal government, but that was sort of where it was when I was there. And then from that got pulled into the White House for a year to help stand up the United States Digital Service. Um, and I guess from that, um, the wonderful late Ash Carter asked me to join the Defense Innovation Board. So, you know, having worked on state-level programs like SNAP and criminal justice issues, going into the Department of Defense was a real learning experience, um, that I'm, you know, really grateful for. Um, so I, you know, got to sort of do a lot on that. And when COVID hit, um, I helped found United States Digital Response. Response, which is still going and such a wonderful organization that helps state and local governments in particular, you know, manage challenges far beyond the pandemic.

That's great. And you look at that Code for America experience, what inspired you to establish Code for America and how did it influence the ideas and premise for your book?

Yeah, Code for America, you know, I date back to a time that I consider myself a bit naive. Had I known how hard it would be, I probably wouldn't have done it. Um, uh, and, but I, you know, I really just saw this opportunity then to get people with tech skills involved in making services work better for people. And I just was really lucky, I think, that so many people did raise their hand to do it. Uh, first fellows and then joining sort of the long-term organization and, uh, really through that process really deepened my understanding of how government can do better, you know, the subtitle of the book, because I think I had an idea really that it was sort of tech that would, that would help. And I've really, through that work, come to see so many of the things that need to change and believe that there's some things that really precede tech. We need tech talent, we need tech expertise, we need tech teams, before we can get the tech to actually work.

Yeah, I think that's completely right on with what we're seeing too. And, you know, you've worked at all of those different levels of government and kind of seen, you know, the ins and outs of the different nuances, as you mentioned, even from like the defense standpoint down to small cities like the one that I was in. You know, are there common challenges and solutions that exist across these levels of government? Or, you know, do these issues differ significantly as you kind of think about those different bands?

I'd say a lot more in common than there is different. Of course, you know, federal government does different things, but these dynamics that I talk about in the book, which particularly relate to this gap between policy and implementation, really are consistent across all levels of government and all functions, uh, just in a fundamental way. Um, you know, I talk about tech talent and I do think that's really critical, but The degree to which complex policy drives the complexity of tech is another thing that I really learned. And I see that everywhere. And you can't really digitize a process that's, you know, too complicated. You need to simplify it before you digitize it. You see that at every level. And you really see the need for the tech people to be able to be in conversation with the policy folks, the process folks, the compliance folks. in a way that we just don't see enough of today.

That gap that you just mentioned between the policy outcomes and the constituent experience, how does it contribute to this notion you have in the book called policy vomit?

Yeah, I wondered if people would pick up on that term.

We have more terms that we're going to ask you because there's policy comment that we'll kind of get to as we go.

But yeah, so maybe we'll start by defining it. And it's not a term I came up with. I think I'll maybe be, uh, infamous for having popularized it. Um, but as a designer in government who talked about this because she was working in immigration services and she could sort of see the direct match between what was in the policy— these are things, you know, we're going to need to know— and then what's on the forms. And for her as a designer, just taking what you— the information you need and putting it in a form isn't design. It's not thinking about the experience that user's gonna have. It's not thinking about when do you need that information. If they're not gonna get, you know, to point C in the process, then you don't— there's— here's all the data you don't need to ask them right now. You can ask them once you know they're progressing further in a process like immigration or any other. And when we sort of just, excuse the term, but vomit the policy into forms and interactions with government, we really drive users crazy. It's very confusing for them. We need a translation layer, certainly in how questions are worded and how these whole processes are designed so that people have the experiences with government that make sense to them.

Love it. So, you know, in your book, you also make a lot of great arguments around, you know, some of the traditional things that we think about, like a lack of funds or, you know, advanced technologies that are out of the reach of government are kind of, you know, holding us back. But it was like this industrial era culture dynamic. And I thought it was really interesting because We often think technology problems are the other things, right? And you kind of put culture front and center and talk about that. How does this cultural issue manifest itself in aspects like paperwork, which you noted in your book often favors the powerful, and the concept of clutter? So let's talk about clutter.

Well, I think when people are upset about bad government services that are enabled by technology, They think that some nameless, faceless bureaucrat is back there trying to torture them. And what they don't realize is that that bureaucrat or those many bureaucrats that are trying— and I say that word very lovingly, obviously— are dealing with just, you know, in like, for instance, the case of unemployment insurance, 90 years of accumulated policy and process that hasn't been sort of thoughtfully designed by policy architects consistently over time to make sense to anybody. These are things that sort of just fall down from the hierarchy and accumulate in ways that make it really, really unwieldy. So I call it clutter. Yeah, it becomes clutter that really, really needs to be cleaned out before you can charge people with making technology that works. One example in the book, which was just shocking to me, I mean, I continue to learn as I go in this, and yeah, 13 years in working with the California Employment Development Department on unemployment insurance during the pandemic, I was shocked to hear this story from a colleague who was working with the claims processors. One of them, as she was asking questions to try to understand how we would clear this backlog of unemployment insurance claims. One of the claims processors kept saying, I'm not quite sure the answer to your question. I'm the new guy. I'm the new guy. And she finally said, how long have you been here? And he said, oh, I've only been here 17 years. The people who really know how the policy and process of a claim, getting a claim from when it comes in to actually getting paid, They have been here 25 years or more. Imagine how much policy clutter has accumulated in unemployment insurance. And why aren't we advocating for that to be made simpler instead of just continuing to say, you know, okay, well, these, you know, we'll just try to make these 53 state unemployment insurance systems work. Well, they are not working well. Most of them are not working well. And we really gotta look deeper at why.

Yeah, I think it may have been that example in the book that you talked about. It may have been the, the director at the time being at the bottom of the waterfall and the waterfall kind of cascading over them. And one of the other powerful notions that you had in the book was no more concrete boats. So can you elaborate on that analogy and its connection to that waterfall culture in government?

Yeah, um, I mean, when I talk about just the, the way people in technology and government are forced to just deliver something that's going to represent 90 years of policy clutter. They're being forced to build concrete boats. But that term came from an interaction that I had with a leader at the Department of Veterans Affairs when I was working in the White House. And we were trying to clear up some problems with the veterans benefit management system. As an aside, you know, we went in because there was really high latency in the system. And, uh, first day on the job, he said, you know, hey, I'm so glad they sent the White House to confirm that there's nothing wrong. And we find out later that he had solved latency by defining it as more than 2 minutes. So if you clicked and it took a minute and 59 seconds for the page to load, you were not to report latency. That's a lot of latency if you're trying to get through a backlog of veterans' claims. Um, but as again, you know, as my colleague Marina was, we're asking him questions. Why is the system built this way? What's it supposed to do versus not to do? You know, what, how did these choices get made? He continually said to me, you'll have to ask the program people, or you'll have to ask somebody else. That's not my call. And he said, you know, I've spent my career training my staff not to have an opinion on the business requirements. If they ask us to build a concrete boat, we'll build a concrete boat. And that was shocking to me. And when I asked him why he would do that, he said, because then it's not our fault. And I completely understand where he's coming from. He's right about all those things. And yet we need leaders to stand up and say this Concrete boat's not going to float. We need to talk about those requirements. We need to talk about those that are driven by policy. We need to talk about how to make something that— where we've made some clearer choices about what to do and what not to do. So this thing is going to float when it launches.

So one of the other things that stood out in your book is this notion of it has to make sense to a person. And I'd love for you to maybe delve into, you know, why this is such an important concept for government processes, you know, as a starting point and how it can potentially reshape the interaction between the public and government.

That line came from a team that I interviewed quite a lot at Centers for Medicare and Medicaid Services. I talked to— there's only a couple people featured in the book, but I talked to many more of them about this project that came down to CMS after healthcare.gov. So you have a team that has been really beaten up in the press for a very public what's known as a failure. I will say that site enrolled more people than had been projected. So I would call it overall a success, but they'd regardless been really beaten up. And when they get their next law they need to implement, which was MACRA, the Medicare Access and CHIP Reauthorization Act, they are absolutely determined not to have it fall on its face the way healthcare.gov initially had. And they start talking about the barriers that they face to do that. And the first one was, it's very complicated law and it has to do not with the general public, but with how we compensate doctors and medical practices. We're trying to pay them more for better quality care, which is going to improve the quality of care provided to Medicare patients. And the first thing they're supposed to do is make a little explainer. And the first first thing that doctors are supposed to do is choose whether they're a sole practitioner or a group. And they're told that there are 9 different definitions of a group. And this team knows that whatever technology they use, whether it's in the cloud or not, you know, whatever programming languages, if they're asked to code something that is complex in that level from the very first choice, it's, it's just going to be too confusing. And doctors are already threatening to leave the program over how hard it is. to file their quality data, to, to, to bill Medicare, et cetera. They've got to train people. And, um, they're saying, if this new system is as bad as the old systems, and they're expecting it to be, I'm going to leave Medicare. I'm not going to take Medicare patients anymore. And that would degrade the quality of care, not improve it. And so they push back on the policy people and say, we can't do that. You're going to have to find commonalities Among those 9 different definitions, we'll work with you on it, um, so that we have one. And they don't get to one, they get to 2. But it is so much better than having those 9 different definitions because, as the policy lead said to her team, I get that it's complicated, but it needs to make sense to a person. And you're— if you're not a lawyer who specializes in this, 9 different definitions aren't going to make any sense. Now they continue then to push back on the policy team to do things that are just going to make it easier on users over and over again. Um, like exempting doctors who aren't going to be required to use this program based on the prior year data, instead of making them go through a whole year and then exempting them. They had to go through the whole year. They'd have to buy all the new AHR software, train their staff, only be told that they could revert to the old one, which is crazy. But because they make choices like this, they end up shipping the Quality Payment Program on time, under budget, and doctors love it. They call the call center instead of angry, they're calling and saying, something must be wrong. This is too easy. And, you know, the team is delighted. They've really had this huge success.

And I think it's really fostered a whole bunch of success since there, You know, as we travel around the country, we're talking to government leaders across state and local governments, and one of the top priorities that we hear from the CIO community to line of business is around workforce and workforce-related challenges.

Yeah.

Getting tech talent into their departments and agencies, getting new leadership into those same departments and agencies. As you look at that evolving landscape across state and local government and attracting the right levels of talent, How can we also boost tech competency within government around policy implementation? One thing that stuck out to me, I have many notes about your book, but was this belief that they manage, they don't implement technology, right? And there was that disconnect between the two groups. So how do we go about improving that?

Well, I wrote the book because I feel like I've spent the past 10 years talking to people who do technology in government. And I basically feel like they're all trying their best and doing really great work. And what we need to do is convince the people who can make decisions that will make their work easier to make those decisions. I'm trying to get a little bit outside of our community and advocate to others on our behalf. So when it comes to tech talent, for instance, I think we've got a lot of great people especially young people who want to come work in government now. And it takes over 9 months to hire. Can tech leaders fix that without the help of executives, without the help of the legislature, without the help of others who are not generally engaging in these conversations that we're engaging with? No, I don't think— we can only go so far with that until we convince people who don't generally engage with us that this is the way it's going to get better. And I think you're alluding to the fact that a lot of folks who are at the policy level don't engage because they see implementation as a detail that someone else needs to take care of. And if I could do one thing with the book, it would be to change that mindset. Not amongst technologists. I mean, certainly I want no more concrete boats. I don't want people to be saying that anymore. But I want the folks who think that this is not their job and beneath them because they do the important work of policy to say, actually, this is more important than a lot of the work I'm doing. I'm going to engage. I'm going to unblock all the barriers to my tech teams being able to hire. And I'm going to train the people that work with me on policy to deeply engage in a dialogue with the delivery teams instead of constantly giving them directives. But that is a serious cultural shift in government that will take a long time. And we're going to have to keep talking about it for many years.

So we'll have to bring you back on in a decade and see how we've done. Now, speaking of policy, you also touch upon an interesting point regarding the tech people essentially becoming policymakers during implementation. And, you know, how does the shift of responsibility affect the system? Can it be managed better? You know, what kind of words of advice do you have for them?

Well, so for tech folks who are getting tapped to be in policy conversations, it's the same thing we've been saying forever. You know, you have to be a translator. You have to come in with respect and curiosity because you're in a field that maybe feels a little bit different. But you also have to show up knowing that you're bringing something unique, especially digital teams that have people who do real user research and can speak for what the user of this policy or the beneficiary of this policy is really going through and how that's really going to work for them. And increasingly, I see policy teams open to hearing about that user research, to the notion that policymakers need to do the same kind of user research that tech teams do, that they will write better policy, not only by interacting with the tech folks, the delivery folks, the user research folks, but by actually adopting some of their tools on their own and challenging their assumptions. I have a little anecdote at the end of the book from our friends in the UK, where one of these delivery folks starts working with a policymaker who thinks he's got all the answers. And he literally has 600 pages of binders about exactly what the new policy should do. This is a social welfare policy. And he's done all this academic research. And this delivery guy, Tom, says to him, why don't you just take a break and come around and watch the teams do their user research, talk to the people who are going to need this social welfare? And 2 weeks later, the policy guy comes to him and says, You know, I've realized that maybe this is all 600 pages of untested assumptions. Let me put it aside for a little while and really engage in the kind of work you're doing. Then I can go back to that, and my policy is going to be much more informed by the real world. That kind of interaction is what we're going for, and it does take a lot of open-mindedness on both sides.

Your book's filled with so many nuggets. I didn't know that user research had its roots in government.

Oh, yes. I found— I did a lot of research for the book, so I learned a lot too.

That was pretty incredible. Based on your experience, and you look at our audience, we've got those technologists, we've got those policymakers and elected officials. Based on all the ideas that you presented in your book, what would be some of the first steps that you'd recommend to someone in government today that wants to start making these changes in their own area of influence?

I think the first thing would be ask yourself who needs to be at the table and ask, and don't accept just who has always been there. Um, I talk about, uh, the records clearance, um, program that we did at Code for America, where, because states are decriminalizing marijuana, many of them are also making former marijuana convictions now expungible. You shouldn't have to live under a felony conviction if the thing you did is no longer a crime. But because the process, a very lengthy paperwork process, um, was just so burdensome, hardly anyone was getting through it. And we moved from there to automatic expungement, which is really just the recognition that none of that paperwork is necessary at all. Policymakers, please take note. It's not always about streamlining. Paperwork, it can be about completely eliminating it and saying these are records in a database, we can simply write an algorithm that finds all the eligible records, change the records, and we're done. It's a little more complicated than that, as I'm sure your audience knows, but it's much closer to that than letting people try to persist through a year of paperwork and court appearances and all these things. But when you continue along that, you see that some of these expungement laws that have already been written were written in such a way that they will never be able to be automated because they don't understand what data is available for that algorithm to, to, to suck up and find. And I'm certain that some policymakers would say, well, that's, that's okay, we still want to make these choices in the policy regardless. But I do think they need to make those decisions understanding the implications. If your policy will not be able to be implemented automatically, very, very few people will get the benefit of it. And if that's the choice you want to make, that's your decision. But if you want to have the option of making a different choice, you have to ask yourself, who was at the table when I'm writing the law or the policy or the regulation? And it's very uncommon for folks to invite a technologist or a user researcher Or the database administrator, or whoever wrote the data structures, right, to be in that meeting. But now we are seeing that it happens in many states because they know that if they don't, they will write something that sounded great and has zero impact.

So now the most important question: where can our audience go to learn more about the book? And most importantly, what to do after they read the book?

Why, thank you for asking that, Dustin. I have a website, recodingamerica.us. You can certainly click on the link to buy the book there. But once you've read it, if you get a chance to read it, please return because I do have a bunch of resources there for folks across all disciplines to take the next steps and I think be part of this whole agenda of recoding America.

And then where can our audience go to find you? It's like the prompts below you are just reading my mind here. So technology.

You can find me on Twitter at twitter.com/palkadot, and the magic there will be knowing where to put the H in my name.

Well, Jennifer, thanks so much for coming on In Case You Missed It and sharing all of your perspectives on government. And we make sure that our audience picks up a copy of your book. It is an important reading and no better time to pick it up than Friday and get some weekend reading going. So again, thank you very much.

I hope you all enjoy it, and thank you so much for having me on the show.

Have a wonderful weekend, everyone.

You too.