FEATURE – Drawing on lean's history, the author explains why organizations adopt AI more slowly than it advances, and what it really takes to close the gap.

Words: Art Smalley

This article is being published simultaneously on Planet Lean and lean.org

AI model capabilities are advancing rapidly, but adoption inside established organizations is moving much more slowly. In hindsight, I don’t think that is much of a surprise.

Technical discussions in the media tend to focus on what the next generation of models will do. I have no doubt that the models will continue to improve, and tools will become easier to use. However, organizations must still decide how the technology will be used. This involves training people, redesigning work, connecting systems, establishing permissions, managing risk, and coordinating changes across functions. In my experience, none of that occurs automatically.

This is not the first time organizations have faced a gap between a powerful new method and their ability to absorb it. I spent time this past week reflecting on the current situation in light of more than a century of scientific management and lean improvement practices. Three questions stand out in my opinion for AI adoption:

1. where will thinking about work reside?
2. why does technical and domain depth remain necessary to support visible practices?
3. how will improvement progress from individual tasks to flows of work and, ultimately, across the enterprise?

My conclusion is that events will not move as rapidly as one might think.

SCIENTIFIC MANAGEMENT AND THE LOCATION OF THINKING

Let’s start with the longer historical view and consider the work of Frederick Winslow Taylor at the end of the 19th century and beginning of the 20th century. His work was revolutionary in many respects. He attempted to replace custom, intuition, and rules of thumb with systematic observation and analysis. His actual contributions were much more than a stopwatch applied to manual labor.

Taylor spent decades studying metal cutting. He examined the relationship among the material being cut, the cutting tool, heat treatment, tool geometry, cutting speed, feed, depth of cut, cooling, machine power, and tool life. His experiments contributed to high-speed tool steel and produced practical knowledge about feeds and speeds. This was a substantial application of scientific thinking to physical materials and machines.

Taylor’s better-known contribution, however, was the systematic study of human work in manufacturing. This work had a different organizational impact. Taylor explicitly transferred much of the planning of work from the worker to management. Planning departments developed methods, set time standards, selected tools and speeds, and issued written instructions. Workers were selected and trained to perform the specified tasks.

Now, in fairness, Taylor also advocated cooperation, training, better shop-floor instruction, shared responsibility, and even higher wages. But the structural division remained clear; management developed the science and selected the method, while the worker executed the planned task.

Industrial engineering carried parts of this pattern forward in 20th-century manufacturing. Industrial engineers commonly studied methods, measured work, established labor standards, balanced production lines, designed plant layouts and material-handling systems, and supported production planning and cost reduction in daily work activities.

By contrast, from the 1950s forward, Toyota made a different organizational choice. Toyota, of course, has domain-specific technical engineers (I will discuss their role in the next section). However, in operations, Toyota made the decision to ensure the people closest to the work had a higher degree of influence in the planning, execution, and improvement of the work. Toyota trained its workforce in work observation, time and motion awareness, waste elimination, process mapping, and other basic improvement techniques. The most famous culmination of this is known as standardized work.

Importantly, this is one practical expression of respect for people. The person doing the work is not treated solely as the executor of a method designed by someone else. The employee has input into how the actual work is performed.

I think it is critical that we recognize that AI presents the same organizational choice with a newer and equally powerful set of analysis tools. A company can place AI expertise in a central group that builds agents, analyzes work, and then tells other people how their jobs should be performed. That approach may produce some useful applications. It will also recreate the old division of thinking and executing. The experts think, and the rest of the organization executes.

My prediction, based on lean’s history, is that the more successful companies over the long run will enable people to use AI to analyze and improve their own work while retaining a voice in how it is performed.

VISIBLE TOOLS AND THE TECHNICAL SYSTEM UNDERNEATH THEM

The second historical parallel I reflected upon concerns actual technical depth. Most people encounter lean through visible plant-floor elements, such as standardized work, kaizen, pull systems, kanban, workplace organization, visual boards, and problem-solving routines. These practices matter, but they do not explain Toyota’s success by themselves.

For example, a one-day plant tour emphasizes what visitors can see: material moving, andon signals, standardized work charts, and team meetings. These practices can be photographed, taught, and copied. Conversely, Toyota’s capabilities in product development, production engineering, supply-chain coordination across the Toyota Group, marketing, research and development, and the wider Toyota Production System are less visible and take years and often millions of dollars to develop. Much of that work remains poorly understood outside the company. Frankly, it is just harder to explain, and the more domain-specific it becomes, the more technical and less applicable it is to the masses.

Consider something as basic as a crankshaft for a moment. An internal-combustion engine contains controlled combustion events with peak in-cylinder gas temperatures around 2,000°C. The resulting forces pass through the pistons and connecting rods to a crankshaft rotating at several thousand revolutions per minute, while journals and other critical features must be produced to tolerances measured in microns.

Typically, more than 300 individual steps were required to convert a crankshaft from a raw forging to a finished component. The material-removal operations are automated. Human work consists mainly of tool changes, quality checks, machine cleaning, troubleshooting, and related support. Producing the component requires control of steel chemistry, forging, heat treatment, rough machining, oil passages, hardening, grinding, polishing, dimensional accuracy, surface finish, fatigue strength, and precision measurement. JTEKT, the Toyota Group company that builds Toyota’s grinders, reported in 2019 that its small CBN crankshaft grinder holds roundness on the eccentric portion of the shaft to 1 micron or less and keeps dimensional variation within 2 microns. That performance requires specialized machines, grinding wheels, bearings, controls, measurement systems, process knowledge, and specific maintenance routines.

I spent most of my Toyota career in engine manufacturing in Japan at Kamigo Engine Plant. Back then, we thought it took about seven years to become proficient in these engineering basics. Standardized work, in contrast, was a 10-hour training class. Yes, operator standardized work was important, but no standardized work chart could determine the correct material, design a crankshaft grinder, establish a heat-treatment condition, determine a datum and material-removal amounts, diagnose a spindle problem, or hold a journal to a few micrometers of tolerance. Those are not simple human time and motion considerations. They are hard mechanical engineering calculations, and those capabilities came from different technical functions inside Toyota working together.

At Toyota, we call this body of technical documentation Work Standards, not Standardized Work. The most important engine-manufacturing standards are developed during pre-production engineering activities involving interdepartmental work among product development, production engineering, process suppliers, tooling engineers, and the plant’s manufacturing engineers. In powertrain operations, the work results in highly technical documents called operations drawings, tooling layout drawings, precision quality measurement sheet, and the static accuracy chart. When I helped set up Toyota’s first full-sized overseas engine machining plant, for example, I had to standardize about 20 types of machine-specific documentation. You would not recognize the names of them, and none are as basic as “Standardized Work.” My point is that the domain knowledge that supports TPS is often hidden due to its technical complexity, and this is true in every functional department in the company.

Additionally, some of that critical technical depth extends across the Toyota Group. Toyoda Machine Works, for example, began when Toyota Motor Corporation separated its machine-tool division in 1941. Later in 2006 it became known as JTEKT, which continues to build dedicated crankshaft and camshaft grinding equipment as well as other types of specialty equipment today. Similarly, Toyota’s largest parts supplier, Denso, carries deep capability in powertrain controls, fuel injection, sensing, ignition, and related electronics. These are separate companies with customers beyond Toyota, but their history and capability are part of the technical base supporting Toyota.

The result is not merely a stable production line. It is often a technological achievement in the product itself. For example, in late 2016, Toyota announced the new TNGA-based 2.5-liter Dynamic Force engine for deployment beginning in 2017. Toyota reported maximum thermal efficiency of 40% for the conventional version and 41% for the hybrid version. At the time, Toyota described those figures as world-leading thermal efficiency.

Kanban, standardized work, and shop-floor kaizen contributed to producing the engine reliably at scale. They did not, however, create the underlying combustion science or product and process technologies. Achieving this efficiency required improvements in high-speed combustion, intake-flow design, direct injection, valve-seat technology, variable control, cooling improvements, friction reduction, and reduced pumping and exhaust losses. The engine, in turn, was part of a larger vehicle system. Its production required processes and equipment capable of turning the design into thousands of reliable parts. Toyota detailed this breakthrough at technical conferences and in various journal publications. The lean world, however, generally does not have much interest in this type of improvement. It is just too domain specific for most people to grasp.

AI has a similar technology stack problem. The accessible layer includes chat, prompting, image generation, document analysis, and simple task automation. These tools allow almost anyone to produce a useful result quickly, and that accessibility is real progress. I equate these to the most visible elements of TPS, such as standardized work, kanban, andon, and 5S.

Building reliable applications for the deeper AI organizational tech stack, however, requires software engineering, data architecture, model selection, context design, evaluation, cybersecurity, permissions, infrastructure, integration, monitoring, and domain knowledge. These skills are harder to develop and are less visible to most parties.

I am not saying that AI should remain solely in the hands of technical specialists — that would repeat the division of thinking and execution described in the first historical parallel. My belabored point is that just giving people access to a chat interface does not create an enterprise AI capability. Companies that succeed over the long run will also have to develop capability throughout their technology stack.

ADOPTION AT THE TASK, FLOW, AND ENTERPRISE LEVELS

The third historical parallel I reflected upon concerns scale. Improvement becomes more difficult as it crosses the boundaries among people, processes, systems, and functions.

Lean was usually adopted first through very local practices. Individuals and teams organized workplaces, documented standardized work, installed visual controls, and conducted kaizen on specific jobs. They could see the work and influence the immediate area. These gains mattered, but they did not automatically connect production planning, purchasing, suppliers, logistics, quality, engineering, maintenance, or other functions. That required additional management coordination and planning.

AI adoption is following a similar path in organizations. A person can prompt a model, analyze job-specific material, create reusable instructions for an AI agent (a SKILL.md file), summarize documents, draft communications, generate an image, or automate a bounded task without redesigning the surrounding organization. This can produce real gains, but isolated examples are often difficult to add together. Just speeding up work at one point does not produce overall throughput paced to takt time. Even at the task level, the organization must decide what data the system may access, which actions it may take, how exceptions are handled, who approves the result, how errors are detected, and who remains accountable. Technical integration and organizational capability are inseparable.

The enterprise level is harder as well. An automotive company, for example, must coordinate markets, product strategy, research and development, product development, production engineering, purchasing, suppliers, manufacturing, distribution, sales, finance, human resources, and management. A hospital, retailer, bank, or logistics company has a different set of functions, but the coordination problem remains.

At this level, each function has its own goals, specialized knowledge, established measures, and authority over part of the system. Enterprise improvement requires those functions to make compatible decisions over different time horizons. A product decision can change engineering requirements. A purchasing decision can affect quality and lead time. A decision about financial metrics can change management behavior. A local AI application may improve one decision while shifting cost, risk, or work into another function. Coordination is therefore part of the technical problem, not merely an administrative detail added after the tool works.

The original lean research by James P. Womack, Daniel T. Jones, and Daniel Roos addressed this wider scope. The Machine That Changed the World covered designing the car, coordinating the supply chain, operating the factory, dealing with customers, and managing the enterprise. Yet, as Professor Womack often lamented, readers often remembered it chiefly as a factory story, even though the factory chapter occupies only about 30 of roughly 270 pages. Visible practices such as kanban, standardized work, value-stream mapping, and kaizen events eventually dominated adoption, while the broader enterprise argument received less attention.

This is my strongest caution for AI enterprise adoption. Focusing only on what is easy and visible to apply will not produce the greatest organizational gains. You can “vibe code” a standardized work application, an engineering change instruction system, or a new supplier measurement system. That does not guarantee enterprise coordination or system-level improvement. An ERP system upgrade, for example, does not automatically improve the underlying work it supports.

At enterprise scale, AI must connect to accumulated software, data, permissions, and responsibilities. An apparently simple application may need to read from an enterprise resource planning system, retrieve the authoritative document, respect access controls, write to another application, preserve an audit trail, and notify the person accountable for the next decision. Each connection requires decisions about access, responsibility, control, and acceptable failure. The model may perform its cognitive step well while the application fails because data are incomplete, interfaces are brittle, or responsibility for exceptions is unclear.

Established organizations generally add AI to systems and responsibilities already in place, often through features in incumbent software. Individual bottom-up use will therefore spread faster than improvement across flows, and flow-level applications faster than enterprise redesign. Some organizations will develop AI-native operating models, but most will add useful tools while the larger coordination problem remains.

CONCLUDING THOUGHTS

The history of improvement does not, unfortunately, provide a formula for implementing AI. It does, however, offer several cautionary tales and help explain why adoption is likely to be slower and more deliberate than headlines often claim.

First, decide where thinking about work improvements should reside. A central AI group should build technical depth and common capability throughout the organization. However, it must do this without taking improvement responsibility from people who understand and perform the work.

Second, be sure to develop AI and domain expertise together. Access to AI does not replace software, data, engineering, security, evaluation, or the technical knowledge held across enterprise functions. It does not automatically design a better product or process. It does give you a bigger and better tool for analysis.

Third, match the scope of improvement to the opportunity. Task-level changes are easier, but their gains are limited. In contrast, end-to-end and enterprise redesign are harder because they cross systems, functions, and responsibilities. Their potential rewards are also larger because they can eliminate handoffs, delays, and waste that isolated task improvements cannot reach.

Finally, I suggest thoughtful metrics that reflect the actual performance of work. The number of licenses, prompts, demonstrations, tokens consumed, and agents says little about whether the organization is creating more value, solving problems more effectively, or developing people. AI is powerful, but without careful application it can also automate waste and produce poorer work at greater speed and scale.

Lean history provides some context regarding why organizations adopt new technology more slowly than the technology itself improves. Organizations absorb new capabilities through their existing people, knowledge, systems, and management practices. The pace of AI adoption will therefore depend on more than the rate at which state-of-the-art models improve. It will depend on how quickly organizations can learn to redesign work and develop the people and systems needed to use them well.

_THE AUTHOR