Why Do Undocumented Decisions Get So Expensive?

No company sets out to build a system nobody understands. It gets there gradually, through the ordinary work of keeping a business moving. 

Someone adds a customer exception to save an important deal, patches a report by hand the morning it is due, or drops in a manual step because the software cannot do the thing yet, and each of those is a reasonable answer to a real pressure. 

The problem is that a reasonable answer, repeated a few hundred times and never written down, is how a company slowly gets harder to run than anyone meant it to be.

Years later the exception is still in place, the manual step is load-bearing, and no one can say why. 

What never got captured was the part that mattered most: why the decision was made, what it changed, and when someone should have looked at it again. 

Without that, a stopgap becomes a permanent rule, and the reasoning behind it walks out the door the day the person who made it does.

Complexity itself is manageable when you can see it. The trouble is how much of it stays invisible. By some estimates, roughly 80 percent of how an organization actually operates is never written down anywhere, living in habits, side notes, and one person's memory.

‍

Where does business complexity actually come from?

It builds up out of small, reasonable decisions, almost never one big mistake. 

When we take over a system somebody else built, what looks like a mess is usually the residue of a hundred practical calls, each one sensible on the day it was made:

• A spreadsheet, created because the system did not show the right view
• A customer exception, added because that deal mattered
• A status field, reused for a second purpose because adding a new one felt heavy
• A manual approval, inserted after one mistake created real risk
• A report, adjusted by hand because leadership needed an answer fast
• A side note that became the only place some critical context lived

Each of those starts as a fine call. 

The trouble begins when it becomes permanent without ever becoming official, and nobody circles back to decide whether it should still be there.

‍

What actually makes those decisions expensive?

When someone writes a workaround down, why it exists, who owns it, when to revisit it, it stays a decision the business can manage. 

When no one does, it turns into something the next team has to reverse-engineer under pressure, usually after it has already broken something. 

What almost never gets written down is exactly what that team needs:

• Why the decision was made
• Who approved it
• Which workflow, report, or customer it changed
• Whether it was meant to be temporary or permanent
• What would have to be true before it could be safely removed
• Who owns it now

A recent CIO.com piece on why enterprise systems grow more complex over time makes the point that the cost of all this accumulation is real even when it never shows up as a clean line item. That is true, and there is a harder version of it underneath. 

The people running the system often do not know a decision was ever made in the first place. 

You cannot manage a risk you have never been told exists, and a rule nobody remembers creating is nearly impossible to remove, because no one can tell you what it was there to protect against.

‍

What does undocumented complexity look like from the inside?

It shows up as hidden requirements, the rules the system was forced to absorb over the years. 

When we start improving or rebuilding a system, the discovery phase is mostly this: finding the decisions nobody wrote down. 

It sounds like this:

• "That field looks optional, but operations depends on it."
• "That status is technically wrong, but finance uses it for billing."
• "That report gets corrected by hand before leadership sees it."
• "That customer type runs on a different workflow, and no one remembers why."
• "That approval step only exists because of one incident three years ago."
• "That spreadsheet is the real source of truth."

Every one of those is an old business decision the software was made to carry. 

Miss one in a rebuild and you break the billing, the report, or the exception that was holding something together, which is why we map how the whole system actually behaves before we change any part of it.

‍

Where does the cost actually show up?

In predictable places, every time:

• Change slows down. A simple update turns risky because nobody knows what else depends on the current behavior.
• Reports lose trust. When definitions and manual fixes are undocumented, leadership starts second-guessing the numbers.
• Training gets harder. New hires learn the steps but not the reasons, so they cannot adapt when something looks off.
• Software gets harder to maintain. Developers have to preserve behavior nobody can explain, which is slow and risky work.
• Customers feel it. Internal confusion eventually surfaces as an inconsistent status, bill, or answer.
• One person becomes the interpreter. The business ends up running on whoever remembers the old decision, and replacing that person can cost up to twice their salary once you count the knowledge that leaves with them.

‍

What should you document before the next system change?

You do not have to record every keystroke, only the decisions that change how the business runs. 

Six of those are worth the effort every time:

• The exception. If a workflow has a special case, write down when it applies and who owns it.
• The field's real meaning. If teams use the same field differently, define what it is actually supposed to mean.
• The source of truth. If the same data lives in several places, decide which one wins.
• The manual step. If someone corrects, exports, or reconciles something by hand, record why.
• The business reason. A rule with no recorded reason is nearly impossible to challenge later.
• The review date. Some workarounds should expire, and some should become real features. Give each one a date to be looked at again.

Once it is written down, the workaround becomes a choice the business can make on purpose, whether to keep it, improve it, or retire it. 

Left undocumented, it is simply a surprise waiting for whoever inherits the system.

‍

What should you ask when complexity shows up?

When you hit a step nobody can quite explain, a short set of questions usually gets to the truth:

• Why does this step exist?
• Who benefits from it, and who is slowed down by it?
• What would break if we removed it?
• Is it protecting the business, or preserving old friction?
• Does the system actually support it, or are people carrying it by hand?
• Is this a real business rule, or an old workaround everyone now treats like one?
• Who owns the decision today?

This is most of what we do in the first phase of any project. 

Before we build or rebuild anything, we run a deep discovery to surface exactly these buried rules, because you cannot design good software around a business you do not fully understand yet. 

We believe that business is built on transparency and trust, and that good software is built the same way, and that starts with making the invisible decisions visible again, so the company can choose which ones to keep.

‍

How do you keep reasonable decisions from getting expensive?

A reasonable decision turns expensive the moment the business forgets why it made it. 

Some complexity is load-bearing and worth keeping, so the work is about telling it apart from the complexity that only exists because no one ever revisited it. 

You get there by writing decisions down as you make them, the ones that change a workflow, touch a customer, create an exception, or bend a report. 

Document those, and the next team inherits a system they can actually understand, instead of a set of rules they are afraid to touch.