PDF Summary:Recoding America, by Jennifer Pahlka

Government digital services often fail to meet citizens' needs, leading to frustration and inefficiency. In Recoding America, Jennifer Pahlka examines why government technology projects so frequently fall short and what can be done to fix them. She argues that the root problems stem from outdated development processes, rigid bureaucratic requirements, and a fundamental disconnect between policymakers and the people who use government services.

Pahlka outlines principles for effective digital service delivery, including the importance of user research, agile development methods, and building internal technical expertise within government. She explains how aligning policy creation with technical execution, simplifying complex regulations, and prioritizing citizen needs can transform how government operates in the digital age. This guide offers a framework for modernizing government services to better serve the public.

(continued)...

In this section, we’ll explore core principles and practices of digital service delivery, as well as the organizational and leadership foundations required for digital transformation.

Core Principles & Practices for Delivering Digital Services

Pahlka argues that user research is essential for effective digital service delivery. It’s a discipline that encompasses qualitative and quantitative methods, such as observation, interviews, surveys, and analysis of usage data. Research into user needs is vital for developing consumer internet products, and it's probable that nearly all the software products you currently use were crafted based on its results. This research is employed to ease the demands of applications and create more streamlined, user-friendly services.

(Shortform note: User research for digital services has its roots in human factors engineering and cognitive psychology. These disciplines emerged in the mid-20th century, focusing on how people interact with complex systems and tools. Researchers studied how to reduce errors and mental workload in tasks like operating aircraft or nuclear power plants. This laid the groundwork for understanding how people process information, make decisions, and interact with technology.)

However, Pahlka points out that for a long time, doing research with users has been regarded as nearly unlawful within the federal government. The Paperwork Reduction Act of 1980 requires federal agencies to get permission before collecting any information from the public. This has been seen as applying to all occasions when a federal department seeks to question anyone from the public, essentially prohibiting user research. Getting authorization typically takes half a year to three-quarters of a year and involves a researcher submitting beforehand every single question they intend to ask. Even though the Act technically excludes most user research, many federal officials opt to be cautious and still require approval. By the time permission is granted, the initiative the research was intended to guide will inevitably have progressed. Digital services will be constructed or altered without an understanding of the problems users encounter.

The Paperwork Reduction Act

In Rulemaking, Cornelius M. Kerwin and Scott R. Furlong explain that Congress passed the Paperwork Reduction Act in response to concerns about the sheer volume of information the federal government was collecting from the public. Congress wanted to ensure that the government was collecting only the information it needed, and that it was doing so in a way that was efficient and not overly burdensome to the public. To achieve this, Congress required that all information collection requests be submitted to the Office of Management and Budget (OMB) for review and approval. This allowed OMB to maintain a central inventory of all information collection requests, and to ensure that they were necessary and not duplicative. However, this requirement has had the unintended consequence of making it difficult for federal agencies to conduct user research, as Pahlka describes.

Another principle Pahlka emphasizes is that well-considered service design can simplify complicated workflows. Service design is the process of converting policy into a practical service. It can simplify complex processes for users and officials. However, legal and policy considerations often overshadow service design, complicating even straightforward interactions.

(Shortform note: Service design can make complicated workflows easier to navigate by providing a clear, visual map of the entire process. For example, a service blueprint can show every step a user takes to access a government service, from initial contact to final resolution. This visualization helps teams identify unnecessary steps, redundant handoffs, or confusing touchpoints that complicate the process for both users and officials.)

We’ll also explore modern methodologies for developing online offerings and the application of user-centered practices to public sector services.

Modern Methodologies for Digital Service Development

Pahlka argues that the agile methodology offers a more flexible and user-centered approach than the traditional waterfall model. The waterfall model is a linear method for software development that consists of several sequential stages: gathering requirements, planning, execution, testing, and upkeep. Separate groups oversee each stage, and after finishing one, you don't revisit it. In contrast, agile development embraces evolving requirements, even in the later stages. It emphasizes frequently delivering functional software, with collaboration between developers and business people every day during the project.

The waterfall model is still widely used in governmental settings, yet it has led to many failed projects. Agile development emerged as a response to the shortcomings of the waterfall methodology. It prioritizes fulfilling users' needs by consistently providing useful software from the start. Agile methodologies focus on users and lead to superior software, content users, and more satisfied developers.

The Origins of Agile Development

The agile methodology was formalized in 2001 with the publication of the Agile Manifesto, which outlined the core values and principles of agile software development. The manifesto was created by a group of 17 software developers who were frustrated with the limitations of traditional software development methods, particularly the waterfall model. The manifesto emphasized the importance of individuals and interactions, working software, customer collaboration, and responding to change. It also introduced the concept of iterative and incremental development, which involves breaking down a project into smaller, manageable pieces and delivering them in short cycles. Larman and Basili argue that agile development is not a new concept, but rather a rebranding of iterative and incremental development practices that have been used since the 1950s. They suggest that the key to successful software development is to treat each iteration as an experiment, using feedback to refine and improve the product.

Utilizing Citizen-Centric Practices for Public Services

Pahlka argues that prioritizing citizens' needs in design can improve government services. This approach centers policy development around citizens' needs. It helps government agencies understand the problems citizens face when using government services.

(Shortform note: The political scientist Elinor Ostrom was a pioneer in advocating for the active involvement of citizens in the design and delivery of public services. In her 1996 article “Crossing the Great Divide: Coproduction, Synergy, and Development,” Ostrom argued that public services are more effective when citizens are involved in their design and delivery.)

Organizational and Leadership Foundations for Technological Shifts

To develop digital competency in government, Pahlka believes it’s necessary to invest in people. This means training and supporting current employees, recruiting new talent with digital skills, and assigning user-focused public servants to impactful roles. These civil servants should be connected across disciplines. Pahlka acknowledges that this will be a lengthy, hard process, and developing proficiency will require time. It will necessitate many thousands of individuals across national, regional, and local governments to adjust and acquire knowledge. They'll need to incorporate a new capability into the essence of their duties and include technologists in decision-making.

(Shortform note: While Pahlka advocates for upskilling thousands of government officials and giving technologists more influence in decision-making, this approach could backfire if not carefully managed. In Automating Inequality, Virginia Eubanks warns that when governments automate public services and social welfare through data-driven systems, they risk embedding existing social biases into code and infrastructure. This creates a new “digital poorhouse” that hides and intensifies inequality behind a veneer of neutrality and efficiency. Without strong equity and accountability guardrails, efforts to build digital expertise in government could end up hard-wiring discrimination into systems that are difficult to challenge or reform.)

Typically, government leaders have viewed implementation as secondary and have misunderstood the digital age as simply changing the tools used in implementation. But implementation can't be separated from policy. The experience of those using the service is just as crucial to a program's success as its governing rules. For most individuals, digital tools are synonymous with policy. Politicians lack motivation to develop 21st-century state capabilities. They're not reelected because they simplify the labyrinth of regulations, policies, and laws that dictate how services are delivered. They don’t campaign to change how government finances and supervises tech projects.

Implementation as “Quiet Politics”

Political scientists have long recognized that politicians have little incentive to overhaul how services are delivered. In the field of comparative politics, Pepper Culpepper coined the term “quiet politics” to describe policy areas that are low in voter salience but high in technical complexity. In these domains, organized interests and bureaucratic actors wield disproportionate influence because the public pays little attention. This dynamic creates a vicious cycle: Politicians avoid tackling complex implementation issues because they don’t generate headlines or votes, while insiders resist changes that might disrupt their established roles.

Pahlka also argues that simplifying policies and supervision can enable effective digital transformation. The government’s approach to digital transformation suffers from a tendency to add more rules and oversight, which creates a complex web of regulations that stifles innovation and hinders progress. Oversight bodies judge tech projects based on how well they stick to the initial plan, which encourages teams to focus on meeting demands rather than delivering working software. This approach doesn’t produce software that serves people. The best solution is to ensure public servants are responsible for outcomes rather than processes. We must rely on government employees to make intelligent compromises that satisfy individuals' needs.

The Downside of Simplifying Policies and Supervision

While simplifying policies and supervision can help digital transformation, it can also create problems. In Street-Level Bureaucracy, Michael Lipsky argues that when public servants have more discretion, they may treat different groups of people unequally. He explains that public servants often have to make quick decisions with limited resources, so they use shortcuts and stereotypes to manage their workload. This can lead to unfair treatment of certain groups, even if the public servants don’t intend to discriminate. For example, a caseworker might spend more time helping clients they find easier to work with, while giving less attention to those who need more help.

In this section, we’ll explore the importance of building internal digital capacity, as well as aligning policy, vendor management, and execution.

Building Internal Digital Capacity

Pahlka believes that establishing internal digital capabilities is crucial for effective government modernization. Some tech companies and private sector advocates argue that government should rely solely on external vendors for digital solutions, claiming this strategy is more efficient and cost-effective. However, the United Kingdom's Digital Service shows the advantages of having a central digital team within government. GDS successfully streamlined services and reduced reliance on large external contracts.

Internal digital expertise allows governments to make informed decisions about technology procurement, manage projects effectively, and ensure that digital solutions align with public needs. Without this capacity, governments risk becoming overly dependent on vendors, leading to higher costs, less control, and services that may not align with users' requirements.

The Limits of Internal Digital Capacity

While internal digital capabilities are crucial for effective government modernization, there are situations where this approach may not be feasible or optimal. In Digital Government, Darrell M. West argues that for many small jurisdictions and public agencies, maintaining a large, highly skilled IT staff is unrealistic due to budget constraints and limited access to technical talent. In these cases, shared-service arrangements or carefully managed contracts with private vendors can be a rational strategy for obtaining sophisticated digital services. The key is to ensure that these external partnerships are governed by clear performance metrics and accountability structures to prevent the issues of vendor lock-in and misaligned incentives that Pahlka warns against.

Aligning Policy, Vendor Oversight, and Execution

Pahlka also argues that aligning policies, vendor management, and execution requires dialogue between those who make policy and technical groups. This is because policy is often unclear, sometimes expressing goals without specific guidance, or offering excessively precise orders that may not achieve the actual policy aims. The time, organizational, structural, and cultural divides between policy and tech teams, as well as tech teams and the tech's users, complicate efforts to experiment with strategies, understand effective methods, clear up ambiguities, and make adjustments.

(Shortform note: In The Transformation of Governance, Donald Kettl argues that many of the time, organizational, structural, and cultural divides between those who make policy and technical groups arose from 20th-century reforms that separated policy design from operational execution. These reforms aimed to insulate policy decisions from patronage and political interference, but they also created a fragmented system in which the people who decide what government should do are often organizationally and institutionally removed from the public and private organizations that actually administer programs.)

Conversations between policymakers and technology groups yield better results than directives. To converse and prevent unintended mistakes that might derail the project, you should involve the implementers at a much earlier stage of the process. They ought to have the ability to voice their opinions on topics once seen as beyond their remit. You should also find resources that enable everyone to communicate in a shared language. The dialogue is bidirectional. Everyone benefits when policymakers can explain to programmers what they intended, instead of leaving them to make their best guess. Opportunities for innovative solutions increase when digital teams gain a better grasp of policy areas.

Participatory Design and Shared Language

The idea of involving implementers in the design process and creating a shared language between policymakers and technologists has roots in the Scandinavian participatory design tradition. In the 1970s and 1980s, Scandinavian researchers and labor unions collaborated to develop new technologies for the workplace. They organized collaborative design sessions where system developers and workers could discuss their needs and concerns. This process helped create a shared understanding of the technology and its potential impact. In their book Participatory Design, Schuler and Namioka describe how these sessions led to the development of new concepts and terminology that bridged the gap between technical and non-technical participants.