Recoding America: Why Government Is Failing in the Digital Age and How We Can Do Better by Jennifer Pahlka
My rating: 5 of 5 stars
I have been intrigued by recent writing (and podcasting) by Ezra Klein on the lack of effectiveness in government, and how we “need a liberalism that builds.” In reading and listening to Klein I was struck by how powerful his arguments were, and how much of his writing on the subject was and is recognizable. I wrote a blog piece on it, and Klein has resumed this conversation through his New York Times column. In listening to the Klein podcast I listened to Klein interview Jennifer Pahlka, the author of a new book “[Re] Coding America.” Klein described the book as one that he hoped that “all policymakers would read.” He hooked me, and after reading it I agree. This is a book that policy makers should read.
Pahlka has served as the Deputy Chief Technology Officer of the United States, and is the founder of Code for America, a non-profit that assists government in formulating workable technology solutions.
Pahlka, in writing this book, really does not pull many punches. She gives us examples of notable government technology failures, and talks about, in great specificity, why these failures occurred. In identifying the failures and why these failures occurred Pahlka, in my view, manages to get well beyond technology issues to fundamental issues of management, and how we make policy. While this book is centered on technology the management lessons imparted extend well beyond technology issues. I do believe that the obvious connection Klein makes to his policy complaints from the “We Need a Liberalism That Builds” series of writings and podcasts are indeed reflected in this book. And they are unquestionably valid.
The book is not a long one, but there is just so much to unpack. We get a view of some pretty notable tech failures in government (including the health care.gov debacle) that examine the failure, and the root causes of the failure. These root causes are not because of faulty code, or due to projects being under-resourced. Pahlka identifies systemic incentives that have ground level policy implementers more concerned with checking off boxes dictated by by the policy at hand, and protecting themselves against oversight, and potential project failure that someone above them may attribute to implementation that deviated from policy. And that oversight can be extensive, as Pahlka points out.
“But it’s already common for government technology teams to report to six, seven, eight, or even more separate oversight bodies, and that’s before they get flagged for an investigation by an agency inspector general, audited by the Government Accountability Office, or called before a congressional committee (or the state or local equivalent of any of these). There are obvious harms from this excess: it worsens an already debilitatingly risk aversion, and when these bodies issue conflicting guidance it creates confusion and derails progress. But the bigger problem is that all the oversight hijacks the time and attention the teams supposedly delivering the product or service. When all your time is spent answering questions and writing reports for other people inside government, it’s mighty hard to be focused on the people outside government you’re supposed to serve.”
Jennifer Pahlka “[Re] Coding America.” Pg. 14
An important point but one that flows into a more critical one, which is the total disconnect between those creating policy, and the folks on the ground trying to implement said policy. That disconnect is shown to us through several painful specifics.
We get a look at the overloaded California unemployment benefits agency, whose software staggered and crashed under the load of filings during the pandemic. Whenever I would see a story like that I always assumed that the underlying technology was likely ok, but that the system was simply over-capacity. Wrong again. Pahlka describes what they found under the hood, which was a system that had been appended to multiple times, and in multiple ways, building on top of technology that dates back to the 1980’s that was using COBOL. The system was so disjointed, with these separate pieces handling different tasks, (and sometimes the same tasks) that the team brought in to ascertain the backlog of cases took seven full weeks just to count that number. This was not employee incompetence, or even the IT staff being incompetent. It was operating a legacy system that had continually been patched with updates that built on obsolete technology that simply could not meet the needs of the citizens it was supposed to be helping.
Well then why not exit the existing system and start from scratch? Pahlka gives us the simply unbelievable cases of where we have set out to do that.
1. The California update of the court system software to connect the courts with a document management system. Cost $500 million. Result: Scrapped.
2. A 2009 launch of new software by the U.S. State Department to upgrade software for visas, passport renewals, and other services. Estimated launch 2016. Cost: Original estimate of $18 million. Real cost: Indeterminate, with estimates between $200-600 million. Launch? Limited pilot of one component in 2019 in six locations worldwide. As of 2021 that pilot program had not been expanded.
3. IRS project to replace the key “Individual Master File” launched in 2000, with completion scheduled for 2006. By 2009 project $37 million over budget, with no result. Project: Scrapped. New replacement project launched, scheduled completion by 2014. In 2019 that project was declared too broad by the IRS, and modified to retire only parts of the old system. In 2021 the IRS has said anticipated completion of the new project is 2030.
Why does this occur? Is it lack of technology chops in government service? Pahlka points out that many of the mega projects have been outsourced to companies with plenty of technology talent, but the results have been, in many instances, the same. Plenty of money spent, but no real results. Nicholas Bagley, in an Atlantic story on this book, summed it up accurately (and better than I could)
“Pahlka brings to vivid life how a cover-your-butt culture that prizes legalistic compliance above all else is especially pernicious for government tech. Policy makers layer requirement upon requirement without considering whether the benefits of complexity outweigh the costs. Even when policy makers give agencies some flexibility, the bureaucracy often transforms suggestions into rigid requirements, which are then slavishly followed. The public interest gets forgotten along the way.
In other words, Pahlka’s book isn’t just about tech. It’s about the American administrative state, and it’s a call for paring back the rigid rules that make it so hard to govern, and for rebuilding government’s ability to do its job effectively.”
Nicholas Bagley How to Fix the Government The Atlantic June 12, 2023
Creating top down specifications for new software that include what browsers need to be accommodated, and other layers of rules that are meant to meet needs but simply hamper the development of technology that actually helps people, is a recipe for failure. And once these conditions are placed the bureaucracy, in so many cases just fearful of not checking all the boxes, carries them out even to the detriment of the ultimate usability of the software.
As Bagley points out Pahlka’s book is nominally about government and technology, but in reality it is about so much more. Policy makers really should read this book. It not only will open your eyes but gives concrete, and achievable, ways to defeat this problem. If you have time catch the Ezra Klein podcast with her as the guest. Worth a listen.
The Ezra Klein Podcast with Jennifer Pahlka
Nicholas Bagley The Procedure Fetish
Bill Manzi.com 