We Need Policy Implementers, Not Policy Makers
Why the United States can’t buy technology.

This article is part of an ongoing project by American Purpose on “The ‘Deep State’ and Its Discontents.” The series aims to analyze the modern administrative state and critique the political right’s radical attempts to dismantle it. Click here to subscribe to Francis Fukuyama’s blog and American Purpose at Persuasion to receive future installments into your inbox!
My last piece for Persuasion argued that large numbers of small, autonomous platforms—airborne and naval drones—would become an increasingly large part of 21st century warfare, and that their spread would be blocked by our current addiction to large, complex, expensive platforms like aircraft carriers, F-35 fighters, and Abrams tanks. This addiction is part of a much larger problem, which is the way that U.S. government agencies buy hi-tech products in general. Our difficulties buying technology is related to the other problem I’ve written extensively about, which is our failure to build infrastructure.
Government agencies procure software in the same way that the Air Force buys fighter jets. A government office starts drafting a “request for proposal” (RFP) to build a new product. This RFP is then sent around to interested agencies for comment, and it is here that the first big problem occurs. The list of requirements multiplies like rabbits, with each unit adding its priorities to the list. Those requirements may be individually justified, but there is generally no lead authority to set priorities and knock requirements off the list in the interest of cost or effectiveness. Oftentimes, the requirements are driven by a particular interest group with friends in Congress who make sure that their pet issue is covered.
This gold-plating problem has been recognized for years in defense procurement. The F-16 fighter, which over the decades has proven to be one of the most useful aircraft in the inventories of many countries, was initially sidelined because it was too simple. The Navy didn’t like the fact that it had only one engine, and the Air Force wanted a larger, heavier airframe for the range of roles it envisioned. It required special lobbying by General Chuck Boyd and his “fight Mafia” to convince Congress to support a lightweight plane like the F-16.
Something similar happens when civilian agencies procure software. They act as if they are buying a single big product that will be good for at least the next decade or two. The list of requirements grows into a large, complex contract. The actual RFP and bidding process are regulated by the Federal Acquisition Regulations, a document spanning hundreds of pages of detailed requirements that mandate things like seeking bids from female- and minority-owned businesses and the like. The contractor finally selected is empowered in turn to produce the product with relatively little ongoing input from the procuring agency, and the software package is delivered after a lot of time has passed.
The problem with this approach is of course that technology moves way too fast, and many of the original requirements are already outdated by the time the product is delivered. Moreover, the contractor focuses on fulfilling the contract rather than interacting with eventual users to modify requirements on the fly. Government agencies that have bought big software packages under the old procurement model have run into huge problems. These include the FBI, the IRS, the State Department, and of course the biggest debacle of the past generation, the Department of Health and Human Services procurement of healthcare.gov under Obamacare.
Companies in the private sector buy large software packages as well, but the process is often very different. Software is usually introduced in alpha or beta forms where users can begin interacting with it, and only after a period of feedback is version 1.0 ready. That version, however, is expected to have bugs and require fixes, fixes that occur continuously over the succeeding months and years based on immediate user feedback. The software designer is more of a service provider that maintains the software rather than a builder who produces a single product.
Part of the problem is lack of technical capacity at the procuring agency. The government needs to be able to interact on a continuous basis with users of their services, and know enough about the technical design to be able to recommend changes to the software provider. This in turn is related to a different problem, which is the separation of implementation from policymaking, and the significantly higher prestige attached to the latter activity.
People who go into government want to be policymakers. They want to be the ones who roll out the new healthcare benefit or passport system or small business subsidy. Since many officials are short-term political appointees, they aren’t going to be around to see how their innovations are implemented. Public policy programs in the United States reinforce this mindset; they train young people interested in going into government to be policy makers, not policy implementers. The latter is a lesser activity that can be hived off to a contractor.
I saw a vivid example of this problem recently. A student of mine who had gotten an MBA from Stanford went to work for the Small Business Administration. She found that the SBA’s website was not particularly user-friendly, so she took it on herself to fix it since she had a decent tech background. Her supervisor told her that fixing websites was the job of contractors, and that she would never get promoted doing such menial work.
The truth of the matter is that implementation is part of policymaking; if a policy can’t be properly implemented, it shouldn’t be rolled out in the first place since it will simply contribute to the narrative of ineffective and incompetent government.
The Defense Department and the Armed Services need to change their procurement model as well and move away from thinking about big once-in-a-decade or once-in-a-generation technology acquisitions. If the U.S. military is going to move towards small, inexpensive autonomous weapons, it needs to open up the bidding process to the thousands of startups that can contribute. It needs to behave more like the Ukrainians. The latter have developed a domestic drone industry on the basis of continuous feedback between operators in the field and the people who write the software and design the platforms. In the current war with Russia, software gets updated every few days, or sometimes within hours of an engagement.
The Ukrainians, of course, are engaged in an existential battle for their freedom, in which the life of their compatriots will depend on fast interaction. The challenge for the United States is to develop a similar sense of urgency when we are not actively engaged in a hot war. If we wait until that war comes, it will be too late.
(For a fuller elaboration of this problem, please see the Niskanen Center report by Jennifer Pahlka and Andrew Greenway The How We Need Now: A Capacity Agenda for 2025 and Beyond.)
Francis Fukuyama is Senior Fellow at the Freeman Spogli Institute for International Studies at Stanford University. He writes the “Frankly Fukuyama” column, carried forward from American Purpose, at Persuasion.
Do you know anyone else who would like to receive Francis Fukuyama’s regular writing straight into their inbox? Please spread the word by sharing this post.
Follow Persuasion on Twitter, LinkedIn, and YouTube to keep up with our latest articles, podcasts, and events, as well as updates from excellent writers across our network.
And, to receive pieces like this in your inbox and support our work, subscribe below:
The difference between policy makers (mostly elected) and policy implementers (mostly employees and appointees) is so important and so overlooked. Thank you for bringing it into better focus. While I am skeptical of Donald Trump (a policy driver), I am hopeful that the folks at DOGE (neither elected nor employees, nor even lawful government appointees interestingly) do understand the fundamental role of implementation better than most in government.
But with respect to the first fine point about procurement, I think one important and central problem gets left out, which is most prominent in the software side of things. I've worked both in large government and a large non-profit, and in each case they faced a nearly identical problem that massive and long-lasting organizations have when it comes to software: legacy systems. I would estimate that about 90% of the insoluble problems in both contexts came down to the desire to upgrade to something more sensible, butting up against the reality of legacy systems that had been used for decades, and which were both incompatible with a newer system, and unchangeable because of long reliance and integration with other systems in the organization.
I don't know if this will fall into the DOGE portfolio, but I would expect that the tech industry participants will also be familiar with this problem in implementation that touches on much of what the entire administration will have to face: Trump's desire to do the right thing vs. the facts on the ground.
Very interesting take on the problems with our government procurement of weapon systems, and just systems in general. The example of Ukraine’s approach with respect to drones and drone software elegantly highlights the downsides of the US’ archaic approach.