S5E17: Lifeboats: Jennifer Pahlka

This is Larry Lessig. Hope has got to be digital as well as analog. If we're going to get a government that can work, we need a government that can work in the digital age. And as I suspect most would suspect, we are far from that now. We have government agencies that still rely on federal fax machines, and we're not long since we had a State Department where email messages could take hours to move from one floor to another. The election of Barack Obama triggered an enormous energy among technologists and policy wonks to try to change this reality. I remember attending an Obama event at Google where Eric Schmidt obviously jokingly asked Obama what's the most efficient way to sort a million 32 bit integers? And after a brief comedic pause, Obama replied, I think the bubble sort would be the wrong way to go. The audience loved it. It loved the idea of a young leader, young enough to know the digital world, even if his first obsession with digital was and the Obama administration did take extraordinary steps to shake up the bureaucracy and to bring digital sophistication to Washington. But in the astonishing book that we'll talk about in this episode, Recoding why Government is Failing in the Digital Age and How We Could Do Better, Jennifer Palka explains why there is a whole lot more work to be done. This was a fascinating book for me to read, maybe especially for me as I'm a law professor who is obsessed about the relationship between law and code. And yet here was a story about especially the lawyers who had no clue about how to think about the relationship between law and and code. More than anything I've read, and maybe even more after this conversation, I am completely convinced that we need a whole new way to think about regulation, a whole new way to practice the teaching of regulator wannabes, which many lawyers think of themselves as to teach them how to think about regulation more generally. I fantasize about launching a new law school or a new school of regulation that would think about the trade offs among modalities of regulation, law and code and markets and norms, and develop a more sophisticated understanding about how these modalities interact and how we can achieve public objectives given this interaction. But all that's beyond the conversation with Jennifer Palka today. Jennifer is the founder of Code for America, launched in 2009, committed to civic hacking, celebrating the spirit I described around the Obama administration earlier in this introduction. From 2013 to 2014, she served as the US Deputy Chief Technology Officer and helped found the United States Digital Service. The USDS brought top technology innovators into government to work on high impact projects epitomizing her belief in government by the people for for the people in the digital age. Vast Company has named her one of the hundred most creative people in business and the Skoll foundation has given her the Skoll Award for Social entrepreneurship. I hope you enjoy the conversation. Jennifer, thank you so much. First for the book, maybe even more for than for the book for the work. But the insight that it brings to everybody and it's triggered a bunch of thoughts in me and I hope we can talk through some of them today. But the real reason it was important to include your book in the series that this season is to begin to get real about the capacity of government to actually deliver. And that's obviously what you've been at the in the middle of for a long time. But the book starts off at the beginning, setting out the objective to understand how we get between policy and actually being able to deliver and then unpacking layers of the problem that make it so that the actual systems of government now don't actually seem to deliver in so many different contexts. And the first and the most obvious layer, which ultimately is not, it seems in your view the most important that people would grab onto is just the idea that the technology is so old that COBOL is a programming language or in the IRS assembly code is still used. And obviously that's an important part, but it's not the most important part. It's a more fundamental philosophical management approach that you diagnose is at the center of so much that's troubled about technology and government. Is that a fair way of characterizing it?

Yes, absolutely. I mean it's understandable because it is websites and apps through which we so often now interact with government that that's what we think the problem is because they don't work well. And that can mean a lot of different things. It can mean that they literally aren't up. It can mean that IT process takes 212 questions to get through an online application form. It can mean a lot of different things.

Things.

But ultimately the reasons why that technology doesn't work as well for people as it should have to do with fundamental problems with government. So I think for me, I happened to work in and around tech and so tech became a lens through which to see some deeper capacity problems in government. And I think not just capacity problems, but capacity that stems from some ways of thinking and the culture of government that really needs to change. So if we go straight at the tech problems, we just get stuck. And that's where we've been for so long, it's just, oh, the tech's bad, let's fix the tech. And we've got to look a little deeper, I think.

Right. So one really instructive example of failure that you describe is something you were in the middle of trying to deal with the unemployment assistance during COVID And you describe this extraordinary context of an incredible backlog of these applications, one and a half million backlog of these applications. And the legislature and all the politicians are demanding that something be done. And so they say you have to hire more people. And your tech team or the team you're working with is able to demonstrate the. Because of the complexity of the system, hiring more people is actually slowing down the ability to process this backlog because the system is so complicated, the new people can't deal with it. So the new people are asking questions to the older, the people who've been around longer. And so the people who've been around longer are spending all their time answering questions to the new people. And so the total output of the system goes down. And you describe this incredible moment where you've been able to demonstrate this, prove it really, and you bring it to management and you say, here, see, it's really hurting you to hire new people. And the response you get from it was, well, there's nothing I can do about that. I have to hire new people because everybody is telling me I have to hire new people. You say, quote, the optics, as they say, would be terrible if we were to say we're not going to hire new people. And so they continue to hire new people and continue to make it so they can't even do what they need do to, to do. And you say, really succinctly, capturing the whole of this section. She was stuck in a waterfall. So what do you mean by waterfall? And how are waterfalls a good way to understand what the problem with government technology is right now?

I think the key thing about a waterfall in this regard is that water only goes one way. Nothing goes back up the waterfall. When tech people hear me say that they think waterfall software development, it's correct that I think waterfall software development doesn't really help us much in government and is the source of some pain and grief. But I'm not really talking about just the use of that alternate methodology, agile user centered development. I'm talking about waterfall as a metaphor for how power and insights and information flow in government. I think people who haven't worked in government sometimes have trouble even believing that she would have reacted that way. Said, I can't do anything with this information. But a lot of people who've worked in government have said, oh, my gosh, that so rings true. It really resonates with experiences I've had. But it is. Clay Shirky had that line. Waterfall is a pledge by all parties not to learn anything doing the actual work. And yes, I understand why. Politically, it looked too bad for her to tell the people who had been promising to the people of California and the press that hiring all these people was the solution. You know, you can imagine why she doesn't want to tell people with far more power and more at stake politically than she has that they were wrong, that that has not been the right solution. And strangely, of course, you know, we were able to say it just fine. You know, we have this weird position sort of wrapped side the waterfall. We have explicitly been given permission to break the waterfall. That's why they send us in. I'm no tech genius, trust me. It's. You know, and my colleagues, they have fantastic analytical skills, and all I had was the permission to tell people something they didn't want to hear. But it's exactly like Clay said, when you all agree to participate in a system in which power and insights only flow one way. When you learn something, even if it's the thing that can solve the problem that you're supposed to be solving, it is not welcome. Or you have to sort of create an alternate structure in which to get that information back up. And it doesn't serve anybody because it means that we can't solve the problems that we've set out to solve.

Right. So to fill out the metaphor, the basic structure which you're describing with waterfall is every. There's a kind of hierarchy of decisions. People at the very top make a policy decision. Maybe they pass a law. This is what's supposed to happen. And. And they pass it down one level to a new layer of what has to happen, and then they pass it down one level to a new layer of what's supposed to happen. And the assumption is that from the very top all the way to the bottom, you can fill out the details of what's gonna have to happen and kind of put it together as a manual and then hand it off, and then they will implement. But as anybody with any familiarity with complex technical systems realize, there's no way to build like that. Anything that builds like that is obviously gonna build something that's going to break or not be able to deliver. You have this amazing point earlier in the book where you're talking about A state technology director who has been in development for 12 years of this particular program that they were going to release to vendors to bid with a $600 million price tag. And you told her you didn't think it was, you thought it was likely to fail. And she responds, quote, do you think we don't know that the last seven IT projects in this state have all failed? Failed. Because this vision of mapping it all out, putting a huge price tag on it, bidding it out, is just inevitably going to crash on the rocks when the reality of the inability to envision everything is realized. And so the waterfall metaphor is just suggesting that when you build it like this, there's no way to go back up, there's no way to iterate, there's no way to figure out how to develop it in a way that's getting you what you want. And so by contrast to this waterfall metaphor, you have the. The concept which is overused, or the word is overused is agile development. If we have waterfall on one side, what would agile on the other side look like?

I should be clear. I don't particularly care if people call it agile development or which brand of it they use, or even if they're using anything at all. I'm more talking about a way of developing software that follows more of a build, measure, learn cycle. You're having a constant feedback loop from the people writing the law policy and the people implementing them and everyone in between where we get to iterate using all of those stakeholders and all of the insights and abilities that they have. I think the most key part of agile development certainly is that you can change over time. They say we welcome new requirements at any phase. You're learning as you go, but what's often not captured in agile because people think of it as the trappings of agile software development for things like standups or feature backlogs and things like that. I think the most important thing really is that the user is there all along. We've created a system for developing technology in government in which there are many, many, many stakeholders, mostly internal stakeholders, sometimes advocacy groups, but the person or different sets of people who are actually going to use the software never see it, never get to play with it, never are really. Their needs are not really considered at all until maybe, maybe at the very end of the process. In some ways, it's user centered iterative development that I'm really talking about when I say agile. It just so happens that various brands of what get called agile development in the tech industry incorporate those and make those Front and center, but there's a million kinds of them. I think a lot of times people in government hear me say that, and they think she's calling for a very specific methodology, and I'm calling for actually a set of principles and a different way of thinking.

Yeah. And you can see how the waterfall metaphor leads everybody at every stage in the waterfall to try to fill out as much as they can, because they kind of notice the train is leaving. If they don't get this requirement now, they're never going to get a chance to get this requirement which leads to these overly complicated projects which can't begin to deliver everything they're trying to deliver. You dub a new law, Burns Law, after Mike Byrne, who was at the FCC and he built a broadband map for the fcc, a really extraordinary project you described. But he says the estimates that most government tech projects could cost 10% of what they do and still provide 85% of the functionality. That's a consequence of the fact that everybody at each stage thinks, I got to get my stuff in now, and if I don't, it's never going to appear because it's only one way. But if you had what you're describing, agile or whatever the word is that we had, you could imagine trying to get the 85% the first time around. Let's deal with the core cases, and then each iteration we can extend to more and more of the edge cases so that we could eventually get to the place where we're getting 100%. But at least we would have had four or five years of getting 85% in a really effective way. And you only get to that ability to develop in that way if you imagine building in this iterative process.

Right, Absolutely. You also have to account for what, again, it's a tech term, and it doesn't really matter what you call it, but the role in tech is a product manager. And product manager is different from project manager in that product. Project management is getting the art of getting things done. It's incredibly important. We have some amazing product manager, sorry, project managers in government, but product management is the art of deciding what to do. So when Mike Burns says, let's do 85% of this, it'll take 10% of the cost and 10% of the time he's saying, let's choose these things. They are more important than the others. And if we get them right, then we can build on what we've gotten. Right. And the problem with that is, again, back to this waterfall. It's not just that Information only flows one way. It's that power only flows one way. And so there's this idea that the people doing the technology development who are at the bottom of the waterfall aren't really supposed to be exercising judgment. They're supposed to be sensitive, some objective set of requirements that simply must be met and we should meet all of them. And that's the job of these low level people who do technology development. Just do everything that the person doing the requirements development has set out. And to say that Mike Byrne or any other leader in government would exercise their judgment to say, actually we're just going to start with these things is sort of heretical if you assume that those people shouldn't use their judgment.

Right, okay, so I thought I'd go a different way. But now I want to make sure we build on this point because it's really fundamental and really one of the most interesting, I guess, legal philosophical points that come for me out of the book. So you describe this incredible woman you named Natalie, and she's at the Centers for Medicare and Medicare Services, cms. And she's doing amazing work, but she's facing, you describe a couple of times she faces a struggle. And the struggle is the law seems to order one thing. It seems to order a Facebook for doctors. And it makes no sense that you would deploy a Facebook for doctors, at least in the first round, at least given the deadlines that need to happen. She's constantly struggling back with lawyers and with everybody else about whether they can just develop it in this way or develop an alternative or just do a part of it and not all of it. And the answer the lawyers are constantly giving is no, this is what the law requires. As if you didn't do in the code what the law requires, you violated the law. For me, it's a weird way to frame it, because when my work 25 years ago, trying to get us to think about the way code is, in a sense, law code plays the role of law. That would seem to be consistent with this intuition. But when I was reading about these lawyers, I felt embarrassed as a lawyer, because there are all sorts of contexts where we imagine the law giving an administrator extraordinary discretion. So the law will say to a police chief, we want you to make sure that nobody is raped, including people who are raped for, you know, because of their gender orientation or anything like that. And we have a complete standard of equality. But nobody would doubt that that police chief is allowed to make judgments about exactly which to do first or where to police more carefully, or how to and if you said, well, you're not doing what the law says, precisely, it would be a kind of, it would show your ignorance about the way administration works. Yes, of course, there's a place policy judgment in the question of implementing the law. And it's striking to me that it, that it seems to take so much to try to get lawyers inside of the administration to realize that what the coders are doing is a policy judgment. And it inherently has these kinds of trade offs. And if you don't allow them that type of latitude, then just like an order to a police department that you must arrest everybody who does X, Y or Z would destroy police enforcement. So too is that what would happen in code development, but in all of the work that you saw, is it kind of an increasing recognition or would you predict that still you would have the lawyers inside the administration saying, here's what the regs say, so here's what the code must do?

Well, in that story with Natalie, where she eventually does get to skirt this supposed requirement for Facebook for doctors, it is ultimately that she finds a different lawyer who will help interpret this regulation a little bit more freely. Now, if you go back and look at the actual law, I mean, I tell the story of her going back to Congress and saying, did you intend this? And they're like, are you crazy? Why would we require that? But there are all these layers of miscommunication in the way that we take when we go from law and policy down to implementation. It's the very maximalist, literalist interpretation of law and policy through those layers into the regulation and then the requirements and the specifications. That's what gets us into trouble. Some lawyer somewhere had decided that this requirement, or it's a provision in the law to allow doctors and Medicare to find each other across state borders and potentially file as a medical group. I think your listeners will get the general gist of this. Right. Someone's interpreted that not as we need to allow them to do that, but we need to build a piece of technology that will enable them doing that. That's where the interpretation came in. And it's so common to see this where someone's gone, let's go to the absolute maximalist interpretation and insist on that. When of course, that's not what was even meant by the people writing the law.

And yes, you're right. And what's striking about her vigorously pursuing this was she was looking for every lawyer, like excuse for not doing what the interpretation said that she should do. But I'm trying to push for something Bigger. What I'm saying is the very idea that you interpret these regulations in that literal way, as if the law itself were the code, is a misunderstanding of the nature of law. Like, just as with a police administrator, no one would expect that a law that says you need to police for sexual violence means a particular set of things. Instead, we understand what it means is that the police chief has to decide how to allocate resources to achieve that point. There seems here too to be a need to recognize that this translation from regulations to code is inherently a translation of judgment. It's not an automatic translation. It's a translation that is constantly reflecting on what is the purpose, what's the reason why, what's the objective, what are we trying to do? And that if you don't give that power to the code implementers, then obviously you're going to run against these crazy consequences of wasting extraordinary money. If you'd built Facebook for doctors, nobody would have used it, and yet you would have stopped the development of an extraordinary range of other important code. So it's more fundamental. It is inherent in the nature of the translation. There has to be be this discretion, not a discretion that's earned by being able to go to a congressperson who says, yes, it's crazy. We never intended this.

I completely agree. And I think that there's two points there. One is, are you enabling folks to have that discretion? And I'd like to return to the story of Yadira Sanchez at the end of the book, taking that discretion, just empowering her herself in ways in stark contrast to some of the earlier stories. But there's also the issue, I think, of people not wanting that discretion. And I tell the story earlier in the book of this leader at the Veterans Administration, actually the Department of Veterans affairs, who is responsible for a system that is not working very well. And I'm questioning him about why was it built this way, why was it built that way? The same kinds of questions that you would ask a product manager who's made some judgment calls about what it would do and what would be prioritized. And he keeps saying, oh, that wasn't my call. You're going to have to ask the program people, you're going to have to ask the procurement people. I finally press him on the point, and he says, I've spent my entire career teaching my people, people not to have an opinion on the business requirements. And I. He says, you know, if they ask us to build a concrete boat, we'll build a concrete boat.

Right? And you said, immediately after that, I was proudly. He was proudly abdicating responsibility in order to avoid blame. It was a gut punch.

Yeah, exactly. It was a gut punch because this was to witness early 2014. We were talking about, you know, veterans benefits, and at the time, I think 16 veterans a day were committing suicide, most of them without access to their benefits. And that's what I thought we were there for. And he said to me, you know, I don't want them to have an opinion because that way, when it doesn't work, it's not our fault. So I don't want to demonize that man. He is working inside a system that strongly incentivizes him to behave that way. And so even if you are given some degree of judgment and leeway to do what you think is the right thing for a lot of people, that comes with a lot of risk. And that's because of this accountability trap where public servants, when things go wrong, you know, we think we're holding them accountable to outcomes because that's what happens. That's what you see. And the legislative hearings and the news reports as we're yelling at you about healthcare.gov not working or the UI backlogs or whatever it is, but in their jobs, if they're going to get promoted, what actually matters to them is whether they've complied with various already established policies and procedures, or if there wasn't a policy and procedure, did they put one in place. That's what the whole oversight apparatus looks for. That's what their careers depend on. And so we can't really be. I don't think we should be too upset with Kevin, though. Obviously I was upset at the time. Until we recognize that this accountability trap and try to do something about it, because it will continue to drive that behavior of, no, no, please don't give me any discretion. That's risk for me. It should not be so risky for someone to have an opinion on the business requirements in such a way that actually gets veterans their benefits.

Right. Because, okay, so these are the two sides that lead to the status quo. One side is people like Natalie who are pushing to try to bend what seems to be the explicit order in order to achieve what it seems is obvious that the regulation is trying to accomplish. And the other side is somebody like Kevin who likes the fact that they're just orders because he knows he's not going to get in trouble if he just follows orders. Both of those are two sides of the same coin. It's about a system that is characterizing these orders as if they are orders in the sense of, to a private in a command in the middle of war, as opposed to, opposed to a ambassador cut off from the home country where you're saying, you know, your objective is to make sure peace is achieved and we're not going to be within radio contact for the next six months, so do that, just make sure that happens. And what I'm suggesting is there needs to be a different conception of what the law is doing to the code here that would make it possible for the system to attract the kind of people who should be rewarded based on their creative adaptation to, to make the system work, and who would want to work in a place where they had the obligation or the opportunity to be creative in making sure the system works. I mean, those two things would be necessary to change it. But that requires in some sense the lawyers to step back and stop speaking as if what they're saying is truth when they say these are orders that have to be obeyed as orders. That's just a mistake. The other part of this that's so fascinating to the story is obviously in product development in the private sector, an extraordinary amount of time is spent watching how users actually use the product and then adjusting the product on the basis of that use, gathering tons of data from the users and doing stuff with it. You describe how this is both not the process because of a waterfall problem, but even more because of a rule problem. You describe these laws, which are almost jokes in the way that their title declares them to be, but the Paperwork Protection act, comically misnamed Paperwork reduction Act of 1980, which it along with other things, make it incredibly difficult for, even if you had agile developers to spend their time trying to understand what the public actually would be doing with the product as a way to make it easier to develop in a product like way. Tell us about how that interacted with this.

The Paperwork Reduction act is designed to reduce the burden on the public. It says the government shouldn't be able to put out all sorts of different forms that we have to fill out. For instance, like we know we're going to have to do tax form, but let's run everything through the Office of Information and Regulatory affairs in the White House. And so that'll create some friction for agencies and they won't be able to burden the public with all these information requests. And that's all well and good, except the devil's in the details. So essentially, the way that you make consumer technology easy for people to use is you put it in front of users from the Very beginning. You watch users use something and see where they get stuck. You see that they don't actually know what that button means. And that kind of user research should be happening all the time, but because it is in a very micro way, also asking something of the public. Once again, you see this maximalist interpretation of the law. And so OIRA basically said, you're going to have to approve any user research through us. Well, I don't think that's what the authors of the bill intended. And I also don't think they imagined a world in which everything would get done through digital means and you would need massive amounts of user research going on all the time. So I seriously doubt that they intended to have this stuff go through. But if you think, think about it, that's one office in the White House for the entire federal government. So it takes nine months to a year to get something through. Now it used to, now it's a little bit better, but still you have all of this apparatus. Like the agency has to put up this whole package. It can take months. And then they send it up to IRA and it gets approved really quickly. It's taken months to get approval for something. Oftentimes it doesn't get approval. They post it to the Federal Register and ask for public input, input on a plan to get input from the public. And sort of nothing happens. Making the burden on users even higher because we're not user testing this stuff. It's a really chilling effect on user research across the federal government. Oftentimes agencies just won't do it because they can't afford that time. And so it's had a really perverse effect. It's sort of this idea of culture eats the policy. The policy says one thing. The impact of the policy is the exact opposite of that, because through all those layers as it's descended to actually get implemented, everyone's taken a maximalist approach and now it's having the opposite impact.

And do you think that when the interpretation from OIRA was made, there was any sense of the consequence for the ability to develop technology that would actually be usable by the millions of Americans who depend on it? Or was it just here's what the law seems to say and here's a simple application of it. So that's what we're going to deem the rule that the government must follow.

There's a lot, I mean, I don't know. I wasn't around for that, but I can somewhat pattern match. I think generally public servants are trying to do the most thorough job they can. They want to be good. They want to do it all right. They don't want to miss the dotting an I or crossing a T. In fact, if you read the paperwork Reduction act, it has an exclusion in there for what sounds like user research. We've had three consecutive presidential administrations issue memos saying this stuff is essentially excluded. But you have this. Whenever there's any degree of uncertainty, the safe thing to do is run it through anyway. Because lord forbid you do user research and someone else says, hey, that should have been run through oira. It wasn't. What you're doing is illegal. You get told that in government a lot. What you're doing is illegal. You could go to jail. I could go to jail for doing user research. That seems strange. And so the default will always be towards, again, the maximalist interpretation. And that is a cultural issue that perverts. That perverts policy. But I mean, I talked to folks at OIRA today and there's a lot to that conversation and they're very well intentioned people and they are trying to solve the problem. I don't think what they're doing is solving it well, but what they tell me sometimes is, well, we have clarified to the agencies that they don't have to send it up. So if they're still sending it up to us, it's not our fault. You know, I do think ultimately you have to have a lot of stakeholders come together and say, no, no, no, we really mean it. You really shouldn't send us this stuff. And I, as the central agency, I sit in the White House. It's a very powerful place. Yeah, you kind of do need to take responsibility for agency behavior, even if they're being unnecessarily risk averse. But that's the problem. And it gets back to what you said earlier, Larry, about, yeah, what do we really think law is and are we fundamentally misunderstanding it? I think the corollary to that is what do people who write law think their job is? Because I was just in Sacramento the other day visiting state legislators and it was even more visible there than it is at the federal level. They think their job is to write bills, introduce them and get them passed and it kind of ends there. Like they don't really follow up. In fact, I felt like in that day when I talked to half a dozen legislators about half different things, mostly they were telling me about laws, bills that they were either introducing or trying to get past that really just required something that was already required. Like, that's the problem that you are addressing with that bill is not a problem of law, it's a problem of implementation. And I do think that lawmakers have more than just legislation as their toolkit. They have oversight, they have hearings, they have communication with agencies. There's all these things that they could be doing to get those the previous laws implemented. And also I think to take care of the civil service, like the health and well being of the civil service is how their laws have impact and they completely neglect that. It's as if you had a gardener who only ever thought about planting seeds in the soil and expected the soil to return these beautiful plants, but never fertilized or watered the soil. So I think there's just gotta be a fundamental rethinking of what it is we expect lawmakers to do and on both sides.

Because I think that part of what you're describing is the way the civil service doesn't think of themselves as partners with the legislators. Yeah, I mean, you know, if they thought of them as partners like you have, there's a great image where Thomas Edison draws the phonograph for his assistant, who's a Polish guy named Cloycy or something like that. And you look at the drawing and you can't begin to understand what that drawing is. But his assistant is really good at interpreting that drawing and turning it into the phonograph. And that's the relationship, in some sense you want to have between the administration and the legislators. Legislators are busy, they're politicians. But they give a pretty clear signal of what they're trying to accomplish. And somehow the civil service has got to feel empowered to exercise their judgment in their product management as you're describing. And it's striking how that seems so rare. Now you describe a couple of really inspirational cases. One everybody will be familiar with, which is the COVID test case. But there's another, which I want to start with, which is food stamps. In I think it's California, this example comes from where the process for getting food stamps is extremely complicated. There's no effective mobile technology for can take so long that nobody could even at a library have time to fill it out, whatever. But then a different team that you're describing here develops a very simple implementation going from hundreds to four questions. And in order to comply with the law, at the end of the four questions, when you hit submit, it has to fire up a fax machine which faxes the application to the administration. But in this demonstration, they showed how a very simple, agile, effective team can deliver a product which is hundreds of times Better than this old waterfall like structure here. And that of course isn't the end of the story because obviously they continue to develop it and make it much more effective. But the objective of making the technology in a way that's directly responsive to the consumers is something that you describe in this really fantastic way in the book, is spreading through government in hopeful and inspiring ways. And Covid was just one place that you saw it most directly. So tell the story of the COVID test, which is, I think for all of us, the one place we saw government work and kind of were amazed that it did.

Yeah, the team that did Covid test.gov was also a lot of the same people who had helped get healthcare.gov back on track. And in some ways I think that it's a different agency, but they're sort of saying, look how it can be. So if you used Covid test.gov, it came out right at the beginning of the Biden administration. Go back in time a little bit. Normally what would happen is that an administration would announce something like that and then go talk to the people who would need to implement it. But in this case they talked to them before they announced it and the team said, look, if you want this to work, you've got to keep it simple. We can't ask a million questions. It's going to matter that it's accessible, it's going to matter that it's scalable, it's going to matter that we launch in different languages. And so they made the trade offs, they did the product management, sorry to use that term again, to say this is what's important and we're choosing all those characteristics. Over a thousand different features. They could have asked for size of household, they could have asked for vaccination status, they could have asked for your insurance and for information and they chose not to. And of course it worked beautifully. There was one problem with it that turned into a great opportunity to learn and fix a longer term problem. That was the issue of. Yeah, it was. Turns out that the database doesn't necessarily know every house that used to be a single residence and it's become a multi unit building. And so some of those people were sort of boxed out because that address had already been taken up. But it was just a data cleaning. And so they recovered very quickly. They provided a way for people in apartments that had this particular problem, very, very small subset of people to bypass the system, get their tests anyway and then clean the data so that the USPS database is now actually much more accurate. Because of it. And it was just all the different decisions that were made up front before anything was ever, you know, before a line of code was ever written, before a spec was ever published. And it just. It just could. It wasn't like a lot of people think, oh, they had better programmers or something. No, it's. They made different decisions about what was important. And you had implementers in conversation with lawmakers and leaders from day zero. That's it.

And the culture of that interaction, I think your book makes clear, is critical, because if they don't feel, in some sense, equally empowered, everybody at the same table, everybody having an equal voice to contribute, then this kind of development becomes really hard. And this idea, the book describes how it's taken forever to advance this idea. When I published my book, first book, Code into the Laws of Cyberspace, I gave a speech in France about it for the. For the Bar Association. And I had lunch sitting next to the chair of the Bar association. And I gave him my card. He just heard my speech, and he took it and he crumbled it up and he threw it on the ground and he said, I am not a technician, I am a lawyer. Right. So this idea that if you. If you bring these things too close together, it insults. But if you get over that and you kind of understand how they both can sit together, then you have this capacity, this potential to deliver in a way which we don't see government delivering right now. And that relates to another point which is central to the book, which is the need to build capacity inside of institutions. Not necessarily people who are going to write the frontline code, but people who are familiar enough, people like you, who are familiar, familiar enough with the code and the architecture of technology to be able to speak meaningfully about this translation, how to carry the ideas of the law over into implementation, and how implementation can help you understand better how to carry the laws into effect. And this brings me to what I'm anxious is a stumbling block to the enterprise which you try to launch us on, the enterprise of reforming government here. And it's the stumbling block which has been at the center of my work, because I'm worrying about the corruption of our government. You talk about in your chapter, what We Believe Matters. You talk about a memo that came out beginning, I think, of the Trump administration, where they were resisting this new way of thinking about technology and government, that the idea that you have in House government IT departments in some sense was a mistake. It was a violation of Ronald Reagan or something like that, and that what we should be doing is just having complete outsourcing to companies like Oracle. And you put it quite powerfully. You say, if our goal was to maximize Oracle's profits from its public sector business, this memo's advice would be helpful. But contrary to that, the point you're trying to make is that this way of running technology in our government actually destroys the public sector capacity of our government and that we've hollowed it out over the last 50 years by forcing all of this into the private sector. But it's no accident because the private sector profits enormously from this being outsourced completely to the private sector, even if the thing they can produce is nothing close to to what we actually want to produce. So when you stand back and you say, like, what are the three things that would have to change to make the kinds of government that you want possible? It seems one thing which is not really at the center of what you're writing about would just be the capacity of money to distort the process for deciding what makes most sense here. Right. Because without that going away, you're going to see a lot of Oracle like influence in these decisions.

I completely agree, they have a fantastic lobbying capacity there in Oracle, but I will say they're kind of losing. I think they're losing because it's just so obvious how wrong they are. The sad thing is, I have nothing against the vendors and I believe strongly in outsourcing, but we have this idea of opex or over capex, which means of course you're going to use capital expense, you know, big contracts, you're going to use money to hire vendors to do work for you in government, but you should spend that capex when you have the appropriate opex. In other words, when you have the right internal capacity, not only can you hire the right vendor, but much more importantly, you're hiring a vendor to do something you have decided is the right thing. And the people inside know what it is they're trying to get. There's a concept you hear a lot in government. We're hiring a vendor to have one throat to choke. It's exactly what that guy Kevin, it's not his real name, said to me. Like, I just, we don't want to have an opinion on the business requirements. It's all someone else's call. And that way it's not our fault. What works well is when you have people inside who say, we understand the problem, we think we know what the product is, we're going to learn along the way, and we have a vendor as A partner. But Those are not 600 million $2 billion projects. They're 20, 30, $40 million projects. I see fantastic vendors delivering great results for projects in the that size because they've done a really good job. Well, they and the government client have done a really good job defining what the product is and defining processes that allow them to learn along the way. So I'm not anti vendor at all. I'm anti abdication of responsibility. I'm anti one throat to choke. And it's sad because companies like Oracle could have a fantastic business doing that kind of work. They just prefer the $2 billion projects and nobody else prefers them. The government clients hate them, the American public hates them. And the sad thing is the people who work at Oracle hate them.

Everybody hates them.

They want to work on something meaningful and successful too.

You tell a great story about when one agency changed their method instead of going from the big hundred million dollar projects one for the more piecemeal projects. And one of the companies that lost from that came in and thanked them for changing the standard because they too thought it would be better to develop software like that and they wanted to be that kind of company that would do that.

Yep.

Okay. Now, when we first. When I saw you for the first time in many, many years, I think I saw you at the launch of Code for America, which was except extraordinary, but that was 2009, so it's been many years since I saw you. It's been a while we had a conversation and you terrified me because you made me realize just how precarious one of the most important bills in the past 50 years is. And that's the Inflation Reduction act or most importantly, the climate crisis component of the Inflation Reduction Act. And the reason why you terrified me was as you were talking about it, the critical part to that act is to build infrastructure to allow the implementation of a wide range of incredibly ambitious but complicated incentives that can only work if there's some infrastructure in the government for making it work. And your concern at the time we spoke about four months ago or so was that there wouldn't be such infrastructure structure or there wasn't, or it was taking a lot to build it. Should we be worried here or what's happening and what's hopeful and what still needs to be shaken up?

Well, I think we're coming along. I would not yet put aside any fears. I think we need to be pretty vigilant about it. I think it's important to think about it in two different ways. It's who do we have on the inside to do the job? Are they the right people to do the job? This job? Do we have just enough of that? But even more importantly in some ways is how much are we burdening that job with a thousand more requirements? And we're burdening the people inside and we're burdening the private sector partners that are supposed to deliver on most of this stuff. I'm definitely a fan of what, well, a critic, I suppose, of what Ezra Klein calls everything bagel liberalism. He's talking about it in certain contexts, I talk about it in other contexts, but it's essentially the same thing. I mean, if you've got three years of compliance work to do before you can stand up a website to administer a rebate, for instance, for your people to install their heat pumps, you can either say, we need a lot more people to get us through that three years of work, which by the way, isn't going to shorten three years, is just going to be able to get. Or you can say we need more people, but most importantly, let's get rid of some of these requirements so that this can happen a lot more quickly. We have burdened everything with too much. And I know I sound like libertarian when I say that, but I think I have. Well, I think my politics are a bit complicated right now, but I think I come from a place of deep belief in government's ability to do good and the necessity to of government having the capacity it needs in order to face the challenges of the moment. So I'm not trying to get rid of things for the sake of getting rid of things. I'm not trying to get rid of things to make things easier on Oracle, for Lord's sake. I'm trying to tackle a problem of too much kludge, too much cruft and not enough people to do it. And we've got to work on both sides of that equation. Oftentimes because of the nature of the work, which is like getting through all the kludge, we hire more administrators and yes, of course, more lawyers and more compliance people. And we don't hire the people who would say, think about how to make that rebate system usable, like rebates to the public. If it's a consumer facing part, that's only part of the ira, right? A lot of it happens in industry. But the part of the IRA that's like, I'm going to be inspired to go put some solar on my roof and a heat pump behind my house because there's a great incentive for it that only Works if like I, the average person feel like I understand that program, I'm going to be able to get through the process. I'm actually going to get the rebate after I spend all that money. Like all those things have to do with usability and understanding user needs and streamlining, creating process that make sense to people. And that's a capacity that like we just don't tend to employ people in government with that skill. So it's not just how many people you have, it's what skills do you have, what do they know how to do, can they do it? And then are they overburdened with a million different compliance frameworks.

So if there were something like the police chief in this story who was allowed to make the trade offs and say, okay, yes, I agree, these 14 things have to be in the product, but they're not going to be in Rev 1 of the product, they're going to be in Rev 4 of the product. And that he or she felt empowered to make that judgment. And no lawyer was going to come in and say you're going to go to jail for this. That would be one structural change that would make it easier for this kind of development to occur. And the mix of feedback and technical abilities would be another component to it. But when you say you're optimistic in the context of ira, does that mean you see more of IRA being implemented in this way? Are the lessons that you write about in your book actually manifesting themselves in the new entities that are trying to bring IRA into existence?

We still have a long way to go. I mean there's so many actors responsible for so many different things on the state level with the, the rebates. It's still an open question. And I mean I can't personally track 50 states implementations of rebate programs. Organizations like Rewiring America are, thank goodness the need to make these things usable is just coming up more and more and I think that's a good sign. But it doesn't mean we're getting there. On the industrial side, we are seeing indications that more people are going to take advantage of some of the try to take advantage of these incentives. I just not ready to rest until we see some of these things get all the way through the process. I mean I kind of think about this in relation to the criminal records expungement program we did at Code for America. The law said if you have a marijuana conviction and marijuana is no longer a crime, that record can get, you know, that conviction can come off your record. And so we Saw some people start that process, but you have to follow it through and see if anybody gets all the way through the process. And at the end, you know, by the year after Prop 64, the Adult Use of Marijuana act had passed in California. I'm sorry, we're particularly looking at San Francisco. 23 people had started it because it's so hard to even know where to begin. Zero had gotten through. And so I want to see the throughput of the system, not how many. I mean, that was very low number of people starting, given that there were something like 10,000 people in San Francisco eligible. But we need to be tracking, not like who has expressed interest, who's applied for a grant, but are these things being built and when. We're so happy to celebrate at all of these early indicators without actually following all the way through.

So is someone building the infrastructure to do that tracking?

I again would point you at Rewiring America, especially for the consumer side of it and a lot of industry groups. There's another one, Institute for Progress is following it as well on the industrial side. And I think they all remain concerned, but happy that there is increasing dialogue about the need to implement this law, not just celebrate its passage.

Okay, so final, final questions. You've had an extraordinary range of experience. You started Code for America. You went into the Obama administration deputy cto. You helped set into motion the United States Digital Services, which is kind of committed to this whole mode of finding new ways to develop technology inside of our government to make it work. Imagine you are appointed the czar, the code czar for America, and you had the power to just make three changes and only three changes that would bring about the incentives. Because you, as I think you rightly put it, what we need to find, focus on, is the incentives that people live within to produce the kind of code or the kind of services that we want. You could change three things. What would be the three things that you think we should change to bring about a technology, an infrastructure for delivering service that would match the capacity of the private companies to do what they're doing right now?

This is where all the listeners are waiting for me to say procurement. And I'm not going to say that in part because I think my concept of culture eats policy. I think you're going to make policy changes to procurement that will inevitably be eaten by the culture. So my three answers to that I should preface by saying I think these are largely changes in behavior that don't require changes to policy or law, but are very difficult and require a lot of bottom up analysis and understanding of people's incentives within a bureaucracy. I would fix hiring and by fix because that can mean a lot of different things. And also I don't honestly believe anything ever gets fixed. I think things are not problems to be solved, but conditions to be managed. But I would work to reduce the time to hire and increase the use of assessments in hiring at all levels. But starting with the federal level. It's crazy that we've asked agencies to digest IRA chips and infrastructure, three gigantic acts and still takes so long to hire even one person. There's some great work that's already moving to fix that. So I would just be. I would be trying to accelerate and spread the work of the USDS team that's worked on something called smeqa. Subject matter expertise, qualifying assessments. There needs to be many other processes like that that work within existing law and policy, but reimagine the process consistent with that law and policy, but much more in line with the intent of that, which is fast meritorious hiring that gets government what it needs. Second, I would reimagine funding so that we can do that operational expense first and capital expense only when we have the operational expense settled. Less big bang funding enable iterative user centered projects and not just in tech everywhere. We need to be much more iterative in our funding of things to put money where we're learning how to do it right. And then third, oversight. There's so many places for oversight in the agencies. In the legislative branch. Most oversight today focuses so much on the compliance with this maximalist interpretations of law that are looking at these policies and procedures that turn out to be somewhat arbitrary. You can come up with lots of different policies and procedures that get at that law. But when we focus on that in oversight, we increase risk aversion. I believe there's a version of oversight that elevates the public servants who are using their judgment and getting the job done. Instead of those like Kevin who are building the concrete boats but are safe because they checked all the boxes. And I really want to engage leadership in sort of imagining what would oversight that really did the job we wanted it to do look like.

I would vote for all three of those exactly in that order. That would be amazing to imagine. And it's critical to build, especially in context like the ira, but also in practically everything the government is doing. And critical also for those who believe there is a role for government. I mean, here's where the cynical story closes the account. There's a part of our political world that's happy when people have no faith in government because that means they don't want to pay for government. That means they don't want to support government. That means taxes can be lower and the like. The only way to get over that is to have government that actually is able to accomplish something. And your book so beautifully shows us this blockage and those magical moments when it breaks through and you can see how people react in ecstatic ways to the idea of their government actually doing something. Reaction to the code, the COVID test, I think, is a perfect example of that. And if we don't find more examples of that, if we don't spread that, then faith in the capacity of government won't restored, won't be restored. And there are so many problems that we need government to solve that just won't get addressed. Jennifer, again, thank you for your work, for the book, for taking time to talk about it, and I'm extremely eager to see many more people talking about it and taking up the ideas because it would make government work.

Thank you, Larry. It's been a delight to talk to you and you've been an inspiration to me since that conversation in 2009. So thank you too.

All right, thank you.

Take care.

This has been the 17th episode of the fifth season of the podcast Another Way. These podcasts are produced by Equal Citizens. They are produced literally by Josh Elstrow of Elstro Productions. Check us out at Equal Citizens Us. Give us your feedback. I love the feedback, especially the ideas. And help us spread this podcast to everyone you think should hear these words. And of course, help us support these podcasts, which are of course free in the free speech and free beer sense of the word. But you can always chip in for some free beer. And this is the chip in we need because I don't ever charge for my work at Equal Citizens, but there are people we employ who need to earn a living. And so everything you donate helps us keep Equal Citizens and the work that it does going. Thanks again for listening. Stay tuned for that next episode.