1. Won’t All Banks End Up With the Same Complexities?
It is a comforting idea: scale is gravity, and operational drag is just what happens when you get big. If that were true, every large organisation would converge on the same outcome: bloated estates, fragile systems, endless governance, and chronic delivery failure. But complexity is not a law of nature. It is a residue.
It is what remains when decisions are postponed instead of resolved. It is what accumulates when compromise is allowed to harden into architecture. It is what grows when organisations confuse activity with progress.
Two banks can grow at the same pace, operate under the same regulatory regime, and still end up with radically different operational realities.
The difference is not growth.
The difference is what growth is allowed to amplify.
2. Doesn’t Growth Force Layers, Process, and Bureaucracy?
Growth forces repetition. It does not force bureaucracy.
Bureaucracy appears when organisations stop trusting their systems to behave predictably. It is a defensive response:
- to systems that are too coupled to change safely
- to teams that cannot deploy independently
- to ownership that is unclear or contested
- to leadership that lacks technical confidence
In well designed environments, growth punishes excess process because process slows feedback. Simplicity becomes a survival trait.
In poorly designed environments, growth rewards control because control is the only way to reduce surprise. Scale does not create bureaucracy. Fear does.
3. Don’t Mature Product Portfolios Naturally Become Complex?
Only if nothing ever truly ends. Product complexity explodes when organisations refuse to delete. Old products linger because retirement is politically painful. New products are layered on top because fixing the original mistake would require accountability.
Over time, the portfolio stops being intentional. It becomes archaeological. Operational complexity emerges when:
- product boundaries are unclear
- shared state becomes the default
- release cycles are coupled
- incidents span multiple domains by design
Maturity is not the accumulation of features.
Maturity is the accumulation of clarity.
4. Growth Reveals Truth. It Does Not Change It.
This is the uncomfortable part. Scale is not a transformation engine. It is an amplifier. Growth does not turn good systems into bad ones. Growth turns weak assumptions into outages. If you already have:
- clear domain boundaries, growth multiplies throughput
- strong technical leadership, growth accelerates decision making
- predictable delivery, growth increases confidence
- resilient architecture, growth improves stability
If you already have:
- unclear ownership, growth magnifies politics
- entangled systems, growth multiplies blast radius
- indecision, growth creates paralysis
- weak architecture, growth exposes fragility
When people say “they will become complex as they grow”, what they are really saying is:
“Growth will expose whatever they have been avoiding.”
5. Why Does Scarcity Force Simplicity Including Organisational Design?
Scarcity is not just a financial or technical constraint. It is an organisational one.
When resources are scarce, organisations are forced to make explicit choices about ownership, scope, and accountability. You cannot create twenty product teams for the same savings account and hope simplicity will somehow emerge either for the client or architecturally. Scarcity enforces:
- a small number of clearly accountable teams
- sharply defined product boundaries
- single sources of truth
- architectural coherence
When you only have a handful of teams, duplication is obvious and intolerable. Overlap becomes expensive immediately. Decisions are made early, when they are still cheap. Abundance breaks this discipline. With enough people and budget, organisations fragment responsibility:
- multiple teams own different “aspects” of the same product
- customer journeys are split across silos
- data ownership becomes ambiguous
- architecture starts to mirror reporting lines instead of domains
This is how organisations create massive internal motion while the customer experience degrades and operational risk increases.
Organisational simplicity and architectural simplicity are inseparable. If your org chart is tangled, your systems will be too.
6. Doesn’t Maturity Inevitably Create Complexity?
No, and this is where many organisations lie to themselves.
We routinely confuse an organisation getting older with an organisation becoming mature. They are not the same thing. Maturity does not create complexity, but immaturity does.
As immature organisations age, they do not magically become disciplined, coherent, or deliberate. They reveal their immaturity more clearly. Deferred decisions surface. Leadership vacuums widen. Weak architectural choices harden into constraints.
Organisations are not like bottles of wine that effortlessly reveal sophistication over time. They are more like a box of frogs, full on entropy and constantly needing to be corrected.
Without active leadership, clarity, and constant intervention, entropy takes over. Chaos rushes in where decisions are delayed. Politics replaces strategy when direction is absent.
Time is not a cure. Time is an accelerant.
7. Isn’t Operational Drag Simply the Cost of Regulation and Risk?
Regulation adds constraints. It does not mandate chaos. In practice, regulators reward:
- clean boundaries
- deterministic processes
- auditable flows
- explicit accountability
What creates regulatory pain is not simplicity but opacity: tangled estates, unclear data lineage, and uncontrolled change paths.
Many organisations hide behind regulation because it is a convenient excuse not to simplify. Compliance does not require complexity. It requires clarity.
8. Don’t All Large Systems Eventually Become Fragile?
Large does not mean fragile. Coupled means fragile. Fragility appears when:
- multiple products share the same state
- deployments are linked
- teams cannot change without coordination
- ownership is blurred
Resilience comes from clean failure domains.
If systems are isolated, you can grow without multiplying outage impact.
If they are not, every new product increases systemic risk.
9. Isn’t This Just a Different Phase of the Same Journey?
This assumes there is only one destination.
It implies every organisation eventually converges on the same architecture, the same cost base, and the same operational burden.
That belief protects poor performance. There are divergent paths:
- one treats simplicity as a first class constraint
- the other treats complexity as inevitable and builds governance to manage the damage
These are not phases. They are philosophies.
10. If Complexity Isn’t Inevitable, Why Do So Many Organisations Suffer From It?
Because complexity is what you get when you refuse to choose. It is easier to:
- keep two systems than retire one
- add a layer than remove a dependency
- add a new product, than fix the existing ones
- create a committee than empower a team
- declare inevitability than admit poor decisions
Operational complexity is not created by growth. It is created by accumulated compromise.
11. So What Actually Creates Operational Complexity?
Almost always the same four forces:
- Indecision
Parallel paths are kept alive to avoid conflict. - Product complexity
Portfolios grow without pruning. - Poor strategic architectural decisions
Short term delivery is traded for long term fragility. - No technically viable strategy for co existence
Products cannot live in isolated domains.
Growth does not cause these. Growth merely exposes them.
12. What Is the Real Destiny?
There is no destiny. There is only design. Organisations that invest in:
- scarcity as a deliberate constraint
- value stream aligned organisational design
- isolation as a scaling strategy
- strong technical leadership
- ruthless simplification
Do not collapse under growth. They compound efficiency. Those that do not, will call their outcomes “inevitable”. They never were.