An opinion piece in Dagens industri by Joel Sunnehall and Mikael Cato recently put words to a concern we share. Their argument was that AI changes the organisation of work, responsibilities and decisions. Buying licences and helping individuals work faster can look like transformation while the company’s ways of working remain unchanged. In their view, the CEO must therefore own the change, and the board must hold the CEO accountable for it.
We have seen the same challenge with operational excellence. Leadership wants a better company but delegates the transformation to individual functions. Each manager improves their own area. The reports look better, yet the customer may still be waiting for the same result.
We recognise this pattern in our own company, Hups. Our 17 employees work across different functions. We have said that we want to be AI-native, and we feel we have come a long way. AI has improved our functional productivity.
But lately, we have started asking ourselves a different question: how can we use AI to improve Hups as a whole? How can it help us become more customer-focused, more effective and more efficient from our customers’ perspective? Those are the questions behind this article.
Our argument is that the largest opportunity often lies in the flow connecting our functions. We need clear end-to-end flows built around what customers actually need, with AI helping us improve the complete result. AI and customer focus belong together on every executive team’s agenda. That requires leadership to start with the flow.
But let's start with defining what the the AI productivity paradox is.
We define the AI productivity paradox as when every function becomes faster with AI, but the customer gets the result no sooner, and sometimes later. Each team reports higher productivity. The business as a whole delivers no more value to its customers.
The idea is not new. In 1987, the economist Robert Solow wrote: “You can see the computer age everywhere but in the productivity statistics.” Companies had invested heavily in computers, yet productivity barely moved. Later research, for example by Erik Brynjolfsson, found that the gains came mainly where companies also changed how they organised work.
We believe AI risks repeating this pattern inside companies. The gains are real at the level of the task. But most of the time a customer waits is not spent on tasks. It is spent between them: in queues, handovers and decisions. If AI only speeds up the tasks, the wait stays almost the same.
The case below shows how large that gap can be.
Let us use a real case to illustrate our point. A train maintenance company began an operational excellence transformation by training all its managers, around 300 people. Together, they identified the company’s end-to-end flows and prioritised them. One priority was the Running wheel flow. Managers from the functions involved were given a shared task: improve that complete flow.
In 10 weeks, the team reduced lead time from 31 days to 6. Before looking at how they did it, let us understand what those 31 days contained.
The running wheel assembly consists of the wheels and axle on which a train runs. When the right assembly was unavailable, a train could not return to service as planned. The maintenance company faced penalties, the operator lost access to its train and passengers could face delays. What looked like a workshop problem affected everyone depending on the completed job.
The Running wheel flow crossed functions, locations and IT systems. Its four phases were transport, preparation, production and finishing. Together, they took 31 days.
Figure 1. The Running wheel flow before improvement. Transport takes 13 days, preparation 6, production 11 and finishing 1. Functional responsibilities and the route are simplified.
The line follows the Running wheel flow from beginning to end. It makes visible something departmental reports can miss: how long the customer has to wait for the completed result.
Imagine attaching a GoPro camera to the running wheel assembly. Press record when it is removed from the train, then stop when maintenance is complete and it is ready again. You would have a film lasting 31 days. How much action would you see? About 21 hours of work that creates value for the customer.
Figure 2. Flow efficiency is 2.8%: 21 value-creating hours within 744 elapsed hours. Green intervals appear in the flow and timeline at the same illustrative positions.
The camera is a metaphor, but the numbers are real. Those 31 days contain 744 hours. Only 21 hours, approximately 2.8%, were value-creating work. The other 723 hours, or 97.2%, were non-value-creating time. Colour the same flow green when value is added and red for the rest, and the lack of action becomes impossible to miss.
This does not mean employees were idle for 97.2% of their day. They may have been busy with other work while this running wheel assembly waited. Much of the opportunity lay in queues, handovers and dependencies between functions. To understand why, we need to look at how the organisation was managed.
Here is where the paradox begins. We see busy teams and improving productivity figures and conclude that the business is becoming more productive. The local gains may be real. What we have not established is whether they create greater value for the customer. Sometimes they make the customer’s situation worse.
This is a common management problem. We divide an organisation into functions, give each manager a budget and ask them to achieve particular targets. Purchasing must lower prices, operations must raise utilisation and logistics must reduce transport cost. Each manager is, in a sense, a king or queen with a clear mandate from the CEO.
The problem begins when those targets are set and tracked independently of the whole flow. A larger purchase may reduce unit price while increasing inventory. Waiting for a full truck may reduce transport cost while delaying delivery. Decisions that improve one function’s KPI can make the customer’s result worse.
Figure 3. The CEO delegates targets to functional managers, represented by crowns. Vertical columns are functions; horizontal lines are end-to-end flows. The functions and KPIs are illustrative.
These managers are doing what they have been asked to do. We have built a management system that rewards the performance of the parts without ensuring that the parts work well together. The more effectively each function pursues an isolated target, the stronger the suboptimisation can become. Suboptimisation means that each part performs better while the whole performs worse.
Leadership must therefore align functional decisions around the result the customer needs. A productive workshop, a low purchase price and a full truck are useful only if they help deliver that result with the right quality, at the right time and at an acceptable total cost.
AI already helps functions generate content, analyse information and complete tasks faster. Now give every function more AI while leaving its mandate unchanged. Sales can pursue more orders, purchasing can negotiate more deals and service can answer more questions. The company can become a collection of even stronger islands, each better at its own task and no better connected to the customer.
The examples below show how this can happen. The applications can be valuable. The risk comes from the assignment we give them and the measures we use to judge success.
Figure 4. Examples of functional AI priorities and possible consequences when only local targets count.
Consider sales and logistics. Winning orders faster can be useful, but if delivery cannot keep up, the queue grows. A logistics team can then save money by waiting for fuller loads, extending the delay again. Both teams may report a gain while the customer receives a later delivery.
That is the danger of automating the existing management logic. We can make each island more efficient while moving the business further from the result the customer needs. Instead, we should ask how AI can help the functions work together.
Let us return to the Running wheel flow. Before the managers analysed it, the company had trained them, identified its flows and prioritised where to begin. The executive team then gave the managers a mandate across functional boundaries. That sequence mattered: they were responsible for a shared customer result, not separate departmental gains.
Together, they analysed where the work stopped, what was missing and which decisions prevented it from moving. They agreed phases, milestones, handovers and shared KPIs for quality and total lead time. They visualised the same information, then established routines to review deviations, decide what to do and follow up together.
Figure 5a. Leadership first trained the managers, identified all flows and prioritised them. The managers then analysed, standardised, visualised and routinised the selected flow together.
Weekly reviews developed into daily management. Transport, production and the other functions could see the same problem and make a coordinated decision. The executive team provided the mandate; the managers owned the transformation and turned it into everyday work.
The big room shown below makes this concrete. A big room is a shared space where managers run the work together. The team stands in front of the same boards: performance, flow, resources and improvement. The point is the conversation those boards make possible. What is stopping this flow, and what must we do together to release it?
Figure 5b. A closer view of the big room. The team gathers in front of the same performance, improvement, flow and resource boards.
This was alignment made practical. The managers first created a common way of working across the functions. Four management capabilities helped them sustain it: Performance Management, Flow Management, Resource Management and Improvement Management.
They followed the same Running wheel flow and judged their decisions against the same customer result. If inspection stopped the work, they arranged inspection capacity. If a handover failed, the functions changed it together. Each capability helped them manage the whole system.
Figure 6. Four management capabilities create alignment around the customer and the complete flow.
Let us look at the improvements behind the result. Direct collaboration connected people who had previously depended on handovers. Transport management changed to support the flow. Production management was redesigned, workstations were combined, and non-destructive testing technicians joined new teams.
These changes reinforced one another. Shared KPIs, phases and routines gave the functions a common direction. Closer working relationships and earlier involvement helped make decisions, information and resources available when needed. The managers were integrating the work into one flow.
Figure 7a. The Running wheel flow finishes after 6 days instead of 31. Both routes use the same scale and are schematic; purple includes any remaining waiting.
The transformation took 10 weeks in total. The team reached its 6-day target after 40 running wheel assemblies had passed through the flow. Compared with the original 31 days, that meant 25 days removed: 600 hours, or approximately 81% of the lead time.
Many improvement initiatives contributed. The chart highlights five examples of changes that connected the functions into one flow. Each bar follows an individual completed assembly; the horizontal axis counts assemblies, not weeks.
Figure 7b. A 10-week transformation, with the 6-day target reached after 40 running wheel assemblies. The five numbered interventions are examples of many improvement initiatives. Bars and intervention positions are redrawn from the original case chart; the horizontal axis counts completed assemblies.
This was an operational excellence transformation. AI did not produce the reported reduction. The result matters because of how it was achieved: the functions changed their work together. No single manager could have redesigned all those dependencies within a departmental mandate.
Imagine instead that the company had asked every function to make its own value-creating activities faster, without changing the waiting between them. Attention would have gone to the green 2.8% of the flow.
Suppose the functions doubled activity productivity. The same value-creating work would take 10.5 hours instead of 21. With the other 723 hours unchanged, total lead time would fall from 31 days to about 30.6 days. A 100% productivity improvement in those activities would shorten the complete flow by only 1.4%.
Figure 8. A narrow functional transformation focuses on the green intervals. Doubling activity productivity saves 10.5 hours if the remaining 723 hours do not change.
Even the impossible upper bound of removing all 21 value-creating hours would leave 723 hours, or just over 30 days. Under this assumption, the maximum lead-time reduction is only 2.8%. That is the limit of improving the activities while leaving the rest of the flow untouched.
A local change can also release a bottleneck and reduce waiting. That effect matters precisely because it improves the whole flow. The calculation shows why we must evaluate improvements end to end, rather than stop at the departmental productivity figure.
Imagine the celebration if every function could report a 100% productivity improvement. The teams would have good reason to feel proud: they would have doubled the productivity of their activities. Yet in our calculation, the customer would still wait about 30.6 days. The main problem would remain, largely invisible in the functional reports.
That is the AI productivity paradox in miniature. We can be better within every function while barely improving the whole. Compare the 10.5 hours saved in that narrow example with the 600 hours removed in the real transformation. The gold mine lay between the functions, where work waited for information, a decision, a part or capacity. Reaching it required managers to change how the functions worked together.
Shorter lead time is not itself a complete measure of company productivity. Quality, delivery reliability, resources consumed and customer value also matter. But the Running wheel flow shows why we must measure success at the level of the whole. Departmental gains alone cannot tell us whether we have become a better company for our customers.
In our development team, AI helped us create code faster than we could review it. Over four months, the number of pull requests we opened increased roughly 2.5 times. A pull request is a code change submitted for review, so this measures output submitted for checking, not improvements delivered to customers.
Previously, reviews kept pace. Reviewing a change generally took less time than creating it, and we could usually clear the queue. With AI, changes arrived faster and were often larger. Understanding how they fit together, checking their behaviour and assessing their impact still took considerable effort.
We started calling it the "review death loop." An author would submit a change and start the next feature while waiting. By the time a reviewer finished one review, another change was ready. A few engineers who handled much of the reviewing felt this particularly strongly. Releases took longer, frustration grew, and reviews became rushed, with less thorough quality assurance. The gap here was between two stages within one team, rather than between departments. Faster creation had changed the balance of the work.
After people raised the problem, we met and agreed on changes. The author is responsible for understanding and checking the change before submitting it. A pull request should be a promise that the work is ready, rather than a handover of responsibility for making it work. We also started splitting large changes into smaller pieces and assigning review tiers based on complexity and risk. This helps reviewers judge where closer scrutiny is needed.
Alongside those agreements, we have built an AI-assisted review system tailored to our platform. It guides reviewers through changes and highlights areas that deserve extra attention. Our response combines process agreements, engineering and AI. Looking beyond code creation helped us identify what needed attention next.
We agreed on the process changes only two days ago, so we cannot yet say whether they have improved delivery. We already find it easier to judge the level of review a change needs, but that is an early impression. We are still testing whether those changes improve the complete workflow.
For us as CEO and COO, the decisive question is: what are we optimising? If the answer is a collection of departmental targets, AI will help us pursue those targets. If the answer is the flow that fulfils a customer need, we give AI a much more valuable assignment.
We do not yet know exactly how this will work in practice, at Hups or elsewhere. But we recognise a clear parallel with operational excellence: when the transformation is delegated to separate functions, the opportunity between them can disappear from view. We do not want our own company to repeat that mistake.
A recent conversation with the CEO of a very successful company inspired us. With a strong background in operational excellence, this CEO described a top-down approach to AI: leadership set the direction for the whole, while teams helped apply AI to redesign and improve complete flows across functions.
We are planning to visit the company to understand how they have implemented AI end to end. We want our entire management team to understand the approach: how leadership directs it, how the functions work together and how they judge whether customers receive a better result.
The first step is to identify all our primary flows: the customer and product flows through which we create value. Where do customers experience the greatest problems? Where do delays, poor quality or unreliable delivery most damage the business? That gives us a basis for deciding where to begin.
Then we can identify the secondary flows that contribute most to those problems and connect them to the primary flows they support. A secondary flow should be improved with a clear understanding of the customer result it must enable. That is how we will decide where AI can make the greatest difference.
We are still learning. The four management capabilities give us a way to ask better questions and examine our own AI agenda. They connect the technology to the decisions we must make as a leadership team.
Figure 9. Questions for the CEO and executive team. Use the four capabilities to direct AI towards customer outcomes and the performance of the complete flow.
For our prioritised flow, we need to give the managers a shared outcome and the authority to change how the functions work together. We need to analyse it, agree how work should move, make bottlenecks visible and establish joint routines. That understanding should guide our first AI experiment, which we must judge across the complete flow.
If we want to strengthen our competitiveness, we have to think about AI and the whole company together. We will now take this next step at Hups. We look forward to writing a follow-up article when we have results, sharing what we did and what we learned.
We would also like to hear about your experience. How have you used AI to improve complete flows and create more value for customers? Share your experience so we can learn together.
Dagens industri — Lämna inte bolagets framtid till it-avdelningen
Joel Sunnehall and Mikael Cato, 8 October 2026.
Are you interested and curious about Hups? Book a demo below to understand how we can help your organization understand and improve your flows.