A Brief Autopsy of the Federal Government’s Perpetual Reinvention Industrial Complex
There is a specific kind of childlike wonder and optimism that only exists in circles of “federal government digital transformation.” It is the the kind optimism that announces itself loudly, in Canva-styled LinkedIn event promotions, for conferences with names like “GovTech Forward” or “FedFuture Con 2026.” These conferences and their names deserve, at least for creativity in naming conventions (check out that double entendre), some appreciation for their enthusiasm.
I’m not saying this to be cynical for the sake of being cynical. I’m also not saying this because I’ve given up on the machinery of American government. I’m saying this as someone who has spent now six years watching the machinery work. Metaphorically, I understand why the load-bearing walls of this system cannot do the things that many people are saying they can do. Or more accurately, I understand why it would be unwise to remove the load-bearing walls while there are still people living inside this structure.
The argument being made, across virtually every federal agency with a budget and a PowerPoint template, goes something like this: “Silicon Valley figured something out. Let’s do that.” It is a seductive argument. It is also, structurally speaking, roughly as coherent as combining chicken and sushi. I love chicken. I also love sushi. The allure of fusion restaurants is something that isn’t lost on me. Tex-Mex is a good fusion concept. It has been wildly successful. I can also say that Tex-Mex is probably successful because it’s barely fusion. Texas used to be Mexico. Fusion of two ideas can work if they are not fundamentally remote and distant from each other.
For the same reason Tex-Mex works, the inverse is true for chicken sushi.
Both are fine. Both have their contexts. The intersection of the two is achievable, technically. But you only get to execute that experiment once before the results clarify the wisdom of the enterprise.
I. The Structural Fallacy: Why Competition Is the Point and the Government Is Explicitly Not Competing
If you want to understand how societies process fundamental shifts in culture, you must observe that memory and mythology are not the same thing. A culture’s understanding of its own transformative moments is often less a record of what happened, than a record of what people need to believe happened. The same principle applies, with hilarious accuracy, to the mythology of government digital transformation.
The mythology goes like this: Government is slow and broken because it hasn’t adopted the tools and mindsets of modern technology companies. The cure, therefore, is to import the tools and the mindsets. Hire engineers who think like engineers at Google. Build products like Stripe builds products. Move fast and, if not break things, at least tolerate a reasonable amount of brokenness in the service of iterative improvement.
This is a perfectly coherent theory of organizational change that fails, in practice, for reasons that are not accidental but structural. To put it bluntly: This strategy fails for reasons that will not yield to better management, or more talented hires, or more enthusiastic leadership retreats.
Here is the core problem: The innovation culture of the American technology sector is, at its foundation, a byproduct of competition. This isn’t competition that is designed to look like competition to win a government contract. This is actual competition. Competition as a specific and merciless environmental pressure that punishes stagnation with nearly instant death. BlackBerry, Yahoo, Myspace, Motorola, Compaq, AOL, Netscape, Pets.com, Webvan, Commodore, Kodak… the list goes on and on. If you fail to compete in tech, if you fail to push to the absolute limit, innovate, and be at the bleeding edge, you will die.
Amazon did not build AWS because Jeff Bezos “needed digital transformation.” Amazon built AWS because their survival, and the survival of every underlying technology that powered their business, was continuously under threat from entities who would have happily eaten their market share with alarming speed. Amazon built AWS because they were trying to sell everything on the internet faster than anyone else, and their infrastructure required these services. Those services did not exist, and so they innovated them into existence.
Upon creating these services, they realized that these services had value. They then became a web services business that happened to have a bookstore.
Upon taking over eCommerce, AWS fully vertically integrated, complete with their own logistics, because their competitor Wal-Mart was not going to stop building more stores, and integrating their supply chains. In this ruthless environment, the best technology portfolio wins.
The federal government does not operate under this constraint. It cannot. The IRS is not losing users to a competing taxation platform. The Patent and Trademark Office does not have a startup competitor disrupting the filing of intellectual property applications with a sleeker UX and a freemium model. The Department of Defense is not losing command-and-control contracts to a rival defense operation that offered better sprint velocity and a stronger product roadmap.
This is not a criticism of government. This is a description of how sovereign governance is supposed to work. The government’s monopoly over its core functions is a feature of a unified, solitary government. Your state DMV is inefficient not because the DMV’s leadership lacks vision, but because the DMV has never, for a single quarter of a single fiscal year, feared losing market share to a competitor DMV. If you genuinely want to make the DMV efficient, (and I mean actually, structurally efficient, not “we put a chatbot on the website” efficient) you would need to allow competing entities to process driving licenses, collect the fees, and live or die by their operational performance. This is a genuinely insane and idea. We’d see tech companies lobbying to lower the legal driving age. We’d then see lobbying to increase the cost of a driver’s license, perhaps with a monthly fee associated. Privatizing services and rendering competition in a market is not always the answer. I like paying for my driver’s license once every half a dozen years, thanks.
But I digress.
Competition is the only mechanism that has ever, historically, produced the kind of relentless efficiency that Silicon Valley evangelists are pointing at when they say we should do that.
To want the efficiency without the competition is to want the chicken without cooking it. You can imagine chicken sushi, but you cannot have it. (Alternatively, once again — you can. Once.)
II. The Talent Problem: “Ain’t nobody gonna take that pay cut.”
I’m going to say this once and do it in a way where I try not to sound like an asshole: The best software engineers in the United States are not going to work for the federal government at the GS-14 pay scale, which tops out around $170,000 a year, in the Washington, D.C. metropolitan area, where the median home price is somewhere between “wow” and “get the fuck outa here.”
This is not a judgment about their character, or their patriotism, or their sense of civic obligation. It is the math of someone who lives here, and can only afford to live here because I have a side hustle as a TikTok creator. If I was not also an influencer, I would not be working with the federal government. Why? For the same reason that top professional athletes do not accept reduced pay simply because they like the way the jersey looks.
A senior software engineer at a top-tier technology company, the kind of engineer whose way of thinking about problems produces genuinely novel outcomes, who can hold an entire system architecture in their head and navigate its failure modes before they occur… this person is making somewhere between $300,000 and $600,000 in total compensation. Often more. Much more, if you’re counting the vesting schedules. This engineer works from wherever they choose to live, because their employer understands that talent is not geography.
The federal government is asking that engineer to accept a compensation cut of somewhere between fifty and seventy percent, relocate to one of the most expensive housing markets in the country, work in an office five days a week, and navigate a bureaucratic environment where the very changes they’ve been recruited to make are, structurally, nearly impossible to make. In exchange, they receive the knowledge that they are serving their country. This is a genuine and meaningful thing. It is not, for most engineers with families and mortgages and student loans and a demonstrated ability to earn serious money, anything to take seriously as a career consideration.
The people who apply for these roles, and they are often talented, often genuinely mission-driven people, are making a sacrifice. The tragedy is that the sacrifice is frequently not rewarded with the opportunity to actually do transformative work. What they find, upon arrival, is an environment where the infrastructure for experimentation does not exist, where the latitude to try something new is constrained by contractual obligations that predate their employment by years, and where the changes they want to make would have downstream impacts on contractors operating under three and five year agreements that were written before anyone thought to hire a person like them.
They are recruited for transformation and deployed for maintenance. The disillusionment that follows is not merely a personnel problem. It is a predictable and structurally determined outcome.
III. The Contracting Environment: The F-35 Should Not Be Procured Like Software, and Vice Versa
I’m going to make an argument that sounds obvious when you hear it in your head, but for some reason, the architecture of Federal Acquisition Regulation has made this almost impossible: The F-35 and a command-and-control software system are not the same kind of thing, and treating them as the same kind of thing, for procurement purposes, is a profoundly stupid idea with real operational consequences.
The F-35 is a piece of hardware. Once you have locked in the design of the airframe and committed to the supply chains and the subcontractors and the manufacturing tolerances, you have made a set of decisions that are extraordinarily difficult to reverse. It is unlikely, as I understand the current state of materials science, that a breakthrough in, say, carbon fiber composites in year three of the production run is going to require a fundamental redesign of the wing surfaces. The requirements are fixed because the physics are fixed. You design for the physics you know.
Software is not like this. Software exists in an environment of continuous and accelerating change. The commercial tools available to a development team in year two of a contract may be fundamentally more capable than the tools available when the contract was written. New approaches to the problem (better tools, better frameworks, better ways of thinking about the architecture) emerge on timescales measured in months, not decades. A fixed-requirements contract for software is, in this sense, a machine designed to produce technical debt. It is a commitment to building the second-best version of a thing because the first-best version didn’t exist when the paperwork was signed.
The federal acquisition system does not currently make a meaningful distinction between these two categories of products. The same basic framework, fixed requirements, defined deliverables, option years structured around the original scope… These govern both hardware and software.
This is not because the people who designed the system were foolish. It is because the system was designed for a world in which the primary objects of acquisition were physical things, and physical things behave more like F-35s than like software. The system has not kept pace with what the government now needs to acquire.
The result is a procurement environment that is simultaneously too rigid and too slow to enable the kind of adaptive development that modern software actually requires. And into this environment, we are thrusting engineers who have been trained in a professional culture built entirely around adaptive development, agile methodology, the ability to pivot when new information emerges, and then wondering why they aren’t able to transform anything.
Gee shucks, I just can’t figure out why building planes and writing code are so different.
IV. The Diagnosis
I’m choosing my words carefully here because precision matters when we are trying to show the difference between a useful critique and comfortable cynicism. Comfortable cynicism tends to eschew accountability.
The people launching these “government at the speed of tech” programs are not stupid. Many of them are genuinely motivated by a desire to improve the functioning of government, and that desire is legitimate and valuable. The engineers they recruit are not mediocre. Many of them are talented, committed, and capable of the kind of work they’ve been promised the opportunity to do. I have worked alongside these people. They are smart people.
The problem is structural. It is putting a person who is a genuinely excellent swimmer into a pool that has been drained. The swimmer is not the problem. The pool is the problem. And telling the swimmer to try harder, to bring more enthusiasm, to embrace the culture of swimming… none of that fills the pool. To roughly quote Nigel Tufnel: The majesty of Stonehenge tends to be lost, when it is in danger of being crushed by a dwarf. Engineers are being invited to visit Stonehenge, but when they arrive, they realize they’re at a scale reproduction of Stonehenge that is two feet tall.
Structural transformation of the kind that would actually enable the government to operate with genuine engineering excellence would require these three things to all happen simulatenously.
- Compensation reform that allows the government to compete, at least partially, for top technical talent.
- Procurement reform that creates different frameworks for software versus hardware acquisition.
- A genuine willingness to accept that improving a system may require disrupting the contractual arrangements of people who are currently employed by that system.
These are not technical problems. They are political problems. They are social problems. They are problems that require legislation, appropriations, and a political will to absorb the friction (and job losses) of genuine change. Building a new office with a cool name and a mandate to “innovate” is not the same thing as solving these problems. It is, in many ways, a way of appearing to solve these problems while leaving the underlying structure entirely intact. It is “Transformation Theater.”
V. A Word About Chicken Sushi
The reason I return to the analogue of chicken sushi is that it captures something specific about the nature transformation theater that sounds reasonable unless you know anything about food safety. Chicken is good. Sushi is good. The argument that their combination represents an opportunity has a surface logic that is difficult to immediately refute. But I assure you, if you try this fusion of ideas, the refutation will arrive later, and it will arrive with some force.
Digital transformation in the federal government is not a bad idea. It is a correct and necessary idea that is being pursued in a manner almost perfectly designed to produce the worst possible version of its outcomes: Burned-out engineers, taxpayer money spent on initiatives with impressive names and minimal structural impact, and (perhaps most damaging) a generation of talented people who entered government service with genuine enthusiasm and left with a comprehensive and well-earned understanding of why nothing changes.
The government is not a tech company. It cannot operate like a tech company. And no amount of “inviting tech leaders into the room” is going to change that. What we do in government is not the same as what they do in tech. Government should not try to operate like a tech company. What it should do (what it must do), if any of this is going to mean anything, is do the harder, slower, politically costlier work of changing the actual structures that determine how it operates: How it pays people, how it buys things, how it allows those things to change over time.
The change is not a conference. The change is not a recruitment drive. The change is not a branding exercise. The change is the actual work. Everything else, however enthusiastically packaged, is chicken sushi: Technically achievable, always inadvisable, and capable of only producing destruction.