FM-05: Normalized Workarounds
A pattern. The workaround was temporary. It became the system.
Justin R. Greenbaum · The Lexicon · June 2026
On day three, a new analyst is told to ignore the documented close process and follow a spreadsheet a senior colleague maintains by hand, because the documented process stopped matching reality years ago. A billing operations lead is the only person who knows the nightly sequence that reconciles two systems nobody ever integrated, a sequence that runs every night and appears in no runbook. An automation team’s project to digitize an approval flow keeps stalling on “edge cases,” and the edge cases turn out to be the actual operating process; the documented flow is the exception. A team’s numbers hold steady the week their most experienced coordinator is on leave, until the third day, when three handoffs she had been silently absorbing start failing in sequence.
None of these people are failing. Each one is holding a piece of the system that no design holds.
This has a name. It is Normalized Workarounds.
Here’s the pattern. Temporary fixes, exceptions, and informal sequences become permanent operating infrastructure. The formal system stops being the source of truth, and the organization can no longer tell the difference between how the work is supposed to happen and how it actually happens. Stability comes from memory, not architecture. The system stops improving and starts surviving on accumulated human patches, and the people holding those patches look, from the outside, like the most capable people in the building.
Endurance masquerades as resilience. The person who “just makes it work” is praised for ownership. The team that absorbs a broken handoff every week is called adaptable. The tribal knowledge that keeps a fragile process alive is filed as institutional strength. The workaround that should have been a two-week fix is, three years later, called how things work in the real world. The signal the system reads is resilience. The condition underneath is a system that has quietly stopped being designed.
What Normalized Workarounds gets mistaken for is what makes it durable.
Resourceful people. Strong ownership. Tribal knowledge. Operational maturity. Each is a hero narrative, and each is how the system rewards the behavior that is hollowing it out. Praising the person who makes it work removes any pressure to fix what they are working around. Documenting the workaround blesses it as the standard. Onboarding new hires into the workaround scales it. Building automation on top of it encodes it in software, which is where it becomes permanent.
Hero narratives are how Normalized Workarounds survives contact with the automation project.
The pattern recurs and changes costumes. In one organization it shows up as a reconciliation that only runs because one person stays late. In another, as an onboarding that teaches the unofficial process first and the official one for the audit. In a third, as an automation initiative that keeps failing on the cases that are not edges at all, but the route the work has actually taken for years.
The conditions are structural, not behavioral. This is why training the operator does not interrupt it; it raises the ceiling on the workaround. Hiring more people does not interrupt it; it teaches the workaround to more people. Replacing the person resets the clock on the same geometry. None of these remove the constraint that made the workaround necessary.
What interrupts it is structural. Remove the constraint the workaround exists to bridge, rather than formalizing the bridge. Reassign authority to the layer that has been absorbing the work. Make the workaround impossible to perform, and accept the short-term disruption that surfaces. Where the root constraint cannot be removed yet, the cleanest move is to freeze workaround expansion: no new exceptions until at least one is retired.
When Normalized Workarounds has a name, the options change.
The operator who has been the single point of failure stops reading her own indispensability as job security and sees it as a structural risk the system is asking her to carry. The manager above her stops praising the save and starts asking what made the save necessary. The executive sees that the automation project keeps failing because it is being pointed at a process nobody actually designed. The board sees that operational continuity and system health are not the same reading, and that one has been standing in for the other.
Naming does not fix. Naming changes what can be seen. What can be seen is what can be acted on.
If any of this feels familiar, it has a name and a taxonomy.
The canonical definition of FM-05, including its early warning signals, common misdiagnoses, and recovery conditions, is at dripractice.com/fm/fm-05.
A role-specific view of how the same pattern looks from the operator’s seat is at dripractice.com/lens/the-operator.
A five-minute diagnostic that runs entirely on your device and never leaves it is at dripractice.com/diagnose.
Next in The Lexicon: FM-02, Escalation Inversion. The workaround persists because the problem never traveled up. Escalation is the path that was supposed to carry it, and FM-02 is what happens to that path.
Subscribe to The Lexicon.
gold. in an effort to hit a launch date, we accept a lot of “temporary workarounds” that become SOP because we move on to the next things and never come back to unwind them, document the real fix, or realign the process with what customers actually need. I call it 'the post-launch wake of good intentions.'