Elon is Running into Process Debt, I mean, the US Government
- Chris Terrell
- Dec 6, 2024
- 3 min read
If you’ve ever tried to renew a driver’s license, file taxes, or pick a health plan without crying into your keyboard, you know bureaucracy has a special gravity. It bends time, energy, and good intentions. So when someone like Elon shows up with a five-step playbook—make processes less dumb, delete steps, simplify/optimize, accelerate, then automate—it sounds like rocket fuel for government.
It also sets him up to collide with a system engineered to resist rockets.
Here’s the tension. Those five steps work beautifully when you own the org chart, the checkbook, and the roadmap. Buy a company on a Friday; delete a layer on Monday; ship a change by Wednesday. In government, you inherit two centuries of accreted ritual: legislation layered on regulation layered on court precedent layered on agency guidance. You don’t delete steps; you convene committees to discuss if deleting steps would violate four other steps.
But that doesn’t make the steps wrong. It just changes the order of operations and the expected timeline.
Start with “make processes less dumb.” That’s not a punchline; it’s a mandate. Ask, “What are we doing that’s obviously wasteful?” Nearly every agency has forms that duplicate fields, reviews that add no quality, and reports no one reads. In a business, you grab a whiteboard and fix it. In government, the whiteboard needs a charter, the charter needs a comment period, and the comments need a response memo. Still worth doing—just slower, with more documentation, and with an eye toward the downstream statutes that created the upstream nonsense.
“Delete steps” is where reality bites. In a private company, you can collapse sign-offs to a single accountable owner. In government, sign-offs often exist because a law said they must. So instead of “delete,” think “consolidate evidence.” Keep the approvals, but build a single ritual that satisfies all of them at once. One briefing, one docket, one packet that covers the statutory bases. Same spirit, legal wrapper.
“Simplify/optimize” is the sweet spot. This is where service design shines: collapse multiple portals into one front door; pre-fill forms with data the state already has; swap PDF uploads for structured fields; publish status like a pizza tracker. None of that requires Congress—just product leadership, inter-agency cooperation, and ruthless attention to the citizen journey.
“Accelerate” is tricky because speed in government is a political choice. The system was designed with friction on purpose—to prevent fast, dumb, consequential mistakes. So the goal isn’t “move fast and break things,” it’s “move steadily and surface risk early.” Think of acceleration as cadence: short cycles, visible queues, predictable releases, and metrics that track wait time, rework, and abandonment.
Only then “automate.” And only what’s stable. If a rule changes quarterly or involves judgment calls, automation becomes a fragility multiplier. The test I use: will the underlying rule and responsible owner be the same in 18–24 months? If yes, automate the plumbing. If not, keep a human in the loop with great tools and clearer guidance.
Zooming out, this is classic process debt. Over decades, institutions accumulate workarounds that once made sense (grandma cut the ends off the ham because the pan was small). Eventually the pan gets bigger—but the ritual remains. You don’t fix that with a flamethrower; you fix it with a framework:
Prescriptive: write the current best way (in plain language).
Ritual: decide the cadence and the “report” that proves it worked (artifact, metric, or decision).
Repeatable: once the ritual reliably produces the outcome, consider acceleration and then automation.
Elon’s five steps aren’t wrong; they’re incomplete without the constraints. In government, the real skill is translating decisive product thinking into accountable public practice.
Process Debt Truth: Systems don’t stay complicated by accident; they stay complicated because no one owned the ritual that would keep them simple.



Comments