Recoding America: Why Government Is Failing in the Digital Age and How We Can Do Better by Jennifer Pahlka

Recoding America: Why Government Is Failing in the Digital Age and How We Can Do Better Reviews

• 
  Megan

  As an Ezra Klein super-fan, I will pretty much read anything he strongly recommends, so I pre-ordered Recoding America as soon as he referred to it as "the book every policy-maker should read."
  
  I'm not a policy-maker, but this book articulates certain dynamics I've seen frequently without knowing how to talk about them effectively. Specifically, Pahlka outlines the way that hyper-attention to compliance, process, and procurement (all interconnected) can lead policies to fail. While I don't work in government, I've spent nearly a decade managing public money through federal and state grants... so I've seen this. I've seen this a lot.
  
  I understand why Ezra Klein recommended this book. When we (Americans) talk about politics, we're usually talking about policy, not so much about implementation. Pahlka is excellent at redirecting our attention on the implementation side, identifying the challenges and the opportunities. I want to give this book to half the people I work with so we can dig into these challenges and the ways they show up in our work.
  
  But I think it is important to remember that she's a stakeholder in the solution she's pitching. I'm compelled by that pitch, so I often had to remind myself that this wasn't some journalist or researcher describing these dynamics: this was someone who served as Deputy CTO for Obama, the founder of Code for America... when she suggests that the United States Digital Service had a profoundly positive effect on the projects it touched, she is talking about the department she founded. When she praises agile project management techniques, she is promoting the approach that shehas worked long and hard to bring forward within government agencies.
  
  I don't think she is wrong. I'm kind of already in her choir. It's just useful for me to remember she's not some disinterested judge.
  
  One anecdote Pahlka comes back to frequently involves Kevin, a psuedonymous IT leader at the VA:
  
  

  “I’ve spent my entire career training my team not to have an opinion on business requirements,” [Kevin] told me. “If they ask us to build a concrete boat, we’ll build a concrete boat.” Why? I asked. “Because that way, when it goes wrong, it’s not our fault.”

  
  
  From that point forward, "concrete boat" becomes shorthand for any absurd project or specification that gets in the way of effective government services.
  
  When I was talking about this book with my husband and I used the analogy, he stopped me. "But there ARE concrete boats."
  
  And turns out he's right:
  https://www.ferrocement.org/
  
  Pahlka references the "concrete boat" idea as if it is self-evidently foolish... but we're the fools here. Even if rare, there are times when a concrete boat is appropriate.
  
  Anyway, I think this is emblematic of the "pitch" element of the book. Throughout, she barely acknowledges the advantages of the approaches she is critiquing, nor any of the disadvantages of the approaches she is promoting.
  
  I've worked in waterfall project management environments and agile project management environments, and the truth is, I lean towards agile. But I've come to appreciate that both environments are flawed, and neither work all the time. Pahlka talks a LOT about the disadvantages of waterfall project management, but barely acknowledges the issues with agile.
  
  Similarly, she often references the idea that "paperwork favors the powerful." This is undeniably true. But the idea that reducing paperwork inherently increases equity is not, and she frequently implies that the one follows from the other.
  
  Despite this, I still will recommend the book to nearly everyone. It's a great springboard for discussion, and probably resonates in many workplaces, not just government tech. I will likely come back to the books "core concepts" (
  https://www.recodingamerica.us/concepts) regularly. They are oversimplified, yes. But they also serve as a useful shorthand for fighting the fetishization of compliance.
• 
  Emmkay

  I almost didn't read this, unable to remember why I'd put it on hold at the library since it's not my usual reading material. Now, however, I think I'll buy a copy and hope I'll have the opportunity to put its insights into practice one day. I cannot believe I've just said that about a book that discusses agile project management and systems change...
  
  Pahlka is the founder of nonprofit Code for America, and served as deputy chief technology officer under Obama. She explores why government has had such a hard time moving into the digital age, which unfortunately reinforces distrust in government and in collective public-minded solutions to the big problems of our age. Among other things, she pinpoints the high-minded disengagement of policy makers, who formulate policy and leave implementation up to others (even though their muddled accretions of years of policy are nigh-on impossible to implement), legacy systems and policies turn every attempt at improvement into an archeological exercise, a new and misguided passion for project management that accumulates and tracks completion of 'requirements' rather than focusing on evaluating what makes sense along the way, and enormously unwieldy out-sourced contracts for new systems (which benefit the IT consulting firms that win them, but not the public organizations that have fallen into a trap of outsourcing technological expertise).
  
  I have to say US bureaucracy seems especially bad, but Pahlka's insights still resonated with and made sense of my own experience. Yes, I'm aware the author's services are part of the solution she proposes, but it was a great, thought-provoking read. I never thought I'd be sitting up in bed reading excerpts excitedly to my spouse from this kind of book...
  
  Please excuse the many quotes for my own later reference:
  
  "Because each successive leadership at an agency usually gets the budget or the mandate to deal only with the most pressing technology crises at hand, and because tech investments must always be pitched as adding some new capability to the system (rarely just renovating what already exists), each piece of the system gets built in different technology paradigms from different eras. But every new piece depends on everything that came before, so each successive layer is constrained by the limitations of the earlier technologies. The system is not so much updated as it is tacked on to. Over time, new functionality is added, but the system never sheds the core limitations of the foundational technologies. At the same time, it becomes enormously complex and fragile. Updates require caution, as any change in one layer can have unforeseen consequences in the others. It becomes harder and harder to support the technologies in the lower, older layers, while the more recent layers require constant updates and patches. The paint cracks."
  
  "When we speak of 'legacy systems' in government, it does not mean simply that they are old. It means that we are grappling with the legacy of decades of competing interests, power struggles, creative work-arounds, and make-dos that are opportune at the time but unmanageable in the long run."
  
  "Modernizing technology without rationalizing and simplifying the policy and processes it must support seldom works. Mostly, it results in much the same mess you had before, only now in the cloud."
  
  "[There's] the need for an approach that is more democratic (in the small-d sense of the word), more open to popular interpretation, than our current bureaucratic culture allows for. Such an approach would recognize that fussy, technically accurate readings of law and policy can be entirely unhelpful when it comes to creating services that make sense for people."
  
  [1975 observation Gall's Law]"'A complex system that works in variably found to have evolved from a simple system that worked,' Gall wrote. 'A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.'"
  
  "...[I]ssuing order, especially from a place of disdain or disrespect...only reinforces blind obedience to the hierarchy. You cannot get the benefits of product management and agile development in a top-down culture."
  
  "Our elected leaders keep thinking in terms of money, regulations, and oversight because those are the levers they have most immediately at hand. When they see a need for change, they push those levers. How much money will it take to solve the problem? What new rules can we put in place? How do we monitor failures more closely and punish poor performance? These levers can be helpful, but they need to be directed at the problem underlying our delivery failures: the lack of skilled technologists within government who are empowered to make the necessary decisions."
  
  "In his 1966 book The Nerves of Government, Karl W. Deutsch said, 'Power is the ability to afford not to learn.' When power flows one way - down the waterfall - from policymakers to implementers, from federal to local government, from those with high-priced lawyers and accountants to those without , even those the system appears to benefit lose out. Is it any surprise that the most powerful institutions within the most powerful country on earth have resisted the uncomfortable work of developing new and foreign competencies? If our timing is better in this moment, it may be related to our nation's loss of power."
• 
  Kristina Fort

  A must-read for policymakers, civil servants, and anyone who wants to see what needs to be done to make the civil service better for people inside and outside of it.
• 
  James Midkiff

  I read this book because it was highly recommended by Ezra Klein on his podcast and my current position is a Data Engineer for city government, so it is highly relevant to me.
  
  The woman who wrote this book knows her stuff. She did a deep dive into her experiences working with various governments on failing tech projects. The key takeaway is that a failing tech project is usually a symptom of deeper problems: burdensome project oversight, bureaucratic risk-aversion, insufficient tech capacity, or designing for the process and not for the user. No amount of money, increase in oversight bodies, new technology or outsourcing would fix this. Instead, we need to train and support existing government workers, hire new people with digital skills into government, put user-focused public servants into positions where they can effect change higher up the policy ladder.
  
  Her biggest criticism was of the waterfall software development cycle; while I knew of it already from a graduate course on the principles of software engineering, it should be familiar to anyone who has been told to build a project that fits a lengthy, outdated, confusing, or conflicting set of requirements and that does not pay attention to the needs of its customers. Policy often thrives or dies because of its implementation.
  
  The lessons are critical, the anecdotes are mostly engaging, and the deep dives into government are illuminating.
  
  P.S. I love her sharp criticisms of Oracle and its then senior vice president Kenneth Glueck for corporate greed and regulatory capture, as well as Elon Musk for arrogance and harming democratic institutions
• 
  Lauren

  Buy this book. It’s one of the best nonfiction books I’ve ever read. Jen gets it. Her extensive use of real-life examples and clear language make this one of the most important books anyone worried about American democracy and government could read. I’ve sent colleagues a ton of quotes from this book - some of the top ones are below:
  
  “If we want to escape that fate, on climate change or any other existential issue we face, implementation can no longer be policy’s poor cousin. It cannot be beneath the attention of our most powerful institutions and it can’t be beneath our attention as a public.”
  
  Government must deliver on its promises if it wants to keep and earn the trust of the American people.
  
  You cannot legislate competence. It is an issue of people - getting more of the ones we need and allowing them to do what we need done
  
  You learn that you need to think about the technically implementation fo a law when you write it. Otherwise, you’ve written a law that looks good on the books but doesn’t accomplish much at all.
• 
  Joy

  I read this with my colleagues, because it’s talking about our field. I’m giving this 5 stars for existing and because it’s headed in the right direction. If I rated it based on my enjoyment (like I do all other ratings on here), I’d give it 4 stars.
  
  In my opinion, the author has 3 main points: 1) Government needs to hire better for IT; 2) government IT needs to use agile development and run far away from waterfall development; and 3) while policy is a crucial first step in making changes we all need to care about the actual operationalization and implementation of all policy changes. (One of my colleagues would say that another main point was that people shouldn’t sue the government as much because it creates administrative burdens that don’t result in better outcomes for citizens anyway. I personally didn’t hear that point come through all that loudly, though.)
  
  I don’t disagree with the 3 main points I took away from this. What I wrestled with was my suspicion that this author has never once hired a real IT staffer in an operating division of federal government without Direct Hire authority — so sure, government needs to hire better for IT, but DO YOU KNOW HOW HARD IT IS TO HIRE ANYONE AT ALL IN FEDERAL GOVERNMENT?! If that’s one of the main points, there needed to be at least a whole chapter (or half the book) dedicated to why it is so hard to hire and how she envisions that changing so you can hire better. I just think it’s way too easy to say “government needs to hire better” as if that is something that can happen easily. As a career civil servant, it’s hard to read this sentiment without a show of deeper understanding of what a hiring official is up against.
  
  I guess I also wrestled with the third point. I mean, I love that she included it in her book. What I wonder about is how you get people—society—to care about ops and admin. So once again, sure you can just say it needs to happen, but how do you actually get anything to change?
  
  But even though this book comes across very much as an outsider writing about government, I appreciate where she was trying to go and am happy a book could be published about it. Much of my struggles with the book relate to the fact that I’m an insider and it’s clear she’s writing about us from the outside, with an outsider’s level of knowledge.
• 
  Nicolas Acton

  I heard Pahlka on the Pivot Podcast with Scott Galloway and Kara Swisher and thought her book would be worth checking out.
  
  If you, like me, are someone who works in, or tangential to, technology implementation in the Government then I think this book will massively resonate with you. Jennifer helps characterize and illustrate many of the problems I have observed in my time selling and implementing government technology. To name a few:
  - data being used as a way to measure the outcomes at the end of a project instead of consistently being used to observe and change
  - Waterfall-driven development leading to late deliveries of bloated products
  - A culture that generally promotes handing off all work to contractors who rotate out with tribal knowledge consistently
  
  It felt good to basically be told in book form that my observations were valid and not crazy, but also Jennifer provides some ideas on how to actually fix these issues as well as people driving change within various agencies, giving me hope that with the right top-cover our Government agencies can reach the same levels of service as companies like Amazon.
• 
  Herbie

  It says a lot about me that this was an utter page-turner for me, had me up late at night wondering how our heroes were going to surmount arcane contracting rules AND stubborn bureaucrats AND oversimplified politically motivated “solutions”… AND private (and sometimes non-profit!) contractors who just want to keep the money flowing to them no matter how wasteful it is.
  
  This really should be required reading for anyone who cares about government and making government work.
  
  The conclusion is the weak point; Pahlka shifts into hopeful, speech-making mode when I’m not sure she has really outlined a reason to be hopeful. I don’t disagree with any of the particulars of the conclusion but I do disagree with it as a rhetorical choice. The rhetoric we need about this problem - how government harms itself and fails to serve by being overly concerned with process and not concerned enough with outcomes - needs to be urgent and clear and radical. Government needs to reorganize itself to work for the people and it needs to do it now, or the forces that want to undermine the institution of government itself will continue to win.
• 
  Evie Bauman

  "On climate, or any other existential issue we face, implementation can no longer be policy’s poor cousin. It can’t be beneath the attention of our most powerful institutions, and it can’t be beneath our attention as a public. We may have trouble imagining such banal reasons for our failures, but we seem equally bad at imagining the role of the details of delivery in our success. It is worth challenging our collective imaginations. What could a government that delivers at internet speed and scale achieve? And what role might each of us play in bringing that vision to life? If we lack that faith in government, perhaps we need to reframe the question. Government is simply the name we give of the things we choose to do togetther.”
  
  “Policy people tend to see those who implement the policy decisions they make as being far below them in the pecking order, perhaps even at the bottom of it.”
  
  “The way the Administration managed the program looked almost as if they thought that actual governing, the nuts and bolts of governing, is for peons. And they are the policy people, intellectuals vs. mechanicals. Policy people vs. operational peons.”
  
• 
  Erin Hatch

  Must read for anyone in government or government adjacent roles.
• 
  Philip White

  This is a good book, but it is written for specific people. If you are interested at all at digital implementation of governments' laws, this book should be required reading. Pahlka provides a perspective on the hurdles of implementation across all governments in the United States that is very valuable. In summary, it needs new thinking and what we do now is not very helpful--regressive even. There are a few bright spots to learn and iterate on--Pahlka highlights the web forms to receive covid-19 tests. Takeaways from this book will help me in my line of work.
• 
  Sanjida

  Pahlka has something important and insightful to say and every government employee needs to hear it. She really nails the risks and pitfalls of siloing policy from product and implemention.
  
  I'm just not sure that everyone needs to read this full book. It is repetitive and rambling and occasionally overstates or simplifies the case. A podcast interview (like with Ezra Klein earlier this year) or an essay length version is probably all you need.
• 
  Micah

  A must read for anyone who wants to understand how hard it is to get government programs to work, why they get gummed up, and how a new wave of tech-savvy and human-centered design practice is transforming it for the better.
  
  My full review is here:
  https://open.substack.com/pub/theconn...
• 
  Doni Guanciale

  SUPER interesting read. This was a recco off of Obama’s reading list to understand the rise of AI & how the government can harness tech to support democracy. This book analyzed the history and difficulties of implementing tech within government services & it was really eye opening to nuances between the private & public sectors. The TLDR version: our government has been HORRIBLE (shocker…) at incorporating the constantly, updating tech into our systems & use it in a way that provides for the civilians who need it. The pandemic showed a lot of ways our crumbling system failed but also other ways people understood the need and used tech to support citizens (ie mailing at home Covid tests). My biggest takeaway is there needs to be a focus on HOW the policy & laws are implemented, in most instances bills aren’t getting executed because they weren’t written with consideration on what was possible. Obviously, this isn’t surprising, but it’s definitely a blunt message of this book that I think is applicable even in the non-government workforce.
  
  Ultimately, I’m hopeful that with the growing of technology, AI specifically, the federal government will continue to implement positive measures into our systems & digital infrastructure. I also think millennials & Gen Z will be inherently more well versed on the implications and need for manageable, functional, but also evolving tech.
• 
  Ryan

  Incredible book that everybody should read about why government approaches technical and digital design in the way it does, and how we can change it to better serve people an make their lives better.
  The anecdotes about healthcare dot gov and covid are frustrating as all, but ultimately the stories of real people trying and succeeding are deeply hopeful
• 
  Isabelle Leventhal

  You ever read a book reading you to filth? That was this for me. I'm going to be insufferable at work and make everyone read this.
  
  Would recommend, particularly to those of us working in government.
• 
  Kyle Witzigman

  Best book I read in 2023. Design AND Delivery matter. Also fun to recognize some of the people in the stories!
• 
  Dan Connors

  
  "We strive to reach people and communities who have been left out by leveraging our resources to create a more just and equitable world. We believe that we all do better when we all do better." Code for America
  
  Ever since the Reagan Revolution of the 1980's, Americans have had a hate/tolerate relationship with government. The days when the New Deal and Great Society brought us Social Security, Medicare, and big government were at their end.
  
  Republican administrations under Reagan, Bush, and Trump cut federal budgets, and made working for the government seem uncool. In the tech sector, especially, computer professionals preferred Silicon Valley and potential riches over less lucrative government jobs. How has this impacted the delivery of important government services like the IRS, VA, Medicare, or the Military?
  
  In the 21st century, this tech deficit has hurt the administration of vital laws that the nation still depends on through its government agencies. In 2020, when Covid-19 shut down many businesses and caused unemployment to skyrocket, congress passed laws that were meant to help a lot of people in immediate need. But it's one thing to pass a law and something entirely different to actually implement it. Congress depended on the states to dole out money through their unemployment systems during the pandemic, and many states were woefully unprepared. Millions of people tried to access state unemployment systems and were turned away because the systems couldn't handle them. How could this happen?
  
  This and many questions like it are answered in Recoding America- why government is failing in the digital age and how we can do better, by Jennifer Pahlka.
  
  Ms. Pahlka was deputy chief technology officer under President Obama and founder of Code for America, a nonprofit dedicated to improving the delivery of benefits with user-friendly access.
  
  There are two big problems that are inter-related. First- the computer systems that the government relies on are huge and complicated, built in layers of computer code that has evolved as technology has evolved. There are a limited number of people who understand how it all ties in together, and many of them are nearing retirement. The second problem is a political one- many Americans and politicians don't really like government, and don't want people (especially people they don't approve of), to get any benefits, so they make the system as inaccessible as they can to start with.
  
  The book details how the food stamp program, SNAP, had an online application in one state with 212 questions that users had to answer before getting a decision on benefits, leading to almost half of the eligible people not being enrolled. Other states, like Florida, deliberately made unemployment and Medicaid enrollment sites deliberately hard to navigate, and when Covid hit, many people suffered needlessly, even though help was available through the federal government. The whole point of pandemic assistance was to help people temporarily who were unable to work so that they wouldn't fall deeper into despair and poverty. But the politics of helping people is tricky, and in our capitalist society relying on government help is seen as weakness. But expecting ordinary people to never need any type of help is unrealistic and cruel.
  
  One section that amazed me was that when politicians panicked during Covid, they threw money at the unemployment agencies to hire more workers, and it radically backfired making things worse. The new employees had to be trained, which takes a lot of time, and the people who know how to do the important work were taken away from that work to train the new people. Many agencies have bottlenecks where very specific knowledge and training is required, and if these people retire or are otherwise occupied, very little can get accomplished. Thus one of Pahlka's main recommendations of the book is the need for more trained and experienced IT professionals to replace the many who are expected to retire in the next few years. Given the salaries that Silicon Valley can provide, that may be a tough sell.
  
  Pahlka describes bureaucracy as a waterfall, with rules and regulations falling down on agencies from on top and being carried out by minions on the bottom rungs. The problem with waterfall systems is that important information often can't flow the other way. Policies can take years to develop and carry out, and they rarely work as designed right away. Workers fear the chain of command, and instead follow instructions to the letter, with the results often missing the mark with what was intended by the politicians who dreamed it up. She describes some of the more expensive disasters as concrete boats- expensive structures that are doomed to sink once put into service. This same principle happens in private industry too, but failures there can be more impactful and force decision makers to listen more closely to end users.
  
  I have never worked for the government, nor do I have the slightest idea how to code, and this book opened my eyes up to a new world that impacts me and everyone else around me. As an accountant, I work with the Internal Revenue Service and state agencies quite a bit, and it gave me some insight into what they are facing. The IRS has been starved for funds for over a decade, and they are tasked with enforcing an impossibly complex tax code that few people understand, including them. It amazes me how they manage to incorporate all these constantly changing laws with their other duties of sending out stimulus checks, dealing with delinquent taxpayers, and collecting money. The two things that have suffered the most- customer service and audits, are the things that have huge impacts on their perceived effectiveness, but they can only do so much with an aging workforce and out of date technology.
  
  The book covers the disastrous rollout of Healthcare.gov, and how the website didn't work at first. It took months of experienced coders to clean up that mess, and Republicans had a field day pointing out the failures. But it also covers the quick startup of Covidtests.gov, and how that site worked perfectly to get Americans free Covid test kits in just seconds, making it seamless for so many to see if they were infected.
  
  Thankfully this book isn't too technical, making it an easy and fascinating look inside the world of both government and computer coding. The politicians who dislike government frankly like for it to fail, and like to point out any time it comes up short. Like most people, I think government has an important place in society, and want to see it succeed as long as it remains responsive to citizens through democracy. Responsive government can be a lifesaver in times of crisis, and good government shouldn't be that controversial. The people at Code for America are "people-centered problem solvers working to improve government in meaningful ways," and it's nice to know that somebody out there is looking out for us when government and private industry fail to do so.
  
  
  
• 
  Jakub Dovcik

  Probably the best book on policy implementation I have read in a very long time - breaks a lot of stereotypes and assumptions about the approach of US federal and state governments to digital services (with many relatable points for other national and local governments around the world) and shows what actually can be done to improve public services, not just in the digital sphere.
  
  It shows that policies like changes in criminal records or push for value-based health care do not just happen by passing of the relevant legislation, but need to be turned into code or individual products - and we too often see the mistakes of the government in this sphere without actually understanding what causes them, that it is not just general government incompetence - Pahlka actually shows how many clever and competent people work in the government and those that do not seem to be so just have bad or different incentives.
  
  Firstly, the problems Pahlka identifies:
  1. Outdated systems - California’s Employment Development Department (which is an interesting newspeak) faced a backlog of unemployment benefit claims (about 1,2 million people were waiting for support) while it ran on mainframes from the 1970s, with software written in COBOL and workarounds on keyboards - experience from other states shows that even putting things on the cloud does not remove the clutter. IRS still has its basic document, the Individual Master File, on the same system as in the 1960s.
  2. Chaos in policy - layers of federal, state and local rules, often contradictory or satisfying political objectives (like the necessity to not pay unemployment support for people that get ill for a single day), making implementation extremely difficult.
  3. Legislators do not understand the reality of tech - like Brook’s law - that adding new people to a digital/software project slows the project down as new people have to learn the ropes and especially the policy aspects of the job - for instance in processing the unemployment claims, that have layers of individual legislative decisions (in EDD was a guy that worked there for 17 years and was still called “the new guy”)
  4. Waterfall management instead of agile - “we have to do this pointless thing because Congress mandated us to do so” without the willingness to question the requirements and description.
  5. Technologists in government are too focused on complying with the process so that they do not get fired, the outcome is secondary - like one VA technology officer who said he “does not have an opinion about the business requirements” and would be okay with “building concrete boats” if they were specified by political/policy people.
  6. Implementation is seen as too lowbrow or low-level by policy professionals in the White House or in departments - OMB was tasked with managing digital services in 1996 by Clinger-Cohen Act but effectively refused to do so because they saw digital as ‘operational in nature’. The book deals a lot with how, even on the level of individual agencies, the divide between policy and implementation (or IT) is huge and very much limiting how the policy actually is done and perceived or used by the citizens.
  7. Government outsources everything (because it treats digital services as a commodity, since the definition of data management in the 1965 Brooks Act) and does not have the competence to change its code - often even the contractors, who are good at “winning contracts but not necessarily doing them well”; plus too specific requirements across agencies and departments, that limit the ability of the individual project to be tailored (like requiring some software module to be present in every Department of Defence software) - that often leads to gigantic projects in hundreds of millions of dollars that take years, developed by firms that have the capabilities to do deliver the project for the requirements (paperwork always favours the rich and powerful)
  8. Rule-making by a too-long legislative process that has to be posted in the Federal Register due to the Administrative Procedure Act (APA) - which extends the time it takes to adjust the workings of a policy if it makes little sense in implementation.
  9. Everything about the development of services and their procurement is too legalistic, procurement afraid of litigation. (Although her argument about the US government having a “medieval legacy” of serving as primarily a judicial authority, feels a bit strange - I would say it has probably more to do with the legacies of litigation around the birth and growth of the administrative state in the first half of 20th century, which she also briefly touches upon).
  10. Too little focus on service design - good digital products cannot be done without good policies. Policy experts often get too specific (like having 9 different groupings when 2 would work fine) to the point that it makes it really difficult to actually implement the policy.
  
  Proposed solutions
  - More product managers, fewer project managers. The government needs solid product owners (she shows how it is possible by an example of one technologist at the CMS - Centers for Medicare & Medicaid Services, Yadira Sánchez, who was not afraid to question the requirements, effectively simulating the agile model by delivering small workable products that met the spirit, but not always the exact letter of the law which was possible due to the clout of her 20 years of experience in the CMS).
  - Generally, the book asks for “incremental, user-centred, agile development” of digital services by the government and a culture change that creates capacity for the development of IT solutions within the government and not just for procurement (as some big vendors of IT services for governments would like to see).
  - Some improvements were achieved by creating a federal Chief Information Officer (implementation role) and Chief Technology Officer (advisory/advocacy) with the team in the U.S. Digital Service - plus 18F unit within General Services Administration (procurement agency for the federal government). This shows that the sense of purpose and interesting nature of the jobs can bring outside experts in digital technology into government, much like has been the case in the legal profession over the past hundred years.
  
  Overall, this book is extremely insightful - it shows how policy failures happen and that what is necessary is more focused on the users of digital services, not the policy goals or government needs. It calls for a culture change, from big projects to small improvements, focused on delivery and assessing success based on results, not just processes (the fact that it might not always be easy to do is not always addressed though).
  
  As a government policy professional, I only second Ezra Klein’s statement that this should be read by all policymakers, on all levels and especially those higher up, when it is easy to be detached from the actual and real effects of the individual policy decisions.
• 
  Margia

  important message
  
  This book gives numerous compelling examples of how digital services and technology competence are critical to achieving our policy goals and effective functioning of the government. Writing style and organization are a little stream of consciousness and the whole book could have been edited to be more concise.
• 
  Greg Talbot

  The words “database”, “policy”, and “implementation” are rarely employed with so much inspiration and gusto. Jennifer Pahlka’s dedicates her “Why Government is Failing in the Digital Age and How we Can do Better” to the public servants. Exploring the challenges of policy and technology, Pahlka walks the reader through the obstacles, culture and successes of government based platforms.
  
  Pahlka explores a number of government initiatives such expunging drug charges after drug decriminalization in California (Prop 64), streamlining unemployment insurance during the pandemic, covid testing kit distributions. She threads a compelling narrative; for example sharing the bottlenecked issue of claims adjusters having to review some 1.2 unemployment insurance claims, and the efforts of the Employment Development Department (EDD) to develop a technical solution.
  
  There is a strong case that the distance between policy makers and the implementers accounts for unexpected outcomes that have weakened trust in government. Simply put “digital work” is not what important people work on (p.15). Rather than cleave politics into the tired left/right divide, she counters with the limitations on all fronts. Restrictive access of implementation teams to decision making. Policy detail that stifles creativity and intent. Small cramped and professional language that defensively limits legal action and achievement.
  
  One of the strengths of the book is that it centers public service to every element of the project initiatives. She gives examples where public servants design solutions for those without financial safety nets. One striking story shared, in a attempt to understand the perspective of SNAP benefit recipients, her colleague applies for the SNAP program and details applying, using and subsisting of the benefits. The team was able to understand the hidden costs not captured from technology. Shame and fears, such as an overdraft amount at a cashier, helped the team create a method for SNAP balance totals to be retrieved.
  
  She also reminds the reader why people go into public service . It’s not the prioritization of compensation or cushy jobs. The empathy and clarity of purpose is its own reward. Often there is bravery required to buck the legacy processes. The challenges of layered architecture, excessive applications and multiple databases means complicates the sweeping goals of policy. Lawmakers envision a system she states, and not a bunch of tenuous connected layers ( p.41). Often these are stories of teams meeting the challenges despite the limitations. Sometimes taking charge and becoming the change agents needed for real change.
  
  It may be true in any year, but it feels like more than ever, our country is challenged and mistrusting of big government. A gridlocked congress, a conservative supreme court, and the rapid innovations taking place in the private sector challenge the notion that we should trust the deep state of individuals that are responsible for building and distributing tools based on policy. Despite the fears of government , that may lie deep in the American psyche or the fears of unabated technology there is the persistent need to serve each other.
  
  This book takes time and care to explain to the reader that there are tireless and hardworking individuals working to modernize solutions. There are regulatory rules that make the process harder, and skill gaps that limit creativity and production. Nevertheless, Pahkla brings and optimism and clear eyed results. Whether it’s covid test registration or unemployment benefit screeners, these processes can, and are overwhelmingly successful. And their success isn’t just powerpoint bullets supporting return on investment, it’s success measured in everyday people’s lives.
  
• 
  Grace

  Recoding America is a primer on bringing America’s government (in particular, its IT) into the digital age. The problem isn't as simple as the government being unwilling to take on new technology. Rather, cumbersome government software derives from obscenely complex and lengthy rule-making, combined with civil servants’ prescription towards these laws (lest they lose their jobs).
  
  This problem becomes exacerbated by the following:
  - Desire for a smaller government means creating some distance from constituents through forms. However, in order to make sure these forms equitably distribute benefits, they are made to be incredibly complex. When a user fails a single eligibility, the likelihood of them receiving their benefit decreases exponentially since they’re relegated to manual verification of their identity/status (Pahlka provides COVID unemployment and veteran benefits as two examples).
  - There are project managers, but no product managers in government. The current ethos for getting things done in government involves executing thousands of pages of rules, but not necessarily evaluating their impact.
  - Those at the top designing the regulations that then inform software don’t empathize with their final users (constituents). Pahlka points out an example where one of her colleagues tries to live off of food stamps to experience SNAP. There’s no way to easily check your balance when you lose your receipt, and you have to humiliatingly return food when you’ve gone over (i.e., no non-discreet way to return items).
  - Liberal officials will sue agencies that attempt to move faster to deliver (as they discard minutiae in laws); such retaliatory behavior decreases appetite for risk and creates more burdensome rules that lower delivery time for users.
  - Government will contract out projects and force new projects to stick with the same contractors, therefore limiting the extent to which they can execute well.
  At the end of the day, implementing innovative technology cannot be the fix-all solution because it may not necessarily be feasible in a given timeline or it may not be informed by user needs. Improving public interest technology requires a mindset shift in accountability, user-centricity, and risk-taking.
  
  Fortunately, Pahlka ends with an optimistic chapter on successful examples of governments serving their citizens via technology. Ukraine, for instance, provided their citizens with digital identification, which became life-saving during the Russian invasion as Ukrainians required identification to retrieve their bank deposits and procure other assets. In Japan and Europe, tax filing is completely automated; citizens just need to check the final form and correct any information. And while there’s still a far way to go, the US’s online distribution of COVID tests was delivered quite seamlessly.
  
  While government IT problems stem from a different source than that of other issues plaguing Capitol Hill, Pahlka points out a bigger theme. Today, the US government fails to serve its citizens’ interests. A reset that forces us to reckon with citizens’ needs is necessary if America is to call itself a government that serves its people.
• 
  Kevin Whitaker

  When we think of politics, we think of writing, negotiating, and passing bills or executive orders. But that's not enough to actually make change happen in the world; laws and rules need to be implemented. This book is about how US governments are poorly set up to implement laws in a way that serves citizens well (especially with technology), and how that can undermine what those policies were trying to achieve in the first place. It's a really good book, and it's especially important as a counterweight to a trend of political discussion becoming even more dominated by the big picture, national issues, and vibes instead of real impacts on people's lives.
  
  What's the problem? Governments are hierarchical: legislative bodies pass laws, which agencies turn into requirements, which are handed down to others (usually contractors) for rote execution. So nobody is responsible for thinking about whether the requirements actually make sense: the people at the bottom doing the real work don't have the power to question things; the people at the top are too focused on the big picture and think implementation is beneath them (unless something breaks catastrophically), and the people in the middle are safer if they follow established standards instead of trying to fix problems in more creative ways.
  
  This is a problem everywhere, but it's especially true for digital projects: you can't take advantage of the rapid feedback loops (learning from users and tweaking code) that have been so powerful elsewhere; older laws and projects are more constraining because the state of the art moves faster; and policymakers are less likely to understand the details of technology, so they're more likely to make dumb specifications. And "digital projects" aren't just laws about technology; they include anything that involves submitting or storing data, which is basically everything.
  
  Pahlka's solution is pretty much to bring "product managers" into government -- people responsible for making sure that policies are implemented in a way that makes sense for citizens (websites work, forms aren't too confusing) instead of checking off all the boxes as easily as possible. They still have to follow the letter and intent of the law, of course, but that can be made easier by bringing technical people into the policymaking process. But that will require policymakers to actually care about implementation, which in turn will require *people* to care about implementation, which isn't really the way we're going right now.
  
  To nitpick the book - it doesn't seriously engage with conservative criticism (it takes as a given that conservatives want government to provide the services it does provide well, which isn't always the case, e.g. tax forms) and I would have liked to see more cross-national comparison to understand if these are uniquely American pathologies or if they hold everywhere.