Jen Pahlka founded the non-profit Code for America in 2009 to help state and local governments use technology better to work with citizens. The organization has had some serious impact. CalFresh, the California state Supplemental Nutrition Assistance Program (SNAP), was so hard to sign up for that folks gave up, missing out on support that lawmakers meant them to have. The Clear My Record program automated the clearing of marijuana convictions after the legislature legalized marijuana use and expressly forgave those earlier convictions. CfA fixed them both.

She makes the point, compellingly, that code is policy -- implementation is policy. Until you can deliver the services that our policies and laws require, you haven't really made those laws or policies.

On the strength of her work at Code for America, Pahlka was recruited into a series of jobs in the federal government. She worked as Deputy CTO of the US under Todd Park during the Obama administration, and helped to create and institutionalize the US Digital Service.

Along the way, she learned a lot about why so much government-delivered technology is so bad. She learned what works in delivering systems and services that really serve citizens.

Recoding America digests those lessons and tells that story. It's full of great anecdotes -- the failure and resurrection of healthcare.gov, the signature Obama-era ACA enrollment website, is widely remembered, but you'll get an insider's view on what went wrong and how it got fixed. The ways in which the Centers for Medicare and Medicaid (CMS) learned from that experience, and how it has gotten better because of it, is hopeful.

Best of all, the book ends with concrete advice for government employees, citizens and technologists on what we can do better, and why. I found it genuinely inspiring and hugely interesting.

Five stars because there's not more stars. ( )

A book by a technocrat convinced that America’s ways of lawmaking could be greatly improved by borrowing from agile development, which allows people lower in the hierarchy to make consequential decisions rather than being burdened by “waterfall” development, where all the rules have to be specified in advance, leading to deadly (sometimes literally) complexity and policy failure. Give people leeway to implement the intent of the overall policy, she argues, and you can avoid the layers of bureaucracy that stymie well-intentioned attempts at reform. While there’s merit in the argument, she doesn’t give a lot of weight to the reasons that policymakers try to be comprehensive—although the perfect shouldn’t be the enemy of the good, it’s also the case that if you get a policy running that works for 90% of people, the 10% excluded are likely to share some demographic characteristics, and the policy is unlikely to be revisited to fix it for them, which is probably worse when it comes from government than when it comes in private software. I imagine she’d respond that oversight that focuses on implementation success, and flexibility to keep working for that 10%, are the proper solutions.

Still, she identifies important dynamics that can defeat progressive policies, like lack of comprehensive recordkeeping plus relying on individual action to implement expungement of felony records for marijuana offenses in California, or nine different definitions of a “group” of doctors for Medicare purposes. Throwing money at the problem rarely helps (though she doesn’t give much shrift to “lift the restrictions and just do something in blanket fashion, whether that’s sending money to people with kids or implementing universal health care” either). Neither does outsourcing and oversight, both of which can help when properly deployed but often end up with more layers of bureaucracy.

Instead, she argues, teams building tech to implement a policy should have the authority to alter it as they go. They should build something that works at least a bit as soon as possible, shift edge cases to human review, and automate the easy stuff, rather than building software that’s supposed to accommodate all possible situations. This is impossible in many government spaces because following policy is relatively safe; even if you’re yelled at by overseers for policy backlogs or implementation failures, they won’t accuse you of violating the law that requires you to serve everyone.

And the worst part of directives from above, from her view, is that “nowhere in government documents will you find a requirement that the service actually works for the people who are supposed to use it. The systems are designed instead to meet the needs of the bureaucracies that create them—they are risk-mitigation strategies for dozens of internal stakeholders,” even though they fail at that regularly.
This is a special problem for government because people interpret their experiences with bureaucracies as evidence of how government works more generally—involvement with the criminal system, or getting a construction permit, or filing taxes, can be unpleasant enough that it erodes faith in government and deters political participation.

Unfortunately, the problem is also worse in government because obsolete tech is paired with obsolete policies—not just obsolete, but accreted over rounds and layers of attempted reform. One thing Palka, who’s not a lawyer, doesn’t suggest is that new laws should explicitly allow regulators to simplify and even eliminate earlier categories and rules—and there are certainly reasons why we don’t do that, because lots of systems rely on past categories and rules, but accretion keeps making things worse. “Lawmakers were furious at state-level bureaucrats for their failures during the pandemic, but it’s the lawmakers who have insisted on petty provisions like docking a claimant’s benefits because the person had a cold one day.” This example comes from automated systems that, pre-pandemic, docked unemployment payments when the claimant didn’t look for work when they were sick. That rule was supposedly waived, but automated systems couldn’t handle the waiver. (This is an example where it’s a dumb rule in the first place, of course, and more universal safety nets would have had lots less waste and failure.)
In software, agile development allows you to learn from data. But waterfall development uses new data only to grade after the fact. “For people stuck in waterfall frameworks, data is not a tool in their hands. It’s something other people use as a stick to beat them with.” So they naturally aren’t that interested in collecting it.

Another problem: “Even when legislators and policymakers try to give implementers the flexibility to exercise judgment, the words they write take on an entirely different meaning, and have an entirely different effect, as they descend through the hierarchy, becoming more rigid with every step.” She gives numerous examples—again, without too much attention to why that happens, often in an attempt to allow different providers to compete fairly for contracts. (And even if we did less outsourcing, that would help, but we still probably want things like rivets to come from the private sector, so the dynamic would still exist.)

One thing that might be fixable is policymakers’ cultural contempt of implementation. They think/hope/expect/imagine that if they write the right rules, everything will be fine, but it isn’t and won’t be.

Pahlka criticizes the Administrative Procedure Act rulemaking process that most of government uses, because it essentially invites and requires interest group lobbying for every rule and the required process is more like a jury trial than an expert evaluation. Leftists, she argues, got really good at suing the government to stop bad stuff, but that contributed to an environment of risk aversion (and didn’t stop the Supreme Court from harming agency power anyway).

At points she’s pretty clear that there are some no-win scenarios here: Equity usually requires data, which requires paperwork, which favors the powerful. Europe's GDPR privacy regime, for example, caused big tech profits to drop 4.6%, but small tech companies lost over 12%.

So, what should we do? Focus on making things simpler for most people and devote human resources to the tougher situations. New programs should be launched when they’re ready to handle 85% of the cases, though the edge cases should be addressed technologically eventually. (In reality, she notes, policies are launched incrementally anyway, because the systems built under current processes don’t work for a lot of people, but they’re incremental in the worst possible way.) “We can’t fix this until we understand that in government, we’re not starting a new relationship, we’re repairing a deeply broken one.” As one person says of welfare applications, “Every time you add a question to a form, I want you to imagine the user filling it out with one hand while using the other to break up a brawl between toddlers.” Documentation should be required only when needed and responsive to actual circumstances.

Even though it sounds scary and even undemocratic to have a random technologist deep in the hierarchy making important distinctions, she argues, it’s necessary for success of the actual intended outcomes decided upon by elected representatives. This is because, when no one can go ahead and make decisions about how a program should work but lots of people have the power to add requirements to it—as is now the case—you get lots of paperwork and few good outcomes. Good product management can “reimagine representation and voice so as to honor the values our government is supposed to be founded on.”

In addition, attentive to implementation, policymakers shouldn’t enact “policy options that are very hard to automate, like decriminalizing burglaries of property under $950.” If they do that, they have to understand that the program will simply fail unless they also provide time and money for people to go through all the individual files in the relevant jurisdictions.

Here’s a success case that goes through initial problems: when the Biden administration sent out all those covid tests, the postal service just asked for your address. “Each apartment was supposed to act as a unique address, but in a very small fraction of cases, one apartment dweller requesting tests would blacklist other units in the same building.” Turns out, that wasn’t a programming error. “It was that mail carriers had been compensating for incomplete data for decades.” The agile process worked, she thinks: “the team quickly added a little note asking anyone who thought this was an error to fill out a short form, and customer service teams reached out to clarify. It increased the burden on this small number of users, and unfortunately these users were disproportionately of lower income.” But the postal service also updated its database in response, cleaning up about two-thirds of the residential address database as a result.

To further improve things, she argues that the government should spend on improving its human resources, especially program management/operating expenses. And oversight should ask less about whether a team stuck to a plan, but what the team learned in implementation and what user tests are showing now. ( )

This book decribes my job. ( )

Recoding America by Jennifer Pahlka is an eye-opening account of the why behind many of our recent policy implementation failures.

For most Americans, the debate and arguments over policymaking capture our attention. Once something has become law or otherwise become policy, unless it directly impacts us, we just assume it is functioning as intended. Yet far too often even those changes with broad nonpartisan support fail to actually help the people they were designed to help. This book examines one of, if not the, biggest reasons for failure to successfully implement: archaic infrastructure and not enough attention to the nuts and bolts of implementing.

There are many examples and ideas included, but my two biggest takeaways are: focus on people and work on short term attainable goals rather than long term goals that are doomed to be obsolete by the time they are supposed to be complete.

By focus on people, this is more internal than external. The policymakers should, in theory, have the people's interest, writ large, in mind in making policy. But that policy must then be made available to those it affects, and simply adding regulations, oversight, and other long (over)used methods are no longer sufficient. Technical infrastructure, good interdepartmental (and -state, etc) communications and data sharing, and workers trained and empowered to make the changes necessary need to be in place.

The short term focus I mention is not in place of long term goals. But rather making short term, and less expensive, projects that then lead to the next part of implementation. This allows changes in infrastructure to be taken into account as well as the inclusion of lessons learned from one project to be part of the next step. Too many long term single projects lock the workers into software, hardware, and techniques that become obsolete before the project is even complete.

My explanations are over simplified and likely imperfect paraphrases of what Pahlka argues in the book. That said, if you are among the vast majority of people who acknowledge that there is often a problem getting the benefits of policy to those needing it, then this book is well worth your time. Your takeaways may be different, and likely more meaningful to you than how I phrased mine, but the information here is valuable for anyone facing the task of implementing change in any organization in contemporary times.

Reviewed from a copy made available by the publisher via NetGalley. ( )