Sep05
Why AI creates an opportunity to redesign the organisation rather than accelerate its inherited compromises
Most organisations were not designed for the technology they use today. They evolved around what was possible at different points in their history.
Information was once difficult to collect and expensive to move. Computing and storage were scarce. Systems struggled with unstructured evidence. Integration was slow and costly. Personal service was difficult to provide consistently at scale, and specialist knowledge often had to sit physically or organisationally close to the specialist who possessed it.
Management layers, controls, processes, roles and service models developed around those constraints. Many of those choices were entirely rational and, in their time, may have represented excellent organisational design.
The problem comes later. Technology changes, the original constraint weakens or disappears, but the organisational compromise survives. Eventually, it becomes so familiar that nobody remembers it as a compromise at all.
Then AI arrives and gives us the ability to automate it.
Organisations carry their history in ways that are easy to overlook.
A report may exist because leaders once had no direct access to operational information. A management layer may have developed because information needed to be gathered, interpreted and consolidated before travelling upwards. A standardised customer process may have been the only economical way to provide service when individual context could not be preserved across thousands of interactions.
A control may compensate for historically weak evidence. A job may exist partly because previous systems could not perform a particular cognitive activity. A process may have several hand-offs because technology once made direct integration prohibitively difficult.
None of this makes the inherited arrangement wrong. It does mean that yesterday's technical constraint can quietly become today's organisational assumption.
AI changes enough of those constraints that simply automating the existing organisation may be one of the least interesting and beneficial things we can do with it.
The obvious question for most organisations is where to deploy AI. It is a perfectly sensible place to begin experimenting. Use cases make an emerging technology tangible, produce learning and can generate value quickly.
But the question carries an assumption that is rarely made explicit: the organisation we have today is the correct design brief.
Consider a service process that became highly standardised because carrying customer history, individual circumstances and discretion through a large organisation was difficult and expensive. One AI strategy is to automate that standardised process more efficiently.
Another is to ask whether AI now makes it possible to restore context, continuity and appropriate discretion at scale.
The same technology can support either approach. One improves the inherited model; the other asks why it has its current shape.
That distinction matters because AI can make yesterday's workaround extraordinarily efficient. A process that exists because of an old limitation can become faster, cheaper, and more scalable without anyone having to reconsider whether it still needs to exist in that form.
Technical success can therefore make organisational baggage more durable.
This is also why I am cautious about equating a portfolio of AI use cases with an AI operating model.
Imagine that several projects succeed independently. Customer service introduces AI assistance, finance automates part of its analysis, operations launches an autonomous agent, HR changes a workflow, and a commercial team uses AI to generate proposals.
Each initiative may have a good business case and deliver measurable value. Yet collectively they are altering the organisation.
The original evidence may now be seen by fewer people. Some decisions remain human, while others become machine recommendations or automated actions. Capability may be disappearing in one part of the organisation while becoming more important elsewhere. Authority can move unevenly. Different systems may commit the organisation in different ways. Customer interactions can take on entirely different contexts depending on which process they enter.
Individual use cases can work while the organisation becomes harder to understand.
That is not a failure of the technology. It is a failure to design the organisational architecture around it.
Redesign does not mean discarding everything that already exists. Current organisations contain hard-earned capability, relationships, operational knowledge and controls developed in response to real consequences.
The first discipline, therefore, is to understand why the organisation works as it does.
That requires more than mapping processes or drawing an organisation chart. It means understanding which decisions matter, what evidence reaches them, where uncertainty remains, which constraints are still real and which survive mainly because nobody has revisited them. It means identifying where important capabilities are embedded in routine work and where informal practices compensate for weaknesses in the formal process.
It also means understanding relationships. A process may appear inefficient because it involves discretion that is difficult to standardise, but that discretion may carry customer history or an institutional commitment that the formal system does not record.
The aim is not to produce a larger current-state document. It is to understand the operating reality well enough to distinguish valuable design from inherited baggage.
Once the current organisation is understood, the question becomes more ambitious.
Instead of asking only what AI can automate, we can ask what the organisation should now become.
Where should judgement sit when AI can provide far richer analysis? What evidence should be available at the point of decision? Which activities should be automated, where should AI assist, and which work can appropriately be delegated? Where is autonomous action sensible, and where should it deliberately stop?
The questions extend beyond technology. If AI performs work that once developed human expertise, how will future human capabilities be built? If the organisation can preserve customer context economically, should the service model still be as standardised as it is today? Which management activities exist because information once travelled slowly through the hierarchy? Which boundaries remain necessary, and which reflect technical constraints that have already disappeared?
Sometimes the answer will be to keep the inherited design. There is nothing inherently superior about radical change.
The important difference is that the design has been chosen again rather than carried forward automatically.
Redesign creates another challenge. A technically successful proof of concept does not necessarily prove that the future operating capability works.
An AI model can make accurate recommendations even when the evidence it receives remains inadequate. An agent can perform a workflow successfully until it encounters an exception for which no escalation path exists. A customer interaction can satisfy every formal process requirement while damaging the relationship the process was intended to support.
A technically impressive solution can also remove work through which people developed the capability the organisation still needs.
The organisation therefore needs to prove more than just technology performance. It needs evidence that the human and AI roles work together, that authority boundaries hold, that exceptions reach the right place, that consequential evidence remains sufficient, that relationships survive the redesign and that somebody can challenge or correct an outcome when necessary.
A tool working is not the same as an operating model working.
Even after the future capability has been designed and proven, the organisation still has to get there.
Transformation diagrams often imply a clean transition from the current state to the future state. Operational reality contains something in between.
For a period, people may work across old and new systems. Some decisions remain entirely human, while others become AI-assisted or delegated. Evidence may originate from different architectures. Authority can be transferred gradually. Customers may encounter different versions of the service model depending on where they enter the organisation.
Capabilities may need to exist twice before they can exist once. Legacy systems can remain essential long after new capabilities begin operating because some part of the organisation still depends on them.
This intermediate condition is not merely an implementation plan. It is an organisation in its own right, even if it is temporary.
It therefore needs to be designed and governed as a single entity.
AI makes that transition particularly important because organisations may be moving more than tasks and systems. They may also be moving authority.
A person who previously made a decision may first become an AI-assisted decision-maker, then an approver, then an exception handler. Eventually, the system may be authorised to act without continuous human intervention.
For some activities, that may be exactly the right design. But the transfer of operational authority should happen because the organisation chose it, not because someone enabled another feature.
During transition, organisations may therefore need to operate several different forms of authority simultaneously. Existing human processes, assisted work, delegated AI activity and more autonomous systems may coexist for some time.
That makes clarity about evidence, responsibility, escalation and revocation particularly important.
Transformation is not complete simply because the new system is live. It is complete when the work, authority, capability and context that should move have moved, what needs to remain has been protected, and the inherited structures that are no longer required can be deliberately retired.
There is another reason AI transformation should not end at deployment.
The future organisation has to remain capable of recognising when it has become wrong.
A decision that was reasonable when made can become inappropriate because evidence changes, a dependency fails, a customer situation moves, or the operating environment behaves differently from the assumptions used during design.
As organisations become more automated and increasingly autonomous, they also need to become better at translating consequences into action.
Changed reality needs to reach the decisions and systems that still depend on an earlier condition. Assumptions may need to be reopened. Exceptions need escalation. Authority may need to be reduced or revoked. The organisation needs to learn from what happened rather than allowing automation to preserve an outdated interpretation indefinitely.
This is why the transformation architecture I use has five connected movements: Understand → Redesign → Prove → Move → Run & Learn.
The labels are not the important part. The management discipline underneath them is.
Understand before automating. Redesign rather than inherit. Prove the operating capability. Move deliberately. Then keep reality connected to action.
There is understandable pressure to move quickly. Boards want progress, competitors are experimenting, and employees are already using AI, whether or not an enterprise programme has caught up.
Waiting indefinitely is not a sensible strategy.
But urgency does not make the inherited organisation the correct destination.
AI offers organisations a clear opportunity to make today's work more productive. That opportunity is real and should be pursued.
It also creates a more consequential possibility: to reconsider why the organisation has the shape it does.
Which processes still solve real problems, and which are responses to constraints that no longer apply? Which human capabilities become more valuable rather than less? Which interactions could carry more context rather than becoming more standardised? Which decisions could move closer to better evidence? Where should greater AI agency be allowed, and where should it deliberately stop?
The organisation we have today matters. It contains history, relationships, experience and hard-earned knowledge. It should inform the organisation we build next.
But it should not automatically become the design brief.
Do not automate the organisation you have today simply because it is there. Understand why it became that organisation, then decide what organisation AI now makes possible.
By Gert Botha
Keywords: AGI, Business Strategy, Digital Transformation
Do Not Automate the Organisation You Have TodayDo Not Automate the Organisation You Have Today
Mandate Design: The Project Management Competency Nobody Is Teaching Yet
Friday’s Change Reflection Quote – Saeculum Leadership – Leaders Architect Knowledge as Legacy
The Corix Partners Friday Reading List - September 4, 2026
