I want to talk about DOGE and federal IT systems from a technical perspective, not a political one. The politics are loud and I’ll leave those to others. What I’m interested in is what the DOGE story reveals about the state of US government technology, what happens when you move fast without understanding legacy systems, and what sustainable modernization actually requires.
This is not a political post. I have thoughts about the tactics used, and they’re technical thoughts.
The State of Federal IT Before DOGE
To understand what happened, you need to understand what federal IT actually looks like. It’s not one coherent system. It’s decades of accumulated technical debt, siloed agency systems, COBOL mainframes that process Social Security payments, Oracle databases from 2001, and custom applications built by contractors who are no longer under contract.
Some statistics that give a sense of the scale:
- The federal government runs over 7,000 IT systems
- Many agencies run payroll on systems older than most of their employees
- The Social Security Administration processes millions of transactions daily on COBOL
- The IRS has systems dating to the 1960s still running
- Federal IT spending has historically been 80% “keep the lights on” vs 20% modernization
This is not because government IT professionals are incompetent — it’s because migrating a system that processes $1 trillion in benefits payments is genuinely terrifying, funding cycles don’t align with multi-year modernization efforts, and the political risk of a failed migration outweighs the technical debt of running what works.
What DOGE Did and What Happened
DOGE reportedly gained access to a range of government IT systems quickly, including Treasury payment systems, personnel databases, USAID systems, and others. The stated goal was to identify waste and reduce spending.
From a technical perspective, what was concerning:
Access control violations: Granting broad read (and in some cases write) access to systems that handle PII, financial transactions, and national security information without going through proper access control processes is not just bad practice — it’s illegal under laws like the Privacy Act, FISMA, and various OMB guidance.
Personnel without clearances in classified-adjacent systems: Federal systems that handle sensitive data have clearance requirements for a reason. Those requirements exist because sensitive data represents attack vectors for foreign adversaries.
Rapid system changes: Reports of DOGE personnel making changes to Treasury payment systems raised immediate concerns. In a financial system, an unauthorized change is not just an IT problem — it’s a potential fraud event, an audit problem, and a systemic risk issue.
No documented change control: Federal IT is supposed to follow change control processes that document what was changed, who changed it, and why. Rapid uncontrolled changes to production systems is how you introduce bugs — or backdoors.
What Proper Government IT Modernization Looks Like
Here’s the thing: the US government does desperately need IT modernization. Many systems are genuinely broken. The SSA’s claims processing takes too long partly because of legacy systems. The IRS’s inability to handle digital returns well is a real problem. VA systems for veterans’ benefits are a legitimate scandal.
But sustainable modernization requires:
Strangler fig pattern: You don’t rip out a COBOL system that processes Social Security payments. You build a new system alongside it, gradually routing traffic to the new system, validating equivalence, and then decommissioning the old system. This takes years, not weeks.
Legacy System → API Layer → New System (gradual migration)
↓
Validation Layer (ensure equivalence)
Data governance: Before you touch federal systems, you need to understand what data they hold, who has legal access to it, and what the retention requirements are. Federal PII has strict handling requirements.
Proper access control: Every system access should be logged, justified, and reviewed. The NIST Cybersecurity Framework and FISMA requirements exist specifically to prevent unauthorized access to federal systems.
Change management: Every change to a production government system should go through a formal change control process. Not because bureaucracy is good, but because federal systems process payments, benefits, and services that real people depend on. Unplanned downtime has real consequences.
Security review: New code or configuration on federal systems should go through security review. Not optional. Not a formality. These systems are targets for foreign adversaries at a level that commercial systems are not.
The Actual Waste Problem
Here’s where I have some sympathy with the stated goal, if not the execution. Federal IT does have genuine waste problems:
Duplicative systems: Multiple agencies running separate systems for the same function (HR, financial management, etc.) is expensive and creates interoperability problems.
Contractor lock-in: Agencies are sometimes locked into vendor contracts that prevent modernization. A contractor whose contract includes operating a system has a financial interest in that system never being replaced.
FITARA compliance gaps: FITARA (Federal IT Acquisition Reform Act) was supposed to improve IT governance. Implementation has been uneven.
The $100B maintenance budget: A huge proportion of federal IT spending goes to maintaining systems that should have been replaced years ago. The cost of inaction is real.
These are legitimate problems worth addressing. The question is whether addressing them through rapid, uncoordinated access to production systems is the right approach — and technically, it clearly isn’t.
What I’d Actually Want from Government IT Reform
If I were consulting on federal IT modernization:
-
Audit everything first: Catalog all systems, their purpose, their data, their dependencies. You cannot optimize what you don’t understand.
-
Targeted decommissioning: Identify systems that can be turned off without affecting active services. There are almost certainly federal IT systems no one uses anymore.
-
Shared services acceleration: The federal government’s shared services initiatives (cloud.gov, Login.gov) are the right direction — replace agency-by-agency systems with modern shared platforms.
-
Procurement reform: Federal IT procurement is broken. Fixed-price contracts for software development don’t work. Agile procurement reforms have been tried with mixed success but are the right direction.
-
Proper security: Any modernization effort needs to be done with security as a requirement, not an afterthought. The federal government is a high-value target.
Conclusion
Federal IT is a genuine mess that needs genuine attention. The problems DOGE nominally intended to address — duplicative systems, wasteful spending, contracts for systems no one uses — are real.
But the way you fix mission-critical government IT is not the way you’d close a startup that isn’t working. Government systems process Social Security payments, veterans’ benefits, tax refunds, and federal employee paychecks. When these systems have problems, real people’s lives are affected.
As an IT professional, what I saw in early 2025 was what happens when people who understand how to move fast in commercial software try to apply that philosophy to systems where the cost of failure is measured in disrupted benefits payments, not missed sprint targets.
You can move fast. You can cut waste. You can modernize. But you have to understand what you’re touching first. That’s not bureaucracy — that’s engineering.
