Jennifer Pahlka is the founder of Code for America, served as the United States government’s deputy chief technology officer, and is author of the book Recoding America: Why Government Is Failing in the Digital Age and How We Can Do Better. Jenn joins us to share her personal reflections of her time in government and the path forward.

[[Audio 1]]

Michael Chui (co-host): Janet, on this podcast we have had a lot of guests who have shared their insights about the economy, including how monetary and fiscal policy can influence labor markets, capital markets, and what that means for ordinary people.

Janet Bush (co-host): Yes, indeed, and other guests have talked about big trends in the world, including digitization, and how that has affected all of us.

Michael Chui: Well, today’s guest has led several well-known efforts to help bring the benefits of digital to the public sector. So much of what we are able to do with our mobile phones and computers has made our lives as consumers easier. And it just makes sense to ask how public services can also be as easy to access as these other services that we use. And making that connection between policy and people requires real work. Or, as one of our previous guests, Tyler Cowen, has described it: “building state capacity.” It’s just true that implementation is really important.

Janet Bush: Yes, in the UK, it is really mixed. Some services are fantastic—the vehicle licensing service is super efficient. But then the Inland Revenue Service suddenly decided I wasn’t born on the day I was born on and after 40 years of tax returns they didn’t believe me. So that was slightly hellish. I will be really interested to hear what good practice is.

Michael Chui: Twenty-nine again!

Janet Bush: I wish.

Michael Chui: Jenn, welcome to the podcast.

Jennifer Pahlka: Thanks, Michael. It’s great to be here.

Michael Chui: Let’s start with your story. How did you end up doing the things that you ended up doing? Where did you grow up, and what was your path to what you’re doing now?

Jennifer Pahlka: My first job out of college I was working in a child welfare agency, actually. I didn’t stay in that. It was too hard for me emotionally. But I ended up in tech. And so I think when I discovered the world of government, I certainly hearkened back to that time in child welfare and thought about how important it was to get tech right in areas like taking care of kids who need to not be at home for a while.

But really it was sort of a classic—living in San Francisco in the late ’90s, you couldn’t not end up in tech. But from there, I got interested as we were building out this brand called Web 2.0, which you’ll remember, but many of our listeners will not.

[[Disruptor1Up mgipodcast]]

The idea that, hey, these ideas, these principles and values of the participatory web, different from the web that had come before, were really best expressed in the creation of our government that’s supposed to work for us. It’s supposed to be participatory.

And so through working on Web 2.0, and then from there moving to Gov 2.0—this was in the years just before Barack Obama was elected president—I had the idea to start something called Code for America, to use those principles and values of the lightweight web that was a new thing back then, to make government work better.

And I started a nonprofit. I ended up running that for ten years, with a break in the middle to go to the White House. And that’s really been this arc, for me, of getting to know government and getting to more deeply understand why it doesn’t always do what we want it to do.

Michael Chui: What was that nonprofit, and what did it do? You spent a decade there, and you founded it.

Jennifer Pahlka: I founded it because I had a friend who was working as the chief of staff of the mayor of Tucson, and he was asking me, “We’ve got all these problems in our city. You’ve got all these Web 2.0 developers who are making things like Twitter and Facebook and Google. Why can’t they come help us make apps for Tucson that would really solve a bunch of problems for us?” He had done Teach for America, and so it ended up being called Code for America because we said, “Hey, what if there were a Teach for America for tech and government?”

But it isn’t exactly like Teach for America. At the beginning, it was a service year program for folks in tech to spend a year helping city governments do tech and service delivery better. Now, 13 years later, it’s a little different. We don’t do the fellowship program anymore. It’s really about working with states and cities and federal government on service delivery, especially in the safety net.

And, of course, I should say I haven’t been there for three years. It’s been run by a wonderful woman named Amanda Renteria since just before the pandemic started.

Michael Chui: What does “service delivery” mean? Because you’re not out there fighting fires or whatever. So what does service delivery mean in this case? What does Code for America do?

Jennifer Pahlka: We think a lot about the regulation of technology and government, and people talk about tech policy. For me it was, “How are citizens interacting with their government? What do they need from government, and are they getting it?”

For example, the first year of Code for America, we worked with the city of Boston. And they had a policy change around how kids were assigned to public schools, or what schools the parents could apply for their kids to go to. And they needed a way for parents to interact, to apply to these schools.

The new policy was around getting kids to be able to walk to school. So it was this walk-zone scheme that they had. And the way that they had been communicating this was a 14-page printed brochure in seven-point type, which, sure, you can read about these different schools. But the key thing you need to know in this new policy is, is that school in my walk zone?—which is a mapping problem.

We had a team there working with Boston, and they were able to very quickly build a website that would allow you to put in your address, the age of your kid, whether the kid had a sibling in a public school, and it would tell you, “Here are the schools that you can apply to.”

[[MostPopularArticles 5]]

That sounds very, very simple. It is a very simple example of a kind of service delivery. But the fact that our team was able to do a beta version in just a couple of weeks and get it launched in just a couple of months was really unusual. The folks in Boston told us that had that gone through typical procurement processes, it would’ve taken at least two years and cost at least $2 million. This was the revelation.

There’s all sorts of services that government provides to people, but in this particular case with the schools, the director of the public schools said to us, “You’re changing our relationship with parents for the better. They have greater faith and trust in us because we were able to get them this information in a snap.” And that’s what we’re going for, is greater trust.

Michael Chui: And there is this weird sort of dichotomy in terms of our expectations, that we’ve gotten from consumer internet, consumer tech—we don’t look at instruction manuals, right? We just download the app and expect to figure it out. And then all this other stuff, number one, in enterprises in the private sector, but then particularly for the public sector, you get these things, and our expectations are a lot lower. And so it’s surprising to find something that actually feels more consumery. Is that fair? Is that what you also discovered?

Jennifer Pahlka: I think expectations are changing, though, because of the very reason that you put forth. If you know it’s that simple to deliver a service on your phone in the private sector, then you ask the question, why is it so hard in government?

Think about all the government forms that you’ve printed out off the web. The form is one page, like your W-9, your W-2 or whatever it is. The form is one page. It doesn’t ask that much. There’s seven pages attached of instructions that nobody reads. But if it’s your tax return, there’s a lot of reading of the instructions.

It’s really, really hard to figure that out, because it wasn’t designed really in the same way that, say, an app on your phone was designed, which was fundamentally grounded in enormous amounts of user research to understand if people really get it and can do it easily.

In government what we say is, the applications and the forms are designed to meet government needs. If it’s something you like using, it’s designed to meet user needs. And that’s fundamentally, I think, one of the themes of my work for the past 15 years now, is “let’s meet user needs.” The government needs will all still be there, but we can put the user needs first.

Michael Chui: Let’s pull on that thread. You do write about it in the book as well. What are the practices that constitute user-centered design? What does it mean? How does it end up that we get stuff on our phone that we don’t need an extra instruction manual for? And then there are these other things where you have more pages of instructions than you do the actual thing you’re trying to get done.

Jennifer Pahlka: Maybe the way to talk about that is to contrast the legacy government process for creating something with the typical user-centered startup process. In a startup—and I don’t mean to lionize startups; they have their pluses and minuses—they can be very good at starting with something very small and simple, having users use it from the very beginning, so it’s shaped by an understanding of what works for them.

You see that they’re failing at this point. That’s not a future they’re going to use. “This way of wording that question is confusing,” “the submit button is in the wrong place,” all of these things. It’s ultimately cocreated with the users, because the people designing the application are so in tune to what users are really taking advantage of and how we’re actually getting to the outcomes that we wanted.

Uber would never have worked if people didn’t find it so easy, right? And it’s not an accident it was easy, because they constantly iterated on it whenever they would see that something was a hangup for a user or something made it easier. And so it’s a very iterative process. It starts small, and they add features as you go rather than trying to get all the features in up front.

Now, in contrast, in government we have this notion that’s really very much in parallel with a lot of enterprise software development, which is the way to build software is to spend sometimes years or even decades gathering all of the requirements so that we know absolutely everything this software is supposed to do, and then handing that off to teams of project managers and developers who don’t really ever show what they’ve built until it’s all done.

And then they’re getting what they call “user acceptance testing” rather than ongoing interaction with these users. You don’t have something that people use immediately and iterate. You’re trying to get all of those often literally thousands of requirements done before anybody ever sees it. And that’s a classic recipe for what I call in the book a “concrete boat.”

Every time you’ve heard a headline about Healthcare.gov or something else like that, that the government spent a lot of money developing, they launched it, and people really couldn’t use it, whether because it didn’t have uptime or they didn’t really know how to use it. When it’s shipped, it’s like a concrete boat, because it sinks the minute you put it on the water.

Michael Chui: As you talk about this, there’s a waterfall—let’s get all their requirements up front. And oftentimes for very good reasons, right? You talk about the number of edge cases, because you actually want to serve everyone. Whether it’s different languages or abilities, it often gets all written down.

How do you think about delivering something that doesn’t work for everyone? Because for a good reason everyone wants equity, right? You want to be able to serve everybody. But if you’re saying, “Well, let’s start with something smaller that serves 80 percent of the population,” then does it feel like a trade-off?

Jennifer Pahlka: One context for government, of course, is that usually there are the legacy channels. There’s a call center. There’s a paper form that you can fill out. In Healthcare.gov, there were both of those things, and even in-person centers that you could go to. You can go in and have someone help you fill that out. So you can serve everybody through a variety of channels.

There’s been, I think, a misinterpretation of this desire for equity that says, “Each channel must serve everybody and must serve them in the exact same way.” And people will talk about, and I think correctly, this difference between equality and equity. The exact same thing for everybody is actually not going to meet everyone’s needs.

If you have a lot of edge cases in your particular situation, and perhaps you don’t speak English very well, it’s going to be very hard to develop a website that works for you from day one. It should work for you on day something—let’s say 200. You should add those edge cases in over time, I believe. But it’s going to be very hard to make something that works for everybody on the first day, because every edge case is even more complicated than the last one.

It’s not that I want websites that only work for the privileged. It’s that I want websites that eventually work for everybody, and I want ways for people to interact with government that are the right ones for them, given their needs.

Michael Chui: You have a rather striking anecdote in the book where one of your colleagues ends up challenging someone and saying, roughly, “You can either have something that works for 80 percent of the population or something that doesn’t work for anyone because we’re not prioritizing.”

Jennifer Pahlka: I hear this all the time. The second part of that story is that my colleague says this to a person in leadership in an agency. This is actually around Healthcare.gov. And it’s the truth. But it’s so unwelcome, as news, that the leader hangs up on her.

I hear that a lot, that the leaders don’t want to hear that we need to have priorities, that we’re not going to get it all done from day one. And I hear this when I talk to teams all the time, especially since the book came out. People call me and say, “You talk about this product management framework as opposed to project management.”

And we can talk about what that is, but fundamentally, in a product management framework, you are setting priorities. You’re saying, “This is more important than this. This is what we’re going to get done up front, and you’re committing not to building a concrete boat that will sink on launch because it’s so overloaded.”

But they say to me, “We’re trying to do that, and we have our priorities that we think are based, really, on informed understanding of the needs of the users. But our leadership says, ‘I don’t want to hear it, do it all.’ What do I do?” And I think that’s something we really need to talk about more in government is, are you actually willing to make choices? Are you willing to set priorities? Because we get better outcomes for everyone when we do that.

Michael Chui: Actually, let’s talk about that. What is the difference between a product manager and a project manager?

Jennifer Pahlka: The language I’ve borrowed from some friends is: project management—which is extremely important, and I worship good project managers, but—project management is the art of getting things done. In a government context, there is a lot to get done, because we’ve so often spent years developing literally thousands of requirements.

Product management is the art of deciding what to do, and that is where we often fall down, not saying “Here are the 7,000 undifferentiated, unprioritized features that this thing needs to have,” but saying, “The most important thing for us to get at launch is this set of people with this functionality.”

Maybe there’s an API that allows third parties to do other parts of it. Maybe stuff is coming in launch two. Maybe there’s creative ways of solving this problem that aren’t just every single piece of it all at once. And I think it’s resonated with a lot of people, that bring more product management thinking to government could really, really help.

Michael Chui: What is Byrne’s Law?

Jennifer Pahlka: I think I coined that term. Mike Byrne is a government technologist who I really, really admire who has worked at the FCC [Federal Communications Commission] and the CFPB [Consumer Financial Protection Bureau] and a bunch of different places. And he always said, “If you just decided to fulfill 80 percent of the features, it would cost 15 percent of the cost that was proposed.”

That’s a pretty big difference. It’s not like we’re cutting off a few features, so we’re saving a few dollars. It’s like all those things at the end really ramp up the cost in a disproportionate way. But if you can pull it down to “we’re just going to do 80 percent of this,” you’re going to be able to launch something with much less money but also much less time, and then get to users earlier.

Michael Chui: One other thing you talk about, too, as we’re talking about the process of actually developing technical stuff, or technology stuff in the public sector, is how you evaluate the progress of a project. Can you talk more about that? Because one of the things you do is distinguish between how a venture capitalist might view the progress of a portfolio company versus some of the legacy ways in which the public sector, and again, as a former public-sector municipal person, I recall this.

Jennifer Pahlka: You’ve seen this in action. Well, the oversight matches the framework in which it’s been created and developed, which is, let’s look at the plan that you set forth, let’s look at all the requirements that have been laid out. Tell me how many requirements have been met. Tell me how well you are operating according to plan.

That sounds fine, but the reality is—and we’ve seen this over and over—you can meet the requirements technically without actually creating an application that works for people. So just looking on paper at what boxes have been checked is no guarantee that you’re getting working software.

As any good product manager knows, the plan that you set, let’s say, five years ago, when someone was developing the requirements and getting the allocation appropriation for the money, for the project, and then taking it out to bid—that’s actually kind of a bad idea, to stick very close to that plan. Because things have changed.

Most importantly, the whole point of the way we develop software successfully today is that you learn as you go. And if you’re only held accountable, if what good looks like is just, “Well, five years ago I said in March of 2025 we would be doing X, and now we are doing that,” that’s probably the wrong thing to be doing. We should be really valuing those folks who say, “Well, we learned this, so we changed this.”

Now, again, if you think about the way a VC interacts with a portfolio company they’ve invested in, they’re saying, “Show me the software. What do users think of it? What’s your adoption like? Are you getting these outcomes?” And if you’ve said you’ve changed the plan—I’ve seen this because we have many funders of Code for America who were VCs, and they interacted with me this way. If you said, “Well, I’ve changed the plan,” they’d say, “Great. You should be changing your plan.” Not “Why are you behind schedule? Why did you say you were going to do X but instead you’re doing Y?” So, we have a really fundamental shift that needs to happen here.

Michael Chui: One of the other things I found interesting in the book, we’ve been talking about building technology in the public sector for citizens. But oftentimes it’s not something new. You talk about the archaeology of technology. Say more about that. Why does the history matter?

Jennifer Pahlka: This became the most clear to me, actually, when I was starting to write the book. I had left Code for America and I was supposed to be going to write, but instead, of course, the pandemic happened. And one thing that happened for me was that Governor Newsom here in California asked me to co-chair a task force for looking at why we had such a backlog of unemployment insurance claims in the state.

Everyone was saying, “Well, we have these unemployment insurance systems in California and every other state that have COBOL [Common Business Oriented Language] in them; they’re really outdated.” And of course they do have COBOL in them, but I proposed that the COBOL was performing quite well. That wasn’t really the problem.

But you talk about an unemployment insurance system, and when my colleagues and I went in there and really pulled back the hood on what was trying to deliver these benefits to people in a timely manner, you don’t see a system. You see a layer of technology that was built in the ’80s, and then they added another layer on in the ’90s, and another layer on in the 2000s. And because of the way that we think about government technology—which is never backwards-looking, everything needs to be a new layer of paint, tell me what new features we’re buying with these taxpayer dollars, but never, wait, how does this interact with what happened before?—you end up with an incredibly fragile sort of layer cake, or we thought about it as literally archaeological layers of technology that don’t really talk to each other.

So there wasn’t a system. There were a bunch of disconnected, fragile systems. And when you look at why people weren’t getting it, again, that bottom layer written in COBOL—wow, is COBOL a pretty durable technology. If you could go through the COBOL part of the system, you were getting paid, and quite quickly, actually. We paid millions of people in California.

But if you had to go through one of the subsequent layers that had been tacked on over time, that’s when you were going into the backlog, and people didn’t get paid, sometimes, for a year. I think there are people who still haven’t gotten paid. Not because the people who work there are stupid or lazy. By no means is that true. They were working so hard. But because the systems were not really built to work together.

And we really have to start thinking about that differently. But the other thing I would say is that the layers of technology are almost less important to critique than the layers of policy. You have policy in UI [unemployment insurance] that goes back to the 1935 Social Security Act. And it’s much like the technology in that it’s always added to, it’s never removed. That’s how you think of, you go excavate a site, the reason there are layers is that stuff falls on the ground, it doesn’t get swept up, and it gets added on top of each other.

In the state of New Jersey, for instance, they say there’s 7,119 pages of active regulations that govern UI. That’s a lot. In California we had this one claims processor who my colleague Marina was talking with who kept saying, “Oh, I’m the new guy. I’m still trying to figure this out.” And by the fifth time he said that she said, “OK, so you’re the new guy, how long have you been around?” He said, “Well, I’ve only been here 17 years. The folks who really know how to process these claims have been here 25 years or longer.”

If you want to ask me why we had backlogs in every state during the pandemic, of these claims, it’s because 7,119 pages of regulations you have to learn, you’re still learning this system 17 years in, that’s not something that scales.

And I really wrote this book in part because I want to challenge the notion that fundamentally it’s the technology that’s the problem. It’s things like the accumulation of policy over time that’s never simplified, never subtracted from, only added to that is a much more core driver of dysfunction than the technology. The technology just expresses that policy dysfunction.

Michael Chui: As Larry Lessig said, just to paraphrase, the code is law, right?

Jennifer Pahlka: Yup.

Michael Chui: These layers of sedimentation and policy then get reflected in our technology as well. But what’s the solution? Do you have to start from scratch? Because that’s really hard and sometimes expensive.

Jennifer Pahlka: It’s interesting, when I wrote the book we were still, what, two years out from ChatGPT making everybody focus exclusively on AI. And I didn’t really understand what we would use AI for at the time. But since the book’s come out, it’s clear to me that one of the uses that we don’t talk about that much is policy simplification.

I don’t think that AI is going to automatically simplify 7,119 pages of regulations. But we have tools now that I think we have to hold our elected leaders accountable to using. They need to understand that the complexity of these programs comes from—primarily, not exclusively—the legislative branch.

They’ve added on rules. And I saw it happen in real time during my time in California. Even as they were buckling under these thousands and thousands of mandates, and that was holding them back from delivering this service, the legislature added more mandates that they still couldn’t meet.

You can see the possibility of saying, “Let’s take all of this voluminous set of rules and ask AI to suggest where simplifications could happen.” Where do you have conflicts? Where has something been deprecated and it’s no longer relevant?

This is not rocket science. You could say we need a regulation that really just says, at the end of the day, just that: this is a great way to have AI help you say, “How do we get to that state?” Actually, so I’ll tell you, in California one of the reasons that it’s taken 17 years to learn it is just the manual that they get when they arrive.

It’s not all 7,119 pages of regulations, but it’s an 800-page manual that you have to learn when you arrive. Could we get that down to 50 pages? Could we deliver an equitable, successful program of unemployment insurance that meets the goals of the public and our lawmakers and complies with the most important regulations—and there are many that are important—that can be communicated in a 50-page manual? I think we could. And I think it’s a great moment in time to ask AI to help us with that.

Michael Chui: What are the other implications of, particularly, generative AI, which have shown up probably roughly just as you were finishing the galleys of the book? How has your thinking evolved as you’ve seen this technology really take off?

Jennifer Pahlka: A couple months before the book came out, I happened to be visiting the New Jersey Department of Labor. This was, I want to say, a month after ChatGPT was released. And I hadn’t thought about it that much.

We were talking with the folks about how their recovery from COVID was going. And one of the things that people do in the services that also doesn’t seem to have as much to do with technology is, they rewrite the letters that people get. So if you’ve ever applied for unemployment insurance—depending on your state—you get this sort of steady stream of communications, emails and actual letters in the mail.

And for the most part they have been unintelligible. They’re not clearly written, so you don’t really know what to do. Classically, in California you would get something called the zero-award letter, which would say, “Yeah, your award will be,” and then it had this whole grid and everything was zeroed out.

And you’re like, “Oh, I guess that means I’m not getting any unemployment insurance.” And actually what it meant was “we’re doing ID verification on you.” But how would you know that? So it would send people into panic all the time.

New Jersey didn’t have that problem. But they did have, as I think most government agencies have, letters written by lawyers that normal people can’t understand.

Janice Cho was a designer there. And she had been one by one taking those letters, rewriting them to be simpler and clearer. Then she would take them to the policy team and say, “Is this correct? What have I gotten wrong? How do we improve this?” And then once the language was done, she would actually do the graphic design of the call to action—big, bold, black, at the bottom, that kind of thing.

Now she would have said, “Well, now I just plop the letter into ChatGPT with the prompt, ‘Rewrite this so I can understand it better.’ I still go and do all the things I used to do. I still go to the policy team. We still check it. We still revise it. We maybe ask ChatGPT to do another version of it. We still redesign it. But I’m getting through them about five times faster because it’s a pretty good tool.”

And I thought, “This is fantastic. This is exactly what we should be using, ChatGPT, certainly other things as well.” But I have this idea in the book: we need government that makes sense to a person. This is what our friends in Medicaid keep saying—it’s only going to work if it makes sense to a person. Well, that’s using AI to make government make sense to a person.

And the danger that I feel we’re headed towards is that people realize, OK, it is too complicated, and AI can understand it, and that lets us off the hook for simplifying it. That’s a bad path. Because then you have incredibly complicated things that it takes 25 years for a human being to learn, and then AIs who understand it.

The AIs are just going to talk to the AIs, but we lose sense that the humans can actually understand what’s going on and defend it and know how to change it. And we should be using AI, as I said before, to simplify the regulations and rules and processes, not to cover up for their overcomplexity.

Michael Chui: I’m going to pull on another thread as well, maybe even leveling up a little bit. One of your major sections in the book is about the mechanicals at the gate. What is your distinction between intellectuals and mechanicals and the work of policy versus, I’ll put in quotes, “implementation”?

Jennifer Pahlka: That language is borrowed from some write-up of the British civil service, where they call out those two groups. And it resonated with me because I had this feeling the entire time I was in government that I think many other people have felt, that part of what’s wrong is that there is this class system, essentially.

The policy class runs government, and everyone else is in this implementation bucket. And it’s just much less important. It’s not very highly valued work. And it’s not highly valued in the sense that the goal of the policy class is to be so prescriptive that by the time we get to implementation, you’re just doing what someone else told you to do. You’re not exercising enormous amounts of judgment.

When the digital revolution started, let’s talk about, say, the 1990s, when companies like Amazon and Google were just starting to really change our society fundamentally, there were two members of Congress who, I think, recognized that this was a big deal. And that the White House, being the most powerful place in US government, needed to have a strategic take on this new digital technology.

There was this real tension between, does this belong in a place like the White House, or is it really fundamentally the work of the General Services Administration? Because they are America’s buyer. This is just tools that we’re buying. And though these two members of Congress were asking OMB [the Office of Management and Budget] to take responsibility for digital strategy, OMB’s deputy director at the time said no, that’s not for us. That’s operational in nature, and therefore inconsistent with the policy role of this institution.

I think that one line encapsulates a certain attitude that is I think fundamentally outdated in the digital age. I think that our policy class fundamentally mistook what clearly proved to be a digital revolution for simply a shift in the tactics, a shift in the tools of implementation.

Michael Chui: You have an interesting passage which I’ll read back to you. “Government leadership has typically seen implementation as a second-class job. Implementation and policy cannot be so neatly separated.” I think we actually see similar kinds of things if you substitute the word “strategy” for “policy” in the private sector, where strategy doesn’t just throw over the wall and technology implements things. They really need to be put together for that to matter. Does that resonate with you?

Jennifer Pahlka: Yes, 100 percent. And I’ve had a lot of people since—I focused on government in the book, but I’ve had a lot of people from the private sector tell me since the book came out that that’s true in their organizations as it relates to strategy.

And if you think about it, in a certain sense what I’m saying is this sort of social hierarchy of policy at the top and implementation at the bottom—think about Silicon Valley. It’s changed a lot, but if you go back to when a lot of these companies were young, their founders wrote the original software. They are founded and run by technologists, by implementers. And they succeeded early on because the strategy and the implementation were the same thing.

We have a concept that I wrote about when I was at Code for America called “delivery-driven policy.” And my colleague there, Dave Guarino, would talk about product management that’s driven by support, literally your customer support. When you are basically understanding everything that your people in your customer success or your call center or whatever are finding out about what your users are experiencing, and that’s how you’re developing your product, that is fundamentally different. It’s being driven by the bottom of your organization, not what we would call in government at the top.

I have huge respect for policy makers. I work with them much, much more now, and actually more than ever am enjoying working with them, because they are understanding this and finding ways to bring those insights from the user level, the bottom level, up into their work. A lot is changing.

Michael Chui: I think from our McKinsey Global Institute perspective, we aspire that our research actually informs strategy and policy, but we describe our work as being micro-to-macro. It’s based on the learnings at the micro level that we find these macro findings.

One of the other things that comes up, too, in the book is a little bit of it comes from this dichotomy, but how much technical capability do you need to have, in your book’s case in government, but also we see this in the private sector too where there was a time where—just outsource all the IT stuff. Just have IT specialists do that for you, and just be a procurement shop. But we see more internal organic capability building up. Why is that? Why do you need that?

Jennifer Pahlka: I think capacity really is the key, some internal capacity. And it certainly does not mean that we don’t outsource, especially in government. We will continue to outsource. The question is how will we outsource well, and how will we operate in a product model instead of a project model?

In a product model somebody has to decide what we’re actually doing, instead of just fulfill 7,000 requirements. So I do think we need some technical capability inside. I spend some time in the book going into the history of why we don’t have it, what decisions were made in the ’60s, in the ’90s, in the 2000s that really kept us very impoverished on that front in government.

But where that conversation has gone since the book came out, people keep asking, “OK, so what’s the right amount to have internally so that you’re outsourcing well?” And I think even more important than that, what are the roles that are important to have internal? What do we need to do internally? There’s a lot of ways to answer that. There is no one answer for everybody. It’s just going to be different.

If you had to boil it down, it’s the government’s job to understand how the systems work, how delivery happens, where it fails, and, yes, then you can contract that out to people. You’re going to hire people to do parts of it.

Product ownership, I get a lot of questions about what’s the difference between product ownership and product management. That’s a great conversation to have, but ultimately you’re finding some balance between what kind of core understanding and capabilities do you have in-house that enable you to get great contractors doing great work? And that is a conversation that I’m really pleased to hear so many people are having.

It also gets back to this concept I talk about in the book around that, which is—going back to the ’60s, government has tried to declare what is inherently governmental and what is inherently commercial, but there’s a category of commercial, you always outsource this, and a category of inherently governmental.

It was always like policy is inherently governmental; technology development is inherently commercial, we always outsource that. Well, the problem is when your developers are essentially making policy decisions, when they are making the key decisions that, yes, affect your policy, the implementation of your policy is different in the software. They’re making the key choices that mean that your policy succeeds or fails.

How do we not have an opportunity to reinterrogate that concept of inherently governmental? Because the concept dates back to the ’60s, long before we had these problems, long before we were serving citizens through digital technology. We have to re-have the conversation now that we’re in a digital age. And guess what? Now we have to re-have that conversation because we’re in the age of AI. But it’s a conversation we absolutely have to have.

Michael Chui: It’s also interesting, too, that it comes up in your book, but we’ve had other guests on the podcast, you can argue about what government should do or how big it should be or whatever, but actually having state capacity, whatever you’re going to have government do, you better have it do it well, actually comes up over and over again. And that’s an interesting message.

All right, if you don’t mind, why don’t we do a quick lightning round of quick questions, quick answers?

Jennifer Pahlka: OK.

Michael Chui: You ready?

Jennifer Pahlka: Yeah.

Michael Chui: What’s your favorite source of information about how digital technologies are being applied to help people?

Jennifer Pahlka: That’s a good question. I don’t read it regularly, but I will say the most interesting stuff that I get is when people forward me Reddit subreddits. Because you’re hearing what’s actually working for people. It’s a bottom-up view.

And I contrast that with—here I have on my desk a memo from the Office of Personnel Management. It’s very interesting. I have to read these pretty much every week to follow what’s going on, but it’s very top-down. And I crave the bottom-up.

Michael Chui: What worries you most about applying digital technologies in the public sector?

Jennifer Pahlka: I believe that if we continue to let the public sector fall behind the private sector—and there’s different ways you can caveat that; I’m not saying the private sector always does things well—but if we continue to disappoint the American public in the way that we offer them services, we really are at the point where people are so frustrated that they’re going to extremes in terms of what they want. They want a strongman, then, to fix it all. And I think that what I worry most about is that our slowness in improving government services through digital technology is threatening our democracy.

Michael Chui: What gives you the most optimism about applying digital technologies in the public sector?

Jennifer Pahlka: At the end of my book, I profile a woman named Yadira Sánchez who has worked at CMS, Centers for Medicare and Medicaid Services, her entire career. It’s the only job she’s ever had. She’s not one of these fancy people who came from Google and has done their little private-sector thing in government. She, and the way she works, the outcomes she’s gotten, the respect she has from her colleagues and her commitment to, in her case, better healthcare in this country, is the single biggest source of hope for me in the past ten years. If we could have a million Yadiras, we would all be fine.

Michael Chui: What’s your favorite application of digital technology in the public sector?

Jennifer Pahlka: You mean like a specific one?

Michael Chui: Yes.

Jennifer Pahlka: Anything that happens automatically.

Michael Chui: What application would you most like to see built?

Jennifer Pahlka: OK, odd answer. I would most like to see a really kick-ass way to apply to be a public servant. We need a better way to onboard people to do this work, and right now going through USAJOBS is just a bad start to something that could be a really fantastic career.

Michael Chui: Other than the US and the UK, which you mention in your book, what country’s government that is making the most effective use of digital technologies that you’re aware of?

Jennifer Pahlka: OK, so everyone here will say Estonia, and absolutely—they’re doing amazing work, and it’s not just in digital service delivery, they’re really a digitally smart country. But they get a lot of love. They’re also much smaller, they have, it’s a great illustration of my point that they have far less policy debt, policy cruft. They’re working with just a much thinner layer of regulation and process.

I would go for a country like Bangladesh, actually, which is working with nothing but has done incredible work in policy simplification to make services easy to use. Most people don’t have any access to digital technology, so they’ve made these service centers where folks can come in and someone can help them use the computer.

And with orders of magnitude fewer resources than any of the other countries that we’ve mentioned, and in a very poor country, they actually are doing a fantastic job getting people the services they need using what we would call appropriate technology.

Michael Chui: What would you recommend that a teenager study?

Jennifer Pahlka: Civics, first and foremost. And then, I don’t know where you go to get a degree in this, but user research. The people who get degrees in user research in a certain way are people like public defenders. They actually really understand what drives people, especially folks that are the most needy in our country.

Anything that gives you real-world experience so that, as you said, Michael, it’s the micro to the macro. You can’t operate just in the macro. Of course, you need the macro, but it’s got to be grounded by a true understanding of the micro, the on-the-ground experience that people have.

Michael Chui: What would you be doing if you weren’t on this path?

Jennifer Pahlka: The joke amongst my friends, because I once said it in an event, is that I would like to be Secretary of Agriculture. Because I think food policy and agriculture policy is just a fascinating area that I don’t know enough about, but I see how it drives everything else. So that’s the fun joke. I am as unqualified for a role in that as one could possibly be, so it would have to be a completely different fork of my life. But I would love to. And that’s funny, because as somebody who gives such a hard time to policy people, that’s actually my ambition, is to be in a policy domain that I don’t understand.

Michael Chui: There’s a place in the multiverse where you are Secretary Pahlka.

And finally, what is one piece of advice you’d have for listeners of this podcast?

Jennifer Pahlka: Use government services, even the ones that you don’t have to use. So, for example, most of us listening to this podcast don’t do our own taxes.

My recent experience was because I had to do it with my daughter when she got her first job and she had to file taxes. And I said, “Oh, that’s easy. There’s a 1040EZ form.” Turns out they’ve deprecated that form and it’s not easy at all.

You need to stay in touch with the experience that the rest of the world has with government services. If you’re not on food stamps, you’re not in the criminal justice system, you’re not a veteran, you actually aren’t having the same problems with government services that most people in our country have. And you are a worse citizen for it. You should make yourself go through those experiences.

Michael Chui: Jenn Pahlka, thanks for joining us.

Jennifer Pahlka: Thank you so much for having me.