Last spring, as I was ending my time at the U.S. Treasury as an oversight official monitoring the IRS’s IT modernization efforts, one initiative by the Trump administration gave me hope that progress would be made after I left: trimming federal contracts with large consulting firms.
The indications had been favorable. In early February, the General Services Administration (GSA) told agencies throughout the federal government to review a list of what it described as nonessential consulting contracts. A few weeks later, the GSA took the next step and tasked agencies with reporting all their contracts with any of 10 specific firms. Those on the list included global consulting giants such as Accenture, Booz Allen, and Deloitte. In May, the GSA added nine more firms to the list.
“Based on available procurement data, we have identified the 10 highest paid consulting firms listed below are set to receive over $65 billion in fees in 2025 and future years. This needs to, and must, change,” Stephen Ehikian, the acting GSA administrator, wrote in the February letter. “By March 7, please provide us with a list of the contracts with these firms that your agency intends to terminate and those that it intends to maintain. For any contracts between these firms and your agency that will continue, please provide a signed statement from a senior official verifying that such contract is mission critical and provides substantive technical support.”
To those who have been in federal IT long enough, the GSA’s implication was clear: These companies make billions of dollars off of government contracts for vague services that provide dubious value to taxpayers, and it’s time to rein them in.
I’ve long been an advocate for reversing the tide of government outsourcing. I believe it’s critical for government agencies to be proficient in the design and creation of their own digital tools — a skill that has become essential to an agency’s ability to carry out its mission. So I was encouraged by Ehikian’s letters. Among a set of civic-tech advocates like myself, concerns regarding the high cost of these contracts are secondary to our concerns about the quality of the work they produce. Taxpayers should not have to pay these companies so much for the work they do. But if they are going to pay this much, they at least deserve functional web sites in return.
On paper, the GSA’s effort sounds like the kind of bold reset that many frustrated taxpayers might welcome. Why should government agencies continue to spend billions on contractors who don’t deliver billions in value? Why not reclaim control, rebuild internal capacity, and force agencies to be leaner and more accountable?
The answer is that after decades of dependence on outside firms to do their work for them, many government agencies can no longer even function without them. They are suffering from something called “vendor capture,” and it’s one of the most underexamined barriers to meaningful change in federal operations.
What is ‘capture’?
The concept of capture is typically used in regulatory contexts, in which government agencies are yoked to the interests of the industries and interest groups they’re meant to regulate, preventing them from working in the public interest.
Vendor capture is a parallel concept. It happens when a government agency becomes functionally dependent on a contractor or set of contractors to accomplish its mission. The dependencies go beyond basic support and extend into what are considered “inherently governmental” domains of knowledge, execution, continuity, and decision-making. The vendor uses its influence in the agency to make itself even more indispensable, which allows it to command higher rates, safe in the knowledge that the agency would rather pay too much than face the risks associated with switching vendors.
When the same vendor has maintained responsibility for a critical system throughout its entire lifetime, the prospect of transferring responsibility is frightening: Will the new vendor know how to handle problems on Day 1? Will the data be migrated from one data center to another without any loss? Can anyone guarantee that the system will work as intended once the transfer is complete? Outside government, there are standard practices that ensure the success of such transfers. Infrastructure stacks can be easily cloned and moved from one cloud provider to another. Software tests embedded in the source code run on demand and will notify administrators of any unexpected behavior.
But captured government systems rely on contracts that do not require such standards, and it is not in the incumbent’s interests to voluntarily implement tools that make vendor transitions safe and easy. When leaving one vendor for another is fraught with risk, the agency stops acting fully in the public interest and becomes a vector for wasting tax dollars.
The problem of vendor capture was not pioneered by the 19 vendors on the GSA’s list, nor are they the only firms who benefit from it today. And of course, every firm, including these 19, is capable of doing great work, especially in a noncaptured environment in which they have to perform well to win business. But if the GSA is serious about reducing business with these firms, it cannot safely do so without an honest assessment of vendor capture in all of its forms.
The 3 forms of vendor capture
Vendor capture runs deep and manifests itself in surprising ways. Having worked across defense, intelligence, and civilian agencies, I’ve seen it play out in different forms. Sometimes the various forms of vendor capture coexist. Sometimes one form dominates. But all three require years of effort and a commitment from an entire administration to uproot.
1. Technological capture
This is the most straightforward kind of government vendor capture. It’s when a vendor has complete control of a government IT system, and the government lacks the technical, or sometimes even legal, ability to manage the very system that was purchased with taxpayer dollars. Preventing government access can be done through several technical means. The vendor might claim proprietary rights to software that runs the system, legally barring the government from modifying it. Or the vendor might design the system so that only vendor employees can perform administrative functions, preventing the government from ever seeing the source code or copying system data.
In a sense, a vendor-owned system — often called a ”managed service” in this context — is stored behind a locked door. The vendor has the only key, and it’s not sharing it.
This situation often begins with a contractual failure by the government. When negotiating contracts with vendors, government agencies routinely fail to claim rights to software systems they are paying a vendor to build. In other cases, as with a managed service, the government explicitly asks the vendor to own and administer the entire system, usually to shift the burdens and liabilities that come with running the system.
As these contracts expire, usually somewhere between five and eight years post-award, agencies find themselves trapped: They are eager to adopt whatever new technologies have come along since the contract was awarded, and at the best prices the market can offer. But the current vendor — the “incumbent,” in government contracting parlance — will argue that the system, full of its custom configurations and proprietary software, cannot be handed over to a competing vendor.
Common sense will tell you that the vendor’s use of proprietary code was part of a deliberate ploy to capture the government agency. Deliberate or not, it can take months or years to safely transition a large system from one vendor to another, and key government systems must be continuously operational.
2. Intellectual capture
Whether or not the government has technical permission to access a vendor-run system is sometimes beside the point: If an agency lacks in-house technical staff who know how to manage the system, the agency has been intellectually captured. All of the institutional knowledge of the system’s architecture and day-to-day maintenance lies with the vendor, and even if the government wanted to manage the system itself, it wouldn’t know how.
In my experience, there are two general causes of this form of capture.
First, the government does not hold the vendor accountable to industry standards for IT operations, especially when it comes to ensuring the vendor maintains up-to-date documentation of how their system works. Contractual artifacts like the Quality Assurance Surveillance Plan (QASP) are meant to equip the government with the right tools to oversee vendor performance, but they often fail to do so. In some cases, the government lacks the technical skill to perform certain assurance measures.
For example, if the QASP states that the vendor must maintain an architectural diagram of the system, the government might not have anyone on its side with the technical skill to see when the diagram has fallen out of date or that it is sufficiently vague to prevent anyone but the incumbent vendor from using it effectively.
More often, though, the problem is with the QASP itself. I routinely see QASPs for IT services that lack any mention of technical performance, and instead focus on the administrative aspects of a contract. Rather than stating that all software code must be covered by tests or that it must meet certain accessibility standards, a typical federal IT QASP will hold vendors accountable to little more than submitting a monthly report on time. In one case, I saw a QASP for a key software system with a single line item: a minimum number of billed hours per month.
In effect, the government was saying that high costs alone were ample evidence of strong performance. 18F, the GSA unit that was dissolved in the first weeks of the current Trump administration, had previously published and promoted a vastly improved QASP template for software contracts.
In short, an agency succumbs to intellectual capture when it doesn’t know what it’s doing. If an agency wants to recover its system from intellectual capture, it must do so by transferring system knowledge from the incumbent vendor to the government.
As for the second general cause of intellectual capture, unfortunately system knowledge frequently flows in the reverse direction. I often see agencies that have a few exceptional engineers, people who are more than capable of technical vendor oversight. But these people are often asked to fill this role across several systems, and are, with comical reliability, a year away from retirement. Upon retirement, they have two paths. One path is to truly retire and rest after decades of late nights rescuing critical U.S. government infrastructure from collapse. The other path is to a vendor that wants to win more contracts with the agency. The vendor can offer the engineer a salary far greater than what they were earning with the government.
After the engineer switches sides, the agency is desperate to retain the precious knowledge; very often, critical systems rely on a single brilliant person, without whom the government could not perform critical functions. This allows the vendor who poached the engineer to win yet more contracts with the agency. The engineer then returns to the agency to work on the very same system they used to run as a federal employee. The difference is that they are now working for the benefit of private interests rather than for the public. The vendor now knows precisely how to entrench itself into the agency and technologically capture it.
This whole process takes just a few months from start to finish, and it happens constantly across the government.
You may notice that these two causes of intellectual capture are essentially the same problem: a dearth of technical talent being recruited into public service. This is a decades-old problem that demands its own treatment.
Intellectual capture leads to a behavior that is both troubling and very common: the outsourcing not only of the work, but of the procurement itself. Because a vendor’s perceived knowledge so eclipses that of the government, customers routinely ask vendors to draft the very contractual documents that describe the government’s requirements. The message is: “We don’t know what we’re doing, but we trust you, so please just tell us what you think we should do and how much it should cost, and then we’ll pay you that amount to do it.”
One program manager of a system critical to national security confided in me that no one on his team knew how the system worked, so he wanted to hire a major consulting firm by name to a) figure out the system, and b) modernize it. Another agency, in working with a vendor to acquire safety-critical network hardware for covert military operations, did not know how to evaluate the vendor’s product for cybersecurity vulnerabilities, so it had the vendor write and perform its own test.
The product passed the test.
3. Psychological capture
I once monitored the modernization of a federal IT system that seemed primed for a contract recompete and a transition to another vendor. The existing contract, with a global consulting firm, was expiring soon. The system was relatively partitioned from others, meaning it had few interdependencies with other systems and contracts. The system’s purpose and operation were also relatively straightforward. And in the years since the system had been developed, newer technologies had arrived that, in the hands of a motivated new vendor, could have vastly improved its performance.
Yet when the program’s leaders were asked about the prospect of a new vendor, they spoke about it like a grave national security risk: They could not fathom the idea of anyone else taking over the system. To them, the system and the incumbent were inseparable, even though there was no technical or contractual reason for that to be true.
At the time, agency procurement officials were under pressure to award more contracts to small businesses. This particular prospect sparked a very telling reaction from the program team that I’ll never forget: “Matt, [vendor name] was on the phone with me all night last night fixing a problem. What small business is going to be able to do that?”
Their attachment to the firm had become so great that they exhibited a form of Stockholm Syndrome: When confronted with obvious evidence of the vendor’s failure — the system was crashing — the program staff not only excused the failure. They viewed it as a positive attribute.
When psychological capture sets in, government staff talk about a vendor with great reverence, but in a way that, in conversation, quickly becomes suspect to the astute listener. The February letter from the GSA’s Ehikian specifically targeted consulting-type contracts, in which firms provide vague services like “strategic guidance” and “program support,” and that agency decisions to retain such contracts should be justified in writing by agency heads. In my experience, these are precisely the contracts that government staff are inclined to breathlessly support in writing, yet when pressed in conversation, cannot explain in detail.
And government staff are much more likely to voice blind allegiance to global firms, like those on Ehikian’s list, than any kind of allegiance to smaller ones. In response to Ehikian’s memo, I expect the GSA received many letters supporting the continuation of contracts that provide negative return on investment for taxpayers.
Psychological capture can transcend specific contracts and create a general belief that vendors inherently perform superior work to in-house staff, simply by virtue of the vendors’ apparent commercial success at selling their ideas and products. The circular reasoning seems to be, I may not understand what these contractors are doing, but other agencies have hired them, so they must be good!
In the most egregious case of psychological capture I’ve witnessed, a vendor was attempting to sell fraudulent encryption devices to a military customer. It had even created counterfeit U.S. government documents as part of its influence campaign against program and procurement officers. When a U.S. attorney’s office approached the customer with proof, the customer insisted the vendor was trustworthy in spite of the deception. The U.S. attorney relented, and an Army unit directed millions in funds to a dangerously broken product.
Solving capture
The Trump administration’s objective with the GSA memo is unclear. Some may believe that this administration has no actual desire to make government work better. But based on my experiences in 2025, the motives of many agency-level appointees are honest, and they are making a good-faith effort to streamline federal operations, cut waste, and restore agencies’ abilities to act independently from their captors. The caveat is that this is not a simple matter of cutting contracts; doing so without a multi-year plan would cause massive operational fallout. And again, in spite of what the administration’s priorities may appear to be, I believe agency leaders do not want such a fallout.
What does a multi-year plan for capture extraction look like? Here’s how I would do it.
For technologically or intellectually captured IT systems, immediately modify existing contracts such that they explicitly differentiate critical technical services from ancillary services. Multi-year vehicles, especially those with large consulting firms, tend to encompass a large range of tasks. What appears on the surface to be a “consulting” contract might include an equal amount of making PowerPoint slides and operating systems critical to national security. Allow the incumbent vendor to continue performing the critical services, but with additional tasks requiring that it rigorously document the system and remove any dependencies on its own proprietary tools. The contracting officer should grant contract extensions to the fullest extent possible; this work is not worth rushing, so long as it is being done honestly and to high standards.
To ensure it is being done to those standards, form a system-transition team to watch over the incumbent’s work. This is the most important component of freeing a system from capture. When a contract ends and a new vendor wins the recompete, the two contracts typically overlap so that both vendors can be paid for the time it takes to make a smooth transition. But the allotted time will not be sufficient with a captured system. These transition periods may last only a few months — far too short a time to free a captured system — and the two vendors have conflicting motives. The incumbent has little incentive to set its competitor up for success, and the new vendor will want to capture the system for itself. This is why an independent team is necessary.
The team should be highly technical and have high standards for documentation and code quality. It should have daily insight into the work being done by the incumbent and administrative privileges over the system so that it can rigorously evaluate that work. Before the incumbent’s contract terminates, the team should attempt to fully administer the operational system on its own for a few weeks. If the new team succeeds without any support from the incumbent, it is a sign that the system has been successfully freed. Doing this prior to the termination of the incumbent’s contract is critical. You do not want the capturing vendor to go off-contract without first having ensured that its continued involvement is no longer essential.
In an ideal world, the transition team would be 100 percent federal staff, as there is no better way to capture-proof a system than by making it a purely government operation. Many agencies will not have sufficient in-house staff to do this for every captured system, especially in the aftermath of the Trump administration’s aggressive cuts to the federal workforce. Besides, if there were sufficient federal staff to watch over the vendor’s work to the extent required, the system probably would not have been captured in the first place.
Therefore, you will likely need to outsource this work. Find a vendor that is highly technical and is willing to agree to contractual clauses that restrict future contracting on the system at issue. This will prevent the vendor from competing for future contracts to manage the system, giving you added assurance that it will work purely in the government’s interests rather than capturing the system for itself. The transition team’s period of performance should overlap both the incumbent’s and that of whichever vendor wins the next long-term support contract.
It may seem odd that a strategy for vendor independence relies so heavily on awarding new contracts to new vendors. But as long as the United States government has a dearth of technical talent, it will rely on vendors to do the job for it. The key is to ensure those vendors put the government’s mission and the taxpayers’ money first.
Preventing capture
The effort described above will be a waste of time if rescued systems eventually fall into the hands of a new captor. Federal government agencies are currently extremely vulnerable to this prospect. Every phase of acquisition management, from initial solicitation to system retirement, is skewed to the advantage of firms that want to make themselves indispensable.
There is but one solution to this: Government agencies need to start thinking of their digital efforts as products rather than projects. Under the status quo project-based model, a new system is considered a project, and its creation is funded under a single contract. That contract often calls for a few years of development followed by a few years of operations and maintenance (O&M). Once that contract expires, the project model considers that system complete, and a new contract for ongoing O&M is put out for bid. This repeats for the life of the system. In a world in which only one vendor has had a role in building the system, an agency will feel captured by that vendor in all the ways outlined above, and it will have no incentive to hire a new firm to maintain it.
Under a product model, however, systems are never “done.” New capabilities are continually being developed under contracts that expire, ideally, in shorter cycles, giving agencies multiple opportunities to expose new vendors to the codebase. This has immense value, the benefits of which can only be leveraged if agencies build capture safeguards into their procurement process: specifically, requiring that the government own the source code and documentation.
And none of this is possible without a sustained, determined effort to improve the quality of the federal workforce. Agencies need to radically increase technical talent across a broad range of subspecialties. Procurement and IT staff need stronger intra-agency partnerships that increase collective oversight of vendors. IT and human capital teams need to work together to recruit like the future of the nation is at stake: Stop going to career fairs and stop posting vacancy announcements to USAJobs that are so vague and uninspiring that they only attract people who don’t care how they spend their days, and start using mission as a selling point to overcome the salary gap.
The long pole in this tent — more people with more expertise — seems unlikely to occur in this moment. As much as the administration wants to cut spending on consulting firms, it seems even more eager to attack the civil service. And it can’t have it both ways. The loss of government expertise is the very root of the contracts the administration is trying to cut.
Matthew Burton has more than 20 years of experience as an IT executive, adviser, and contractor for the United States Departments of the Treasury, Education, Defense, and Energy; the Consumer Financial Protection Bureau; and various components of the Intelligence Community.
