Why DOGE’s meddling at Treasury could have catastrophic consequences for the US economy

Earlier this week, inexperienced officials from Elon Musk’s Department of Government Efficiency (DOGE) gained administrative access to the core payment systems at the US Treasury’s Bureau of the Fiscal Service (BFS). Like many Americans, I was shocked. Unlike most Americans, I am in a professional position to understand the potential for catastrophic macroeconomic consequences far beyond the privacy and security concerns suggested in the media and by our elected representatives.

One of the officials with admin access to the Bureau of the Fiscal Service was 25-year-old engineer, Marko Elez, who is unlikely to have experience in the arcane, aging COBOL programming language (dating back to 1959) of the bureau’s payment system, and who meets DOGE’s recruitment criteria of having the hunger to make change. Unfortunately, the line between impatience and recklessness is not clear-cut, and any missteps could upend the entirety of public expenditure in the United States.

Elez resigned from DOGE today over allegations of racism, rather than professional competence. His replacement is just as unlikely to have the kind of experience and temperament required to work with the most mission-critical systems in the United States government. DOGE has stated that it wants to recruit risk-takers who want to “fundamentally remake the federal government” at all costs.

In my professional opinion, it’s only a matter of time until DOGE’s meddling inadvertently triggers a catastrophic failure of Bureau of the Fiscal Service systems, and the damage may not be reversible, if the safeguards required to run a secure, reliable system have been bypassed. Revoking DOGE’s administrative access to the BFS payment systems and restoring the systems to a known safe state is a sensible, bipartisan action that voters and their representatives on both sides of the aisle should agree on.

For more than 15 years, I have been a practitioner of Site Reliability Engineering (SRE), the discipline of making software reliable, scalable, and adaptable. As an employee, advisor, and investor, I’ve worked with software companies ranging from five-employee startups to behemoths like Google/Alphabet. I’ve authored books on Site Reliability Engineering practices and served multiple times as editorial chair of conference proceedings for our field. And, once upon a time, I was a 20-year-old, hot-headed new hire at Google determined to make her mark upon the industry and the world, hungry to make an impact.

Google allowed any engineering employee to propose changes to almost any system, subject to peer review and phased deployment, so I wrote code beyond my ordinary duties to improve Google Maps and shared systems that the entire company used. Not all my changes passed initial muster, but patient senior engineers on the responsible teams mentored me, so my contributions could be accepted.

In the wake of the chaotic launch of President Obama’s healthcare.gov initiative, many of my Google colleagues volunteered for the all-hands-on-deck effort to fix it and for the United States Digital Service (USDS) organization that came afterwards and brought industry experts into government. When they returned from their assignments, they impressed upon their colleagues how crucial it was that government systems stay reliable. One United States Digital Service alum shared with us that if the Centers for Medicare and Medicaid Services (CMMS) delayed in submitting its list of approved reimbursements by just 48 hours, it could shave several percent from the US GDP for that year as hospitals failed to make payroll and doctors’ offices closed. That statement stuck with me as an example of how government IT systems can have unexpectedly large ripple effects on American citizens’ daily lives.

I have spent a decade encouraging engineers to test their software in production, performing final validation of proposed changes in the real live serving systems—but with measuring and controlling for risk as part of the equation. According to the “testing in production” philosophy, there are diminishing returns to attempting to exhaustively test changes in pre-production staging environments; increased maturity comes from better controllability and observability of the places where the running code affects real users.

But testing in production does not mean skipping staging environments entirely—or the unit tests, peer review, observability, and circuit breakers that could limit potential harm. I have been assigned many times as a change agent to improve the productivity of existing teams but have never bypassed their controls while doing so. It is crucial that existing change-control processes be followed and reformed to improve efficiency, once outside change makers gain a better understanding of which controls are the most effective.

I have taken risks and gotten egg on my face for breaking production as an enthusiastic but inexperienced developer. But the only damage was to my ego; no one was harmed because I worked within the bounds of change control, and our systems at Google had sufficient safeguards to undo my mistakes. Unfortunately, government financial systems are not nearly as forgiving, and the methods that young DOGE engineer has reportedly employed to make changes directly to live environments without testing or review go far beyond the pale, in my opinion, even for the “move fast and break things” community epitomized by the early Facebook. But even Facebook/Meta ended up changing its motto to “move fast with stable infrastructure.” When the United States economy is at stake, stability ought to be the overriding virtue.

Individual engineers experimenting directly upon real, live systems without first validating their changes or seeking peer review violates every best practice for controlling risk in the industry. Elon Musk says he wants to run the government more like a business, but no business operates this way. For instance, every public company must implement Sarbanes-Oxley (SOX) controls to ensure no single developer can tamper with their financial data and systems. The vast majority of private software companies adhere to Service Organization Control Type 2 (SOC2), and the government’s own Authorization to Operate (ATO) protocols, which likewise prescribe testing processes and forbid employees from unilaterally making changes. These practices ensure safety and reproducibility, which enables software engineering teams to move faster with confidence.

Experts like me train employees to act within their scope of knowledge and to seek assistance when working in unfamiliar languages and codebases. We practice code review and graduated deployment strategies to ensure that we catch errors as early as possible, before they impact too many users. It is an affront to industry best practice on risk management to suggest that the best way to reform a piece of software is through unilaterally making untested changes.

If and when one of DOGE’s changes—or an unforeseen interaction between its code and normal business processes—triggers a malfunction, all payments could fail to be disbursed—not just those that Elon Musk and President Trump disapprove of, but to all payees and creditors of the United States. Medicare reimbursements could fail to go out on time, causing hospitals to shut down and patients to suffer. Social Security checks and tax refunds could not go out. Department of Defense civilian employees and troops could go unpaid. Federal contractors, including Musk’s SpaceX, may not receive payment for their services. Even worse, an “unintentional operational default on United States treasury securities” might come into effect.

This scenario is orders of magnitude worse than the potential Medicare payment delay that my Google colleagues worked to avert as United States Digital Service volunteers during the Affordable Care Act rollout. Worst of all, the Treasury collapsing would be a deliberate, self-inflicted wound against United States national security, rather than an unforeseen circumstance. Recent legal consent orders that limit DOGE workers to reading but not modifying records within the payment database are insufficient. The risk is ongoing, so long as any recently-added and untested code is still live in production, or if DOGE workers can push new code to indirectly alter the databases without contravening the legal orders.

Providing visibility into government payments does not mean granting an insufficiently supervised individual or group the ability to delete the entire American economy with one misplaced keystroke. Americans may have voted to reduce government waste, but they certainly did not vote to roll the dice on a catastrophic collapse of our economic system. I urge the House and Senate to assert their oversight authority. and appeal to President Trump to rein in Elon Musk before the inevitable catastrophe occurs.