TRANSFORMATION AT SCALE AND SPEED - PART 3

Part 3

Redesign the work before redrawing the organisation

An organisation can change every reporting line and leave its most frustrating problems intact.

Customers still repeat information. Employees still reconcile conflicting data. Decisions still wait for approval. Work still moves between departments with nobody entirely sure why the previous team could not complete it.

The structure has changed. The experience of getting something done has barely improved.

For senior leaders, this is a useful test of organisational design. Before approving a new structure, we should be able to explain which work will become easier, which decisions will become clearer and which customer outcomes will improve.

In Part 1, I argued that transformation must become a permanent leadership capability. In Part 2, I explored the ownership required to make that capability effective.

The next responsibility is to design how the work will happen.

That requires looking beyond the organisation chart and examining the journey from a customer need to a completed outcome. It means understanding where people contribute judgement, where technology can help and where the organisation itself creates unnecessary effort.

Begin with the outcome the organisation exists to deliver

A structure makes certain things visible: positions, reporting relationships and formal authority.

It tells us much less about how value reaches a customer.

A customer seeking a service does not experience our functional model. They experience the questions we ask, the time they wait, the decisions we make and the reliability of what we deliver.

An operating model should connect those experiences to the way the organisation works. That includes processes, technology, funding, skills, controls and decision rights.

The latest research reinforces the need to consider these choices together. In an October 2026 article, McKinsey reported that nearly three-quarters of the AI high performers in its 2026 survey had substantially redesigned workflows, compared with approximately one-quarter of other organisations. That association does not establish that redesign alone caused their performance. It does make workflow design a serious question for executive teams assessing AI investment.

My recommendation is to begin with a specific outcome and examine everything required to deliver it.

For customer onboarding, that might mean helping an eligible customer begin using a service promptly, with accurate information and appropriate checks.

For product development, it might mean moving a validated customer need into a reliable product.

For supply operations, it might mean meeting a delivery commitment despite changes in demand or availability.

Each outcome crosses organisational boundaries. Designing for it requires leaders to examine the whole flow.

Find out where the time actually goes

Consider an illustrative organisation trying to improve customer onboarding.

Its employees spend time reviewing documents, checking information, resolving exceptions and communicating decisions. But the customer’s elapsed time also includes periods when nobody is actively working on the application.

A case waits for allocation. Missing information is requested. A discrepancy moves to another team. An approval waits for someone with the appropriate authority.

These are different problems, and they require different responses.

If document review takes an hour but the application waits several days between teams, making document review faster will address only a small part of the customer’s experience.

A September 2026 McKinsey analysis directs attention to these interfaces: the verification, reconciliation and routing required as work passes between teams and systems. Its useful contribution is to make the space between process steps an explicit subject of redesign. Its broader claims about the scale of coordination costs draw on varied evidence and should not be treated as a universal benchmark.

For your own organisation, measure what happens.

Separate active processing time from waiting time. Track how often work returns to an earlier stage. Examine the cases that take much longer than average. Identify where employees recreate information that already exists elsewhere.

Then ask why.

Some delays protect an important control. Others reflect unclear responsibilities, incompatible systems or a decision that has never been revisited.

The objective is to understand the reason for each step before deciding what should change.

Question whether the work is still necessary

AI creates an opportunity to reconsider work that organisations have accepted as unavoidable.

Before automating a report, ask who uses it and which decision it informs. Before accelerating an approval, examine the risk it controls. Before introducing a new assistant to reconcile data, investigate why the organisation maintains conflicting records.

A faster version of unnecessary work still consumes resources.

This matters because automation can make a weak process more difficult to challenge. Once a workflow is embedded in systems, supported by dashboards and connected to performance targets, people may assume its underlying logic has already been tested.

Senior leaders should require that logic to be made explicit.

What is the purpose of this activity? What would happen if it stopped? Could the need be addressed earlier in the journey? Does it exist because of a genuine customer or control requirement, or because of an internal arrangement that has outlived its usefulness?

These questions can be uncomfortable. Removing work may affect budgets, management responsibilities and established measures of contribution. That is why workflow redesign needs executive sponsorship as well as operational expertise.

Decide where AI fits by examining the task and its consequences

Once the necessary work is understood, leaders can make more informed choices about technology.

A role contains different tasks. Some are repetitive and well defined. Others involve incomplete evidence, sensitive relationships or consequences that are difficult to reverse.

Treating the whole role as either “automatable” or “human” conceals those differences.

In the onboarding example, a system might extract information from documents, identify missing fields and prepare a summary. An employee might investigate conflicting evidence, assess an unusual case and explain a consequential decision to the customer.

The allocation should reflect demonstrated capability, the quality of available information and the consequences of error.

There is also a discovery challenge: organisations may struggle to identify where AI would be useful in the first place.

A 2026 INSEAD working paper by Hyunjin Kim, Dahyeon Kim and Rembrand Koning reports a field experiment involving 515 high-growth start-ups. Firms given information about how other businesses had reorganised production around AI identified more use cases and achieved performance gains. The intervention concerned discovering where and how to apply AI; it was not simply a comparison of firms with and without access to the technology. Its start-up setting also limits direct generalisation to large enterprises.

For established organisations, the practical implication I draw is to involve people who understand the work in exploring possible applications. Technology demonstrations alone will not reveal all the constraints or opportunities.

Design the exceptions before scaling the routine

The most revealing cases are often those that do not follow the expected path.

Information is incomplete. Two sources disagree. A customer’s circumstances fall outside the usual categories. A system produces an answer that looks plausible but cannot be adequately supported.

A workflow design needs to explain what happens next.

Who receives the case? What evidence accompanies it? What authority does that person have? How will the customer be informed? Can the process be paused or reversed?

These questions should be answered before wider deployment.

Human review also needs to be realistic. If automation removes straightforward cases, the remaining work may contain a higher concentration of difficult decisions. Fewer cases do not necessarily mean a proportionate reduction in effort.

Employees may need more preparation, longer review time and better access to specialists. Capacity planning should reflect the complexity of the work that remains.

An executive team should therefore ask whether the proposed model has been tested against difficult cases, operational disruption and changing volumes. A successful demonstration under ideal conditions provides limited evidence about how the service will perform under pressure.

Choose a structure that supports the work

Once leaders understand the workflow and its dependencies, structural choices become more grounded.

A persistent cross-functional team may be appropriate when an outcome requires frequent collaboration between disciplines. A shared platform may make sense when several teams need the same reliable data, technology or services. Functional centres of expertise may remain important for professional standards, development and independent oversight.

These arrangements can coexist.

McKinsey’s September 2026 operating-model study, based on responses from 701 executives and senior leaders, found no single best design among organisations pursuing AI reinvention. It emphasised combinations of choices and their execution. The findings are based on individual respondents’ assessments, rather than representative accounts of each organisation.

Leaders should therefore resist treating a product model, a platform model or a flatter hierarchy as a complete answer.

A team described as autonomous may still depend on several external approvals. A new cross-functional unit may reproduce old silos if its members retain conflicting priorities. Removing a management layer may transfer coordination work to people who have no time or authority to perform it.

The design needs to account for those consequences.

Before changing reporting lines, specify the work the new arrangement will own, the decisions it can make and the capabilities it will share with the rest of the enterprise.

Make the model understandable to the people operating it

An operating model is incomplete if employees cannot explain how it changes their work.

People need to know what they are expected to achieve, which information they can rely on and how their responsibilities connect with those of colleagues and systems.

They also need opportunities to identify weaknesses in the design.

Microsoft’s 2026 Work Trend Index surveyed 20,000 workers using AI across ten countries. Its analysis found organisational conditions—including culture, manager support and talent practices—were more strongly associated with self-reported AI impact than individual factors alone. The report explicitly describes these as statistical associations, rather than causal effects.

That finding supports examining the environment around the employee when a new workflow struggles.

Do managers provide consistent guidance? Is there time to learn? Are quality expectations clear? Does the performance system reward the behaviour the redesigned process requires?

If those conditions remain unresolved, another round of training may leave the central problem untouched.

Test the complete outcome and account for the full cost

A redesigned workflow should be assessed against the problem it was intended to solve.

For onboarding, I would examine completion time, accuracy, customer effort, exception handling and the cost of delivering an acceptable outcome. I would also look at how performance varies between straightforward and complex cases.

Include the resources required to operate the technology: review, integration, monitoring, support and correction. Measure whether effort has been removed or transferred to another team.

Be explicit about how released capacity will be used.

It might support additional customers, reduce backlogs, improve service or create room for learning. Until that decision is made and implemented, estimated time savings should not be assumed to translate into a financial benefit.

Finally, establish what happens after the trial.

Who owns continuing improvement? Which old processes can be retired? What evidence would trigger a revision? How will learning from one team become available to others?

These decisions connect the Architect stage of transformation with Activate and Amplify. The design becomes a working capability through use, evidence and adjustment.

Ask to see the work before approving the chart

At your next operating-model review, choose one important customer or business outcome and trace how it is delivered today.

Examine where work waits, where information is recreated and where decisions become unclear. Identify the activities that remain necessary and those that deserve to be challenged. Test how people and technology could work together differently.

Then assess the structural changes needed to support that design.

An organisation chart should express choices about how the business will perform. Those choices need to be clear enough that employees can act on them and customers can experience the improvement.

Before approving your next restructure, can you point to the work that will become easier—and the evidence that will show it?

Next in the series: Build the skills to make the new model work.

Research underpinning this article includes McKinsey’s October and September 2026 analyses of AI and operating-model redesign; the March 2026 INSEAD working paper Mapping AI into Production; and Microsoft’s May 2026 Work Trend Index. The customer-onboarding example is illustrative. The proposed leadership practices are a synthesis informed by these sources.