There is a very subtle way systems degrade. They do not collapse. They do not even fail all at once. You could say there is no clear moment when something breaks. You simply reach a point where you can no longer explain why things are the way they are.

To understand why this happens, Tesler’s law of the conservation of complexity strikes me as highly instructive and a solid argument. It states that any system has a minimum level of complexity that cannot be eliminated. It can only be moved.

In other words, when you simplify something, you are not making complexity disappear. You are deciding where it lives.

This is not a new idea. In 2009, in a book Yusef and I co-authored, we pointed to something that then felt more technical than strategic. In design, managing complexity with judgment matters more than insisting on erasing it entirely.

A very simple example is email. You can redesign the interface, hide options, or automate parts of the flow. Still, a core remains that you cannot remove without breaking the system. You will always need a recipient, a subject, and a message body. That is the minimum complexity. Everything else can move. That stays.

Simplified email interface, with recipient, subject, and message body as the minimal complexity core you cannot remove

Things start to go wrong when we forget this and begin to simplify without understanding what we are shifting.

When the system can no longer be explained

At first, everything makes sense. Each decision fits a concrete need. You add a feature because there is a demand, you simplify a flow to reduce friction, you optimize a metric because it reflects relevant behavior.

It all seems reasonable. And having lived that process firsthand, it is.

The difficulty, however, does not lie in those individual decisions. It lies in what happens when they pile up without a trace.

Gradually, the ability to understand the system fades. You stop knowing why it was designed this way, what problem it originally solved, or which alternatives were discarded along the way.

You get pulled along by the market, you lose structure, and when that happens, your relationship with what you are building changes completely. You stop designing and start merely reacting.

Optimizing without understanding

At that point, optimizing becomes easier. You only see what is immediate. You believe more conversion, more speed, or less friction is the answer, and you overlook what you are losing.

Partly because we often remove friction without distinguishing between useless friction and the structure that holds the system together.

The difference is critical and easy to grasp with a simple argument. If removing something means you can no longer explain what is happening, it was not friction. It was structure.

Back to email. You can simplify the interface. But if you remove the recipient, the system stops making sense. You can no longer explain what is going on, who the message is for, or what action you expect next.

You have not reduced complexity. You have removed the structure that made the system work.

Legibility as a competitive advantage

Organizations that have lasted for decades do not only optimize outcomes. They also optimize legibility.

What does that mean? It means they build systems where decisions leave a trace, context is not lost, disagreement is visible and becomes part of the process, and work can be understood even from the outside.

A clear example is how work happens on GitHub. Every code change is more than just a technical tweak. It records who did it, when, why, and which alternatives were discussed.

Pull Requests are not just a middle step. They are where disagreement becomes visible, where people argue, question, and improve the solution before it is merged.

Now imagine a company that worked like that. One where every important decision left a trace. Where you could understand months later why one path was chosen over another. Where disagreement was made explicit and useful instead of being smoothed away.

That is legibility. It comes less from polished documentation than from how the system itself forces the work to stay explainable as it happens.

Optimizing without understanding is the start of dismantling

This pattern is not limited to digital product. It shows up in many places, always in a similar way.

  • In product, for example, when you drop fields to lift conversion. It works. More users finish the flow. Months later you realize you lack key information to understand what they are doing or why things fail. You gain volume at the expense of clarity.
  • In teams, when you speed up delivery by cutting analysis or documentation. You ship sooner, yes, but revisiting decisions, onboarding someone new, or maintaining coherence gets harder each time. You gain short-term speed and lose continuity.
  • In a city, when you prioritize immediate land use over its future role. You build fast and monetize sooner, and years later you lack public space, services, or affordable housing. What looked like efficiency was, in fact, consuming the system itself.

It always plays out the same way. Optimizing what you can measure today usually means under-investing in what you will only understand tomorrow. It echoes what I described as the limit of incremental improvement. Beyond a threshold, the next improvement stops being marginal and redefines the system itself.

It is less that you make bad decisions than that you lose the ability to make good ones later.

What cannot be explained cannot be improved

The hardest part is not complexity or living with it. It is losing the ability to understand it.

As long as you can explain why you are doing something, you have control. You can adjust, correct, improve. The moment that explanation vanishes, the system still runs, though it no longer fully belongs to you.

From then on, you are not designing. You maintain without deciding and react at every turn.

Every time you simplify something, you are not removing complexity. You are shifting it. Sometimes onto the user, sometimes onto the team. Often, into the future.

When that shift is not conscious, the system keeps working while, at the same time, becoming incomprehensible.