The DOGE debacle, part 1

A former USDS engineer on why government systems can’t be updated with a “full rewrite”

A team meeting at the US Digital Service. This photo is, as of publishing, still the banner of USDS.gov, a now functionally defunct website after the staff was mostly fired and replaced by DOGE.

Upon Elon Musk’s takeover of Twitter in 2022, he quickly decided that the entire Twitter codebase needed a “full rewrite.” The code, as he saw it, was so grotesque that it was not salvageable — only by firing most of the staff and deploying a new, clean codebase did Twitter have a hope of surviving.

When he stood up the Department of Government Efficiency (DOGE), Musk took the same approach to the federal government. Firing thousands of workers, he declared that the old ways of operating were so outdated and full of waste that only a fresh approach could fix them. By bringing in fresh technologists who could build new, more useful products, DOGE — according to Musk — would deliver a government capable of providing the same results for 15 percent less cost.

The parallels between Musk’s Twitter takeover and DOGE’s slashing of the federal government workforce are well-known. But — this should hardly need to be said — the federal government is nothing like a social media company. Its systems are many orders of magnitude more complicated. When Trump took office there were about three million federal employees, about 430 times bigger than Twitter when Musk took over. Hundreds of millions of Americans rely on the government for everything from healthcare and social security checks to economic stability to safe food, drinking water, and air travel.

If a social media platform breaks, people can’t post their hot takes. If the federal government breaks, the consequences are dire: National security is endangered and lives are at risk.

That’s part of why, as past reformers have learned the hard way, government efficiency requires a totally different approach than private companies. But Musk paid no attention. His approach to two agencies in particular, the United States Digital Service (USDS) and 18F (a branch of the General Services Administration), reveals a disastrously naive strategy to reform — but also what a genuine vision of what making government work better would look like.

What were USDS and 18F?

USDS and 18F, although living in separate parts of the executive branch, were tasked with broadly similar goals: helping the government move faster and more efficiently in the digital age. Each was a designated team of technologists, designers, and engineers whose sole job was modernizing the federal government to be more effective.

If DOGE had been a good-faith effort to improve efficiency, it should have been their natural ally. But instead of bringing in additional resources to bolster their efforts, Musk fired most of the staff. The guides that 18F wrote to empower government agencies to write more cost-effective software contracts? Gone. The expertise of USDS engineers who could clear backlogs in complicated datasets? Lost. It was Musk’s “full rewrite” in bureaucratic form.

Perhaps DOGE believed that USDS and 18F were just another set of stodgy government agencies, moving too slowly to make any real difference. What the government really needed, they thought, was a nimble, tech-savvy agency that could disrupt the old way that things worked in Washington. “We’re doing things differently. We are entrepreneurs, not politicians,” Musk wrote in the Wall Street Journal. He vowed to hire “some of the sharpest technical and legal minds in America” in pursuit of his mission.

The great irony here is that USDS and 18F themselves were meant to be disrupters when the federal government stood them up 13 years ago. After the debacle of the HealthCare.gov rollout, the Obama administration decided to bring in tech workers from Silicon Valley who could quickly build products to help the government operate more efficiently. At the time, the tech industry was in full disruption mode: “move fast and break things” was Facebook’s memorable motto. When they arrived at 18F, the DOGE liaison even admitted that the agency was the “gold standard” of government efficiency work.

But, as USDS and 18F discovered, moving fast and breaking things is not the path to achieving efficiency in government. In order to get things done at the federal level, you need to understand where the bottlenecks in the current system lie, meaning you need buy-in and trust from agency leaders and staffers. Simply trying to replace an existing, mission-critical system without taking the time to understand why it works the way it does is bound to fail. Failure, in this case, doesn’t mean that a website is down — it means disruption to critical government services. USDS and 18F learned that the disruptor model is simply not effective at streamlining government operations. That’s why they pivoted away from it.

In the case of Twitter, Musk has stopped talking about his “full rewrite” directive. To experienced tech-watchers, this was no surprise. The cliché of an executive demanding a full rewrite, only to realize that it is a bad idea, is so well-known that software engineers were writing about it 25 years ago! DOGE is going to learn the same lesson — if it hasn’t already. Musk’s ability to bend reality to his will may extend to his acolytes at Tesla and xAI, but it cannot change the fundamental rules of how complex systems work, whether it is a codebase or a bureaucracy.

That’s why DOGE hasn’t delivered on its promise of greater government efficiency: It was doomed to fail from the start.

---

To help us understand why taking a careful, process-driven approach is necessary when modernizing government, I spoke with Greg Novick, a software engineer who worked at USDS for the past four years.

Our conversation, which follows and has been edited for clarity, was illuminating.

Tell me a little about how you ended up working at USDS — what drew you to this work?

I spent more than 15 years in big tech and helped build products that became incredibly pervasive, but also ushered in things like social isolation and the spread of misinformation. Over time I learned about the work at USDS and was in awe of how members of the agency used their skills as technologists to bring about incredible positive impact for the American public. It became clear to me that public service was a way for me to leverage my skills and experience to have the type of impact I was searching for.

Describe for me, if you can, what a typical project might look like at USDS?

There were no “typical” projects because every agency we worked with had different needs and was trying to address unique challenges. But a few things were generally true: We first sought to understand the nature of the challenge, then build iteratively alongside our agency partners, and finally chart a course for the agency to carry the work forward.

It is so tempting to assume that the problem you were sent to solve is exactly as stated, or that the solution you presupposed is certainly the correct one, but that is never the case. One of my favorite USDS core values was to “design with users, not for them.” We would always start by talking to users — whether those are agency staff or members of the public — to understand exactly what they were experiencing so we could better understand the pain points, bottlenecks, or other contributing challenges. Sometimes we might discover that the problem we were asked to solve was less urgent than another problem we uncovered and we’d pivot. Without truly understanding users’ needs, you might build a technology solution that doesn’t solve the problem or just results in an operational challenge (high call center volume, for example) rather than streamlining processes.

All the while, we were either briefing or directly including agency partners in our work. Agency civil servants are the absolute experts in the programs they administer and the systems they own. It’s a significant understatement to say that government programs are complex, and nobody understands both the nuances and the reality of day-to-day operations better than the agency staff.

It was always critical that we work alongside the agency team to benefit from their knowledge and experience, but also to make sure they were able to carry our collective work forward. There are innumerable challenges to solve and we would inevitably need to move on to the next one, so working in partnership with agency teams would enable us to build the technical capacity of the team to own the work in the long run.

You’re describing a careful process — getting feedback, iterating, communicating with leadership, and so forth. Why not just go the DOGE route and come into an agency guns blazing?

Building trust with the agency staff is so, so important. As I mentioned, they are the experts. Without their partnership, any solution we might attempt to build was destined to either solve the wrong problem or fix the problem insufficiently.

For example, there are very complicated databases underlying many government programs, and many of them have evolved over decades and don’t at all resemble the way you’d build that same database if you started from scratch. Often in these agencies there is a person (or if you’re lucky, a handful of people) who are responsible for fully understanding the data in these databases and generating whatever reports are needed by the agency. If I came into an agency and demanded access to the production database so I could run my own reports from that data without consulting the agency experts, I would surely misinterpret the way data is represented and draw incorrect conclusions.

Further, if we didn’t build trust with the agency team and moved forward by building something that they weren’t bought into, when we needed to move on to our next projects, whatever we left behind would simply wither. It is like an organ transplant that is either accepted or rejected by the body — if the solution was rejected by the agency, we haven’t solved anything.

Of course, the agency experts need to still be around in order to take this approach. If they’ve all been fired or encouraged to take a deferred resignation as DOGE has done, that knowledge is gone.

According to public reporting, DOGE is in the process of pivoting away from cutting the workforce and towards building apps to make the government run more smoothly. Presumably, these will be similar kinds of projects to those that USDS did. It strikes me that they’re going to end up learning the same lessons you already did.

Building technology in government is so different from building in a tech company. I was fortunate to benefit from the wealth of experience that had been passed down through the 10 years of USDS. When I started at USDS, my peers who had been doing this work for a while taught me how to successfully engage in the work. Most of USDS is gone now, but my understanding is that those that remain also haven’t been consulted thus far anyway.

Government services are often a lifeline when people are in most need — disability benefits, food assistance, disaster assistance, healthcare. There are incredibly critical systems that run programs like these that are in need of significant modernization. But it is really important to not lose sight of the fact that in the end, these systems serve people. I’m sure you can quickly build a new replacement system that gets a few things right, but the gaps will mean lots of people probably aren’t getting the services they need, or they’re getting the wrong benefit. The opposite approach would be taking incredible care, spending years building a new system that meets all of the program needs, but that means it is going to take years to realize any improvement (and likely, by the time you’re done, what you’ve built will be in need of modernization again).

If you care about delivering the services people deserve, starting small and learning as you go, rather than trying to wholesale replace systems, is the only way to make sure you continue to provide services as you improve them.

It seems DOGE is aiming to connect different datasets (such as those from the IRS and DHS). Good idea or bad idea?

There are legitimate reasons to want to share data across agencies, and there are ways to do this without violating the Privacy Act. DHS and DOJ, for example, together administer various immigration functions, so it might make sense for them to develop specific data sharing agreements to provide those services.

That said, there’s good reasons not to compile a mega dataset (or at least to take care — and follow the law — when doing so). Data has differing levels of sensitivity that require corresponding protection measures. Personally identifiable data should require different consideration than statistical data, for example. Agencies individually manage the access to their data based on their sensitivity and internal procedures. When you merge data together, it becomes harder to control access at a granular level and to protect it sufficiently based on how sensitive it is. Further, as a dataset grows, it becomes much more valuable to scammers and foreign adversaries, making it more vulnerable to breaches (and increasing the impact of any breach).

What you’re saying is that in the short term, they may get some wins, but it will cause long-term damage.

I expect we will see short-term mistakes and long-term impact, as well. Modernizing systems that administer government services isn’t a one-and-done project. Policy and technology both evolve, and we deserve government services that keep pace. The traditional approach of building a government system via a large contract that’s managed by nontechnical agency program staff results in a product that is stale already on the day it’s finished, and likely doesn’t meet users’ needs. Similarly, a temporary tech team can quickly build something new in a silo, which might serve the needs of some, but certainly not all. Who will be around to update it when the law changes, problems with the system cause unmanageable call volume, or a downstream service provider’s API changes?

The real solution is hiring career technologists into government agencies who partner with program experts and vendors that are contracted to build iteratively based on user research. USDS and 18F were one source of this talent, but we also spent countless hours interviewing technologists to place them within agencies.

Sadly much of the progress of that generational effort has been wiped out, but the needs of the public remain.