How a Temporary Workaround Becomes the Way the Company Runs
Nothing was ever decided. The temporary fixes just stopped being temporary, and one day the workaround was the architecture. Part III of Organizational Physics Applied.
Northstar at month 9 is, by the only measures the board tracks, the best version of itself so far. The enterprise motion that started with one $4.8M deal is now a named growth pillar. Revenue is up again. The company has hired ahead of it, the headcount is north of where Part I left it, and the founder-CEO has started using the word “scale” in a way that means it. There is nothing in the deck that would make anyone stop.
There is also, now, a volatility event. A significant outage tied to one of the enterprise integrations, the kind that reaches a customer’s executive team and therefore Northstar’s. The event is handled, but it lands in a company whose signal has already been compressing for two stages, and the CEO’s response to it is the thing this installment is about, because it is the response that any decisive leader would have, and it is the one that converts everything temporary into something permanent.
The Bridge That Was Going to Be Gone in 18 Months
Go back to the ERP bridge from Part I, the thin integration layer the customer swore would be retired inside 18 months.
It is now month 9 and the bridge is not retired.
It has, instead, acquired three new dependencies, because it worked, and things that work get built on. A second enterprise customer’s onboarding leaned on it. A reporting feature reused its plumbing rather than standing up its own. An internal tool started reading from it because it was already there.
No one decided the bridge was permanent. Every one of those three decisions was made by someone reasonable who saw a working piece of infrastructure and used it, which is what competent engineers do. But the sum of three reasonable reuse decisions is a load-bearing dependency that the company can no longer remove on the original timeline, or any timeline that doesn’t involve a project nobody wants to fund. The temporary thing did not get extended. It got built into, and being built into is how temporary becomes structural without a meeting.
This is the pattern the doctrine states flatly, and it is worth quoting because the whole stage is contained in it: a shortcut becomes a habit, a workaround becomes unofficial policy, a temporary accommodation becomes permanent infrastructure, and no single change is decisive. The pattern is.
You will never find the decision that made the bridge permanent, because there wasn’t one. There were a dozen small uses, each correct, that added up to a structure no one chose and everyone now depends on.
The bridge is the visible instance. The same thing happened to the things you cannot point at as easily. The containment behavior from Part I, where directors solved locally rather than escalating, stopped being a behavior and became the way work routes at Northstar. The curated reporting from Part II stopped being how people happened to brief upward and became the format. The org did not adopt these as policy.
The pattern repeating wore grooves into the system, and grooves are policy that no one has to enforce, because the water already runs that way.
The Reorg That Ratifies the Drift
The CEO, post-outage, does what decisive CEOs do. He reorganizes. Not recklessly, and not from ego. He sees coordination problems, he sees the enterprise motion straining the existing structure, and he restructures to match what the company has become. He stands up an enterprise pod with its own resourcing. He adds a layer to tighten the coordination the outage exposed. He centralizes a few decisions that had been diffuse, because the outage made diffuse decision-making look like the culprit.
Every move is defensible. And every move ratifies the drift instead of correcting it, because he is restructuring around the workarounds rather than around the standard the workarounds replaced. The enterprise pod is built to keep producing the customizations, which means the customization-as-default is now in the org chart. The new coordination layer formalizes the escalation latency from Part I by giving the summarization an official home, so the curation that used to be informal now has a job title attached to it. The centralized decisions pull authority toward the CEO at the exact moment his signal is most compressed, which means more decisions are now being made on the curated picture, by the person with the least accurate version of it.
The reorg feels like getting a grip. It reads, on the org chart, like maturation. What it actually does is take the drift of the first two stages and pour concrete around it, because structure is what you get when you make behavior permanent, and the behavior he made permanent was the adapted behavior, not the original standard. He has not stopped the Cascade. He has given it an architecture.
And the cruelest part, the part that makes this stage so hard to see from the chair, is that it works. Coordination does improve. The outage’s immediate cause does get addressed. The numbers that prompted the reorg get better, which the system reads as proof that the reorg was right, which is exactly the trap the doctrine warns about: external success arriving while the structure degrades, and the leader reading the success as validation that the current pattern works. The company learns the wrong lesson at the worst possible moment, and it learns it because the lesson is wrapped in a genuine win.
What It Costs by Month 9
The measurable signal has moved again, and it has changed character, which is the tell that you have crossed from one stage into the next. In Part I the cost was a metric drifting, escalation latency doubling. By month 9 the cost is that the drift has stopped being a metric and become a constraint.
The escalation latency is no longer a number that moved. It is a structure: the new coordination layer means six days is now the designed path, not a degradation from three. The customization load is no longer a percentage of tickets. It is an enterprise pod’s full mandate, a team whose existence depends on the customizations continuing. The ERP bridge is no longer a line item flagged for sunset. It is three dependencies deep and effectively unremovable without a funded project. Each of these started as something you could have corrected with a decision. By month 9 each has an owner, a budget, a headcount, or a dependency graph defending it, which means correcting it now costs something real: someone’s mandate, someone’s team, a project nobody planned for.
That is the difference between Part I’s stage and this one, stated as plainly as it can be. Early, the cost of correction was discomfort. Now the cost of correction is structural disruption, because the thing you would be correcting is no longer a behavior.
It is now he architecture the behavior hardened into, and architecture does not yield to a conversation.
You Have an ERP Bridge Too
The recognition this installment asks of you is more uncomfortable than the last two, because it is not about a metric you can check or a meeting you can recall. It is about the things in your company that everyone calls temporary and no one is planning to remove.
So make the list, and be honest about the word. What in your organization is officially temporary, a bridge, a stopgap, a “just for now,” a manual process someone does by hand until the real system is ready, a team that was stood up to handle a transition?
Now ask the only question that matters about each one: what is built on top of it. If the answer is nothing, it is genuinely temporary and you can leave it alone. If the answer is anything, any single thing, if other things now depend on the temporary thing, then it is not temporary anymore, regardless of what you all still call it. It is infrastructure that has not been acknowledged, funded, or hardened as infrastructure, which is the most expensive kind to own, because it carries all the weight of a permanent system and none of the investment.
And then look at your last reorg, or the one you are contemplating, through the lens Northstar’s CEO could not use on his own. Ask whether the new structure is built around the standard you want, or around the workarounds you have accumulated. The test is specific: for each new box on the chart, ask whether it exists to produce the outcome you actually want, or to keep doing the adapted thing the organization drifted into. A coordination layer that exists because escalation got slow is not solving slow escalation. It is institutionalizing it, the same way Northstar’s did, and it will feel like a fix the entire time it is setting the drift in concrete.
You cannot un-pour concrete with a status update. The only move at this stage is to decide, deliberately and at cost, which of your hardened workarounds you are going to keep and fund as real infrastructure, and which you are going to tear out before the next layer gets built on top of it.
Both options are expensive. The one option that is not available anymore is the one you had in Part I, which was to write a sentence and prevent the whole thing…for free.
Next: what happens to the people, when an organization spends long enough rewarding the adaptation instead of the standard, and the team you are left with is the one the drift selected for.
Part III shows you the workarounds that became your architecture. The companion Operator Insight makes them visible and decidable: how to inventory hardened workarounds, separate real infrastructure from unacknowledged debt, test whether a reorg corrects drift or concretes it, and the 30-day sequence to choose. Recognition here. The decision instrument there.