This Is What Happens When Governments Build Software

Episode Summary

Executive Summary: The episode argues that government software failures are less about “bad tech” than about policy, procurement, budgeting, and organizational design. Guests Jennifer Pahlka and Dave Guarino explain how top-down requirements, one-off funding, rigid RFPs, weak internal capacity, and legacy policy layers produce brittle systems. They highlight unemployment insurance and COVID-era successes as proof that iterative, user-centered, continuously funded approaches work better.

Main Topics: Why government software fails (Priority: 5/5): Government systems often break because agencies translate policy into massive requirements lists, then hand them to vendors in a one-shot build model that prizes compliance over usability. Procurement and vendor selection (Priority: 4/5): RFPs can effectively exclude innovative vendors by demanding prior experience with identical systems, leading to a small pool of large incumbents and reinforcing mediocre outcomes. Policy over product management (Priority: 5/5): The guests argue that public-sector technology is treated as implementation, not product design, so tech teams lack authority to simplify rules or change requirements based on user testing. Budgeting and the one-time project mindset (Priority: 5/5): Government commonly funds big replacements and then shifts to minimal maintenance, whereas modern software requires continuous iteration, staffing, and learning after launch. Unemployment insurance as a case study (Priority: 5/5): California’s UI system exposed how decades of policy accretion, manual identity checks, and underinvestment made pandemic-scale demand nearly impossible to handle. Internal capacity and hiring constraints (Priority: 4/5): Even when governments want to improve, slow hiring, rigid civil service processes, and weak in-house expertise prevent them from making timely product and technical decisions. Signs of change and successful examples (Priority: 3/5): Examples like COVIDtest.gov and New Jersey’s labor department show that government can ship fast and iteratively when it has internal capacity and a simpler, outcome-focused mandate.

Key Arguments: Government software failures often reflect bad requirements gathering and procurement incentives rather than purely technical incompetence. RFPs tend to encode every imaginable rule and compliance checkbox, producing systems that technically satisfy contracts but do not work well for users. Requiring vendors to have built identical systems before narrows competition so much that agencies often end up with the same large contractors. Modern software should be treated as a living system requiring continuous iteration, not a one-time project followed by maintenance. Policy design is inseparable from software design; if the underlying policy is convoluted, the software will be too. Unemployment insurance became unmanageable during COVID because the system relied on manual identity verification, legacy processes, and staffing models that could not scale quickly. Internal capacity matters as much as outsourcing: governments need enough in-house talent to define goals, test products, and challenge bad requirements. The biggest bottleneck is often hiring speed, not salary alone; if it takes months to hire, talented candidates disappear before joining. Successful public-sector tech needs product management authority to arbitrate trade-offs among compliance, user experience, and technical feasibility. Better accountability should focus on whether people can complete transactions and get outcomes, not merely whether agencies checked every procedural box.

Data Points: Stock Movers report length: 5 minutes or less - Promotional intro for Bloomberg’s short-form podcast product Claims processor tenure: 17 years / 25 years+ - A California unemployment insurance worker described as the new guy after 17 years; the most experienced staff had 25+ years of knowledge California modernization RFP requirements: 6,700 requirements - Jennifer Pahlka cites a state business system modernization RFP with roughly 6,700 requirements Federal hiring timeline: 9 months - Pahlka says it can take about nine months to make an offer in federal government California UI surge staffing: 5,000 people hired - Dave Guarino says California hired 5,000 people to help process claims during the pandemic Translation file size: 50 megabytes - Guarino describes a government site loading one huge translations file Translation load delay: About 1.5 minutes - The same government site blocked interaction while a translation file loaded COVID test site launch: 1 day early - COVIDtest.gov launched ahead of schedule after being announced for six weeks out COVID test site usability: 11 seconds - Pahlka says the site took about 11 seconds to use, with others reporting 8–15 seconds Veterans health form latency definition: Under 2 minutes - A VA leader defined latency as acceptable if responses took less than two minutes Veterans suicides per day: 18 per day - Pahlka references the number of veterans committing suicide daily at the time UI modernization funding after Great Recession: Several billion dollars - Pahlka says states received significant funds for modernization after the Great Recession States modernized after Great Recession: About half - She notes roughly half the states technically modernized then, but none outperformed average in the pandemic Customer experience executive order: Mentioned as ongoing policy - The episode closes by noting President Biden’s customer experience executive order

Pivotal Quotes: "the technology systems are part of a larger socio-technical system" — Dave Guarino: Explaining that software problems are intertwined with staffing, policy, and operational rules "if you tell us to build a concrete boat, we'll build a concrete boat" — Jennifer Pahlka: Describing a culture where IT staff avoid challenging bad requirements so they can avoid blame "It has to make sense to a person" — Jennifer Pahlka: Arguing that policy and software should be simplified around real human use, not just formal compliance

Implications: Listeners should see public-sector tech as a policy and management problem, not just an engineering one. The path forward is simpler rules, stronger in-house teams, continuous funding, and iterative product development focused on real user outcomes.