18F: Why acquisitions matters
5 March 2025
So starting with Regan in the 1980s, the federal government began a long campaign of excising any internal expertise that might also be found in the private sector. The result has led to a world where the federal government can't do much of anything without hiring a contractor. This is a problem for the obvious reasons: 1) vendors cost more, not least because of corporate overhead and profit margins; and 2) vendors have an incentive to builds things that are only just barely good enough, to keep the contracts and the money flowing. But those aren’t the only, or even worst, problems.
Prior to Regan, "good enough for government work" was a compliment. It reflected the high-quality of work produced by the federal government. But Reagan and conservatives of his era and since decided to ridicule the civil service and deny its ability to function. So today when people say "good enough for government work," they generally mean it's half-assed but technically sufficient. Not exactly a ringing endorsement.
Government work, however, has still been good. I recall a few years ago a section of I-20 through central Mississippi was being resurfaced. Naturally, the work was contracted out. (States followed in the federal government's footsteps with outsourcing critical duties.) When it was finished, a state inspector came out to check the work. It was wrong, and the contractor had to rip it up and do it again, at no additional cost. That inspector is an example of how good government work is, when government has the expertise to do and/or properly oversee the work.
But the gutting of expertise across government has meant that government has also lost the ability to judge what is good and what is bad. If you don't know what a proper road surface is supposed to be – what angle it slopes off at, how high it piles above the ground, etc. – how can you inspect it to know it was done properly? You can’t.
In the software world, things were even more dire. The explosion of software into the government world began AFTER the purging of expertise, so there was no long wind-down as experts slowly retired or left federal service. Instead, it has been difficult from the very beginning.
Contracting officers ("1102” in gov-speak; these are the only people allowed by law to obligate the federal government to contracts) never got to work with software engineers to learn how to write a contract for software deliverables. So they did the natural thing and wrote the contracts for software much like they would anything else.
The trouble is that software, unlike a bridge or a road or a tank, is infinitely malleable. Good software projects (and therefore, contracts) should take that into account.
One of the great things 18F did was recognize acquisitions as a major issue for tech modernization early on, and it created an acquisitions unit by late 2015 to focus on that problem in particular. We developed a series of hypotheses for how software procurements could be structured and executed to increase the likelihood of success. We ran our experiments with our partners, and... we found success.
Our method was straightforward: we work with a partner agency to understand and scope the problem to be solved. We’d show them how to peel back that onion to get at the core issues their users are dealing with. Then, we’d start building a solution with them. This was a long process, because we weren't just building software – we were also building product owners who understood the systems they were building, executive sponsors who saw the value in the systems, and an agency culture of steady, visible value delivery. Our first deployment was always exciting, just a few days or weeks into an engagement. Even more exciting was when we slipped into a cadence of semi-weekly product demos, showing new features. Everyone could see that it was working.
Meanwhile, we would also be talking to the agency acquisitions specialists. We'd have them in the product team as much as they were able, so they could see how we worked and could participate. Then when the partner agency was ready, we'd work together to prepare the solicitation to ask vendors to come finish the work. At this point, our partners knew how to manage a software project, they knew what "good" looked like, they knew how to ask probing questions. They knew about short iterative development cycles, and they knew how to put that into contracts. They knew what to look for in a good vendor proposal and what to be wary of.
This was one of the great strengths of 18F. We didn't just build stuff. We built expertise. We helped agencies regain the competence they were robbed of from the 1980s onwards. The great story of 18F is less about the software we created and more about the resiliency and expertise we helped other agencies find in themselves.
If you want a more efficient, effective government, you can't do that without doing what 18F was doing.