Learning From the Legacy of 18F

In March, the U.S. government shut down 18F, the digital services team tasked with modernizing government technology and services. 18F was perhaps best known for helping the IRS create a free direct-file tax website that makes it fast and free for Americans to file taxes. This was part of 18F’s mission to attract digital talent, reinvent how the U.S. government acquired technology, and, equally ambitiously, give it the capacity to place bets and build solutions.

Politicians, public administrators, and members of the public who want their government to effectively use and build digital-era technologies should look closely at and learn from 18F’s legacy. The problems 18F sought to address have not been solved, neither in the United States nor in most other parts of the world. This piece provides context surrounding 18F’s creation and reflects on what did and didn’t work, offering lessons that can guide future digital government initiatives.

The 18F Model: A New Way to Build Government Tech

Launched in 2014 and housed within the General Services Administration (GSA), 18F was the result of both top-down and bottom-up forces. In the shadow of the disastrous Healthcare.gov launch and in pursuit of successes like the U.K.’s Government Digital Service, U.S. government officials recognized the need for stronger digital-era capacities. Jen Pahlka, founder of Code for America, was recruited as a deputy chief technology officer at the Office of Science and Technology Policy, in part to launch this nascent effort. In addition, Dan Tangherlini, the GSA’s administrator, emerged as a champion for building this capability within GSA’s centralized mandate after seeing the value of tech teams using agile, user-focused methods.

Another driver emerged from below. The Presidential Innovation Fellows program recruited talent into the U.S. government, and GSA specifically. Many of those fellows found purpose, meaning, and a genuine need for their work. They didn’t want to leave. There was thus political demand, an increasingly clear need, and a ready pipeline of talent.

The result? A simple idea—build a team of technologists inside the government to work directly with agencies to make government services accessible and available online. In a digital era, if government IT is expensive, slow, and ineffective, then government is expensive, slow, and ineffective. Founded on a few core principles, 18F’s mission centered on the following:

• User-centered design: Build or acquire services based on the needs of the people who use them, not bureaucratic or political requirements.
• Agile development: Deliver a working (even if imperfect or unfinished) product quickly, iterate often, and improve based on real user feedback.
• Open by default: Share code and practices so that agencies can build on each other’s work instead of reinventing the wheel.
• Pathways for private-sector talent: Create models, frameworks, and hiring authorities for bringing technical talent into government.
• Cost-recovery model: Agencies pay for services, so they must demonstrate value.

While these principles guided 18F’s work, its organizational structure and approach differed from other digital government initiatives of the time. Those differences played a key role in 18F’s value proposition.

Indeed, 18F was often compared to (and sometimes confused with) the U.S. Digital Service (USDS), which was created around the same time, with many of the same principles and a similar mission. But the two operated differently. USDS, particularly in its early days, was akin to the Marine Corps. Housed within the White House, it worked with significant political cover, often intervening when assistance was requested, but sometimes deploying without invitation to take on tasks for which it was absolutely needed. As a result of its focus on tackling problematic projects, USDS’s founding culture leaned toward engineering and development, with product and design lower on its list of priorities.

18F was more akin to the Peace Corps. Housed in GSA with a founding culture connected to usability and design, it focused only on issues it was expressly invited to, working alongside agencies, understanding their constraints, and co-designing solutions.

While the two teams occasionally clashed, their different budgets, accountability, and organizational structures were ultimately a source of strength, particularly in a government as vast and decentralized as that of the United States. Over time they came to complement each other: USDS handled urgent crises, while 18F joined projects earlier and prevented future crises. This complementary model suggests that future digital government initiatives might benefit from multiple entry points rather than a single, monolithic approach.

From Advice to Product to Infrastructure

The organization’s ability to incubate ideas and formalize methods, as well as provide a place where technology talent could land in government, are perhaps the most consequential—and least understood—elements of 18F’s structure. They are why dissolving 18F was an odd choice for an administration that both values technology talent and seeks to save money.

Indeed, 18F started saving the government money within weeks of its launch when it integrated FBOpen—a tool created by Presidential Innovation fellows to help small businesses find government contracts—into a government website in under 30 minutes. This was soon followed up by CALC, a tool that helps public servants compare prices for contracts across agencies. The former was important in helping small businesses and increasing competition for contracts; the latter has saved hundreds of millions by making procurement more transparent and directing purchasers to the lowest cost vendors.

These successes were partly a function of 18F’s core principles, but they only scratch the surface of how it operated. 18F’s unique funding structure enabled an evolutionary pathway to scale ideas that had impact—from providing advice, to building products, to ultimately creating shared infrastructure. There was a clear pattern:

1. Consulting with agencies on individual projects
2. Identifying recurring patterns across projects
3. Codifying and publishing reusable tools and advice
4. Building shared products to address common challenges
5. Developing sustainable public infrastructure used across government

This path started with individual projects on which 18F would consult. But working with several agencies concurrently started to reveal patterns, and teams began to codify and publish advice and reusable tools to help their own teams move faster while also providing guidance to teams across the government. 18F’s practice guides enabled teams to deploy a consistent approach, and tools like the U.S. Web Design System (USWDS)—a toolkit of principles, guidance, and code—facilitated a usable and consistent design approach for any government website.

However, codified advice was just the beginning. 18F helped agencies build viable products quickly, iterate often, and test with users. However, various forms of compliance (accessibility, security, privacy, etc.) make setting up even a single-page website within the U.S. government costly—upward of $3-5 million. So 18F began to create products such as Federalist, a platform for quickly launching government websites that met compliance and security standards out of the box. By dropping the cost of creating websites to virtually nothing, 18F reduced its teams’ project times by months and also enabled teams across government to work quickly. Some of the products incubated by 18F—such as Cloud.gov, Login.gov, and the USWDS—would ultimately evolve and be handed over to the Technology Transformation Services (TTS), 18F’s parent department inside GSA, to become public infrastructure—core tools that every agency can rely on and use at scale.

To understand how this evolutionary pathway from projects to infrastructure was made possible, it’s necessary to dig deeper and look at 18F’s funding structure. 18F was funded via a long-term loan from GSA’s Acquisition Services Fund that enabled it to maintain staff but that it had to repay through paid advisory work across government. This cost-recovery business model made it unusual compared to other government efforts to draw in digital talent. Because 18F was beholden to the agencies that it needed to sell its services to, it had to demonstrate effectiveness. For good and for ill, 18F was more dependent on carrots—incentivizing agencies to adopt new digital-era practices—and could not merely beat them with policy sticks in an attempt to enforce compliance (a practice that rarely works and requires significant ongoing political capital).

This approach also gave 18F the freedom to use its loan-funded runway to operate as an innovation center that could pursue longer-term bets. In short, 18F had patient enough capital to scale small interventions into more robust products and potentially into enterprise-wide solutions. This structure—which has both benefits and drawbacks—remains innovative.

GSA had created something special: the ability to create a pipeline for innovation in government. 18F’s sensory capacity to spot trends, its entrepreneurial potential to rethink first principles in how to address identified needs, and its ability to transform ideas into scaled, efficient, and reliable systems operated by TTS in a more bureaucratic tradition were all made possible by an unusual funding model. This is a state capacity worth understanding. It also makes it all the more perplexing why a government would choose to dismantle rather than reform 18F.

Challenges and Resistance

18F’s successes didn’t leave it without challenges. From the start, it faced resistance. Government IT was (and largely still is) dominated by large consulting firms and contractors who benefited from the status quo. The idea that a small in-house team could deliver technology faster and cheaper than billion-dollar contracts was, unsurprisingly, not welcomed by everyone.

On top of that, 18F’s cost-recovery model forced it to continuously sell its services to agencies, some of which were hesitant to embrace new ways of operating. This created a paradox: The team was supposed to make government technology better, but it often had to convince agencies to take the leap first. Some agencies were willing, but others were not. Agencies have long-standing relationships with vendors, and even when those relationships aren’t producing favorable outcomes, it can be easier to stick with the familiar than to take a chance on something new.

In addition, not every bet placed was a good one, and for every project like Federalist (which was eventually integrated as a feature into Cloud.gov), there were others that failed or, like Login.gov, had uneven success. In the private sector, such failed bets are expected; in government, they’re often viewed as wasteful expenditures rather than necessary learning.

The structures that enabled 18F to conduct innovative work were also those that made it vulnerable. Some agencies were never interested in its work, and traditional contractors lobbied against it. 18F was not the bastion of left-wing ideologues some on the right have claimed it to be. But it was filled with people who left the private sector based on the belief that the government can and should create value. The decision to shut it down is a window into how hard it can be to sustain any project focused on innovating in government, regardless of demonstrated impact.

Although 18F is gone, its legacy remains. It confirms what other governments around the world—like the U.K., Argentina, and Brazil—have increasingly demonstrated: that governments can build digital services in-house, and do it well. It introduced agile, user-centered development to agencies that had never worked that way before. It showed that open-source collaboration could work in government. These ideas won’t disappear just because 18F has.

Lessons for the Future

If there’s one takeaway from 18F’s story, it’s that changing how government works is a long game. Bureaucracies are slow to adapt, and entrenched interests push back against reform. But the need for better government technology won’t simply go away.

So what should future efforts take from 18F?

• Governments need to be effective buyers of technology. To do that, they need talent that understands the technology they are buying. Given the fast pace at which technology evolves, having the ability to pull outside talent in is one way to maintain this capacity.
• Governments can build great technology in-house. While most technology should be bought, governments should maintain the option to build because sometimes it is the right choice and because it provides leverage over vendors. But they need the right structures and leadership support to sustain it. 18F proved this with projects like Cloud.gov, Analytics.USA.gov, and Direct File.
• Cost-recovery models can be limiting. Some core funding and a departmental mandate are necessary to allow for long-term transformation. 18F’s need to continuously sell its services sometimes prevented it from addressing the most critical needs.
• Political and cultural resistance is real. Successful digital teams need strong champions at the highest levels of government. 18F flourished under supportive leadership but became vulnerable when that support waned.
• Digital expertise should be embedded across agencies. Rather than centralizing talent in one team, agencies need to build internal capacity. 18F’s most lasting impact may be the digital skills it helped spread throughout the government.

The next iteration of digital government services in the U.S. should build on 18F’s foundations while addressing its limitations. The question isn’t whether the government needs this capability—it’s how to structure it for lasting impact. 18F may not have always gotten it right, but it proved that new approaches were both possible and effective.