A migration stalls.
A transformation costs more than expected.
A seemingly small change suddenly requires coordination across five teams.
The instinct is usually to diagnose the event.
What failed? Which technology needs replacing? Where should we invest?
But the event may not be the problem.
It may be revealing the problem.
After years working in and around distributed technology environments, I have become increasingly interested in what moments of change expose about organisations: hidden dependencies, accumulated workarounds and assumptions that held only while nothing moved.
For leaders deciding where to place capital, attention and organisational capacity, that distinction matters.
If we misdiagnose what change reveals, we can spend considerable money solving the visible symptom while preserving the system that produced it.
— Observed Reality —
Change has a way of making invisible relationships visible.
A migration may begin as a technical exercise: move workloads, change infrastructure, replace a platform.
Then reality expands the problem.
A dependency nobody documented becomes critical.
A manual workaround turns out to be connecting two supposedly independent processes.
A decision stalls because the knowledge required to make it sits outside the formal ownership model.
The architecture may describe how the system was intended to work.
Operations reveal how it actually works.
That difference matters because organisations rarely operate exactly as they were designed.
Customers behave differently from projections. Regulations evolve. Teams adapt around constraints. New technology gets layered onto old technology. Informal relationships develop because formal processes cannot accommodate every situation.
Some dependencies are designed.
Others simply become true.
— System Principle —
Over time, a gap emerges between the system described on paper and the system people actually operate.
That gap has a cost.
Sometimes it appears as additional infrastructure, slower delivery or operational risk.
Other times it shows up as people performing manual reconciliations, remembering undocumented dependencies or coordinating across organisational boundaries simply to keep work moving.
These are not necessarily signs of inefficient people.
They can be signs of complexity the system has not resolved and therefore asks people to carry.
This is why change can be so useful.
It does not merely disrupt the system.
It reveals where complexity has accumulated.
Seen this way, change becomes a form of organisational observability.
It gives us evidence about where assumptions no longer hold, where dependencies have become implicit and where the formal architecture has drifted away from lived reality.
— Inquiry —
That leads to a different set of questions.
Where does work unexpectedly slow down?
Which dependency becomes visible only when something moves?
Where is knowledge concentrated in one team, or even one person?
Which control protects the organisation, and which exists because of an assumption that is no longer true?
Where are highly skilled people repeatedly compensating for structural complexity?
And perhaps most importantly:
Where does the system actually end?
At the platform?
The organisation?
The customer or market it ultimately serves?
The boundary matters because organisations can optimise one part of a system while transferring cost, delay or risk somewhere else.
A platform can meet its reliability target while customers experience friction downstream.
A transformation can meet its delivery milestones while creating additional operational work.
A policy can achieve its intended control while generating unintended complexity elsewhere.
From inside the boundary, each intervention can look successful.
Expand the boundary, and the picture may change.
So the leadership question becomes:
Are we solving complexity, or merely relocating it?
One way to improve that diagnosis is to change the boundary through which we examine the system.
Draw it narrowly, and we may see a technical issue.
Widen it, and we may discover ownership, incentives or decision-making authority.
Widen it further, and the same event may become a question of continuity, compliance, cost or customer trust.
Same event. Different boundary. Different consequence.
The point is not to make every problem infinitely large. It is to follow the outcome far enough to understand what can prevent it from being achieved.
One system’s output becomes another system’s input.
A process can complete while the intended outcome still fails. An acknowledgement can tell us that something moved without telling us whether it did what it was meant to do.
That is where local optimisation can begin to separate from system performance.
— Consequence —
This matters because diagnosis shapes investment.
The visible problem may suggest another platform, another tool or more automation.
But the underlying constraint may require a redesigned process, clearer ownership, a different operating model or a change in how decisions are made.
The consequence therefore reaches beyond architecture.
It influences technology investment, organisational capacity, customer outcomes and risk.
At institutional scale, the same systems problem can even surface in policy.
The domain changes. The systems problem does not.
Every investment also makes an implicit choice about what the organisation intends to preserve: an outcome, a control, a capability, or sometimes complexity inherited from the past.
That is why change should be treated as more than an implementation challenge.
It is information.
The question is whether the organisation is purposeful about how it uses it.
— What Comes Next —
Complex systems will always produce surprises.
The objective cannot be to predict everything.
But organisations can become better at noticing.
An outage can expose an undocumented dependency.
A transformation can expose an organisational boundary.
A regulatory change can reveal an assumption embedded deep inside an operating model.
The strategic opportunity is to learn from those signals before disruption becomes the only mechanism capable of producing them.
That requires observability, certainly.
But it also requires inquiry: the willingness to compare how we believe a system works with how it actually behaves, and to let that evidence influence what we fund, redesign or stop doing.
Which leaves me with the question I want to carry forward:
If one of our assumptions changes tomorrow, what exactly are we expecting the system to preserve: an outcome, a control, a capability, or sometimes complexity inherited from the past?
