Many organizations appear contradictory because they have to meet contradictory requirements at the same time.
- Everyone wants to deliver faster. At the same time, quality must not suffer.
- Teams should make decisions autonomously. At the same time, the company needs comparability.
- Architecture should hold up in the long term. At the same time, it should not slow down current product work.
- Governance should provide orientation. At the same time, it should not turn every initiative into a process.
I think many organizations make a small but consequential thinking error here: they treat these contradictions as problems that need to be solved.
Sometimes that is correct. Some problems have a cause, a decision and a clear repair. Unclear responsibility can be clarified. A broken process can be simplified. A missing system can be built.
But many important organizational questions work differently.
They do not disappear just because one side wins once.
Some tensions remain
Standardization and flexibility are not a one-off decision problem. Both sides have value. Standardization makes things comparable, repeatable and efficient. Flexibility enables local adaptation, speed and learning.
The same applies to speed and care. To governance and autonomy. To efficiency and learning. To centralization and local decision-making. To short-term delivery and long-term viability.
When one side dominates permanently, a good organization rarely results. The organization develops a tilt.
- Too much standardization stifles local reality.
- Too much flexibility produces uncontrolled growth.
- Too much governance slows decisions.
- Too much autonomy can lose coherence.
- Too much speed creates downstream costs.
- Too much care can paralyze all movement.
The point is therefore not to choose the right side once and for all.
The point is to manage the tension consciously.
A problem seeks a solution. A tension needs leadership.
That sounds abstract at first. In practice, it is quite concrete. It changes the question you ask.
- Instead of: “How do we solve the conflict between governance and autonomy?”
- More like: “Which side has been overemphasized for too long, what side effects do we see, and what weighting do we need now?”

Balance is not a state
I find the scale a helpful image, but only up to a point.
A scale looks stable. You put weight on the left and right, observe the movement and look for equilibrium. This is a useful image for individual decisions. It forces you to take both sides of the tension seriously.
But in organizations, that balance does not stand still.
Markets move. Teams learn. Technologies change possibilities. Regulation shifts boundaries. Customer expectations become clearer or less clear. Power relationships change. A system that was too slow yesterday may be too uncoordinated tomorrow. An organization that currently needs more autonomy may need more shared standards again a year later.
That is why the image of a pendulum also fits.
An organization swings more toward control, then toward autonomy again. Toward speed, then toward stabilization. Toward innovation, then toward reliability. The critical issue is not that the pendulum swings. It becomes critical when nobody sees that it is swinging anymore.

In organizations, balance is not a target state. Balance is ongoing work.
VUCA is not a buzzword here
I am cautious about acronyms because they quickly become decorative. But VUCA is a useful lens for this idea.
- Volatility means: things change quickly.
- Uncertainty means: information remains incomplete.
- Complexity means: many factors interact with one another.
- Ambiguity means: the same situation can have several plausible meanings.
In such an environment, there is rarely one permanently correct organizational answer.
A decision can be right in one quarter and produce side effects in the next. An architectural rule can provide orientation in one team and create unnecessary friction in another. A process can create clarity initially and later become a ritual that consumes more energy than it returns.
This does not make decisions arbitrary. It makes them dependent on context.
And that is exactly why making tensions visible helps. Not as an excuse to avoid decisions, but as a better basis for making the next decision more consciously.
Architecture work is often work on tensions
These patterns appear constantly in enterprise architecture, product work and software organizations.
Architecture work is often described as providing target pictures, standards, principles and roadmaps. That is true. But beneath the surface, something else happens too: architecture work makes tensions visible.
An architectural principle such as “teams should be able to deliver independently” rarely stands alone. It touches platform strategy, interfaces, data ownership, governance, security, costs, skill distribution and operations. Every decision shifts weight.
- More team autonomy sounds good. Until each unit makes its own platform decisions.
- More standardization sounds good. Until local product teams can no longer represent their reality.
- More central architectural control sounds good. Until nobody learns quickly enough anymore.
- More decentralized decision-making sounds good. Until the organization loses its coherence.
Architecture is therefore more than solution design. Architecture also means working on tensions:
- Which forces are acting right now?
- Which side has been maximized for too long?
- Which side effect is becoming visible?
- Which decision moves the system in a better direction?
Working on tensions needs practical formats
At this point, working on tensions quickly becomes abstract.
You can say: we need to balance governance and autonomy better. Or speed and care. Or standardization and local reality. That sounds plausible. But in everyday work, the tension eventually needs a form in which people can examine it together.
That is where methods become interesting.
They give a tension a concrete working format. People can look at something together, name differences, sort assumptions and choose the next step more consciously.
- Event Storming helps when shared domain understanding is missing.
- Process modeling helps when everyone discusses the same workflow but has different mental pictures.
- Stakeholder Mapping helps when power, influence and who is affected are unclear.
- Decision Matrices help when assessment criteria are unclear.
- Assumption Mapping helps when too many assumptions are treated as certainties.
In all these cases, the method is not simply “right” or “wrong.” It makes a particular side of the situation visible. It directs attention. It creates an artifact people can discuss. And that is precisely how it intervenes in the tension.
The better question becomes: which tension is currently dominant, and which side do we need to make visible again?

This is exactly the perspective from which I currently find method selection interesting. For me, it begins with the question of what kind of uncertainty is actually present.
This is also one of the ideas running in the background of MethodAtlas: methods become more helpful when understood as a response to a concrete work situation.
Mature organizations are not free of contradictions
Perhaps this is the most important point.
A mature organization is not one that no longer has contradictions. That would be a strange goal in dynamic environments.
An organization is more mature when it:
- recognizes its tensions better.
- does not immediately treat every friction as an error.
- can distinguish whether a problem needs solving or a tension needs managing.
- sees which side of a tension has dominated for too long.
- considers decisions both as local solutions and as weightings within the system.
This does not automatically make organizations harmonious. But it makes them more capable of acting.

Organizations do not resolve many of their most important contradictions.
They learn to make them visible, weight them consciously and rebalance them repeatedly.
And perhaps that is where the difference begins between an organization that merely responds to friction and one that understands its own dynamics better.
