World Class
Manufacturing
in the Age of AI

Section 4Permalink

Organize Around the Flow

Manufacturing carries a structural paradox that predates AI and gets more expensive in its presence. Schonberger’s mismatch: operations planned as a straight line, the organization drawn as a ladder, and the real work moving in a tangle of crossing arrows between them. Under AI that mismatch costs more, because AI moves only as fast as the organization lets information move.

Conway’s Law is why it survives good intentions. Stated in a 1968 Datamation paper and popularised seven years later in Brooks’ The Mythical Man-Month: any organization that designs a system produces a design shaped like its own communication structure. A siloed plant builds siloed AI, however good the models are. You cannot buy your way past it. The limit on what AI is worth in a plant is organizational design.

What the coordination is actually buying

Harang Ju set out to test whether coordination is load-bearing. Not whether meetings are annoying, but whether the outcome would have been different without them.

His method is worth understanding, because it gives you a test you can run yourself. Take a piece of work and break it into steps. Then ask what happens at each step when new information turns up. In some work, a fact arriving late genuinely overturns what you already concluded, and you have to go back. In other work, information only ever adds to the picture, and nothing arriving later can make an earlier conclusion wrong. For that second kind, the people involved do not need to stay in sync. Each can work their piece and the pieces still fit at the end. The coordination is not correcting anything, because there is nothing to correct.

He ran that test across sixty-five business processes from a standard taxonomy and about thirteen thousand job tasks from the US occupational database. Around three quarters of the processes and four in ten of the tasks came out on the side where late information changes nothing.

From there he estimated the money. If coordination effort is spread roughly evenly across work, and that much of the work did not need coordinating to come out right, you land at somewhere between a quarter and a little over half of coordination spend buying no better answer. That is an estimate resting on an assumption rather than a measurement, and he says so.

Two things about the numbers matter for a plant. The task-level figure is the conservative one and it is the one that held up against a second dataset, so plan against four in ten rather than three quarters. And when he looked at management work on its own, it scored lowest, around a third. Managers coordinate about exactly the kind of work where late information does overturn earlier conclusions. So the overhead you can strip out is mostly not theirs, which is the opposite of what most people want to conclude from a finding like this.

Most plants carry the overhead as a meeting cadence. Shift handoff, daily production, weekly operations, monthly business review. Each tier compresses signal and passes it upward, and each one adds lag between a problem appearing on the floor and somebody deciding about it. Ju’s test sorts them. Where new information can still change the answer, the meeting is doing work and should stay. Where it cannot, the meeting exists to move information, and that is the part a system can do.

One thing to be careful with in the evidence. Anthropic’s Economic Index measures AI use by occupation, and production occupations are in it. They sit near zero, with a gap of more than three orders of magnitude between computer and mathematical work at the top and production near the bottom. A later report added a second measure, estimating how much of an occupation’s work AI could cover in principle, and production came out under 20%, among the lowest of the twenty-two groups.

Manufacturing has not been overlooked, then. It has been measured and the numbers are low. What both measures share is that they are taken through general-purpose chat and coding interfaces, which is not how a plant would deploy any of this. They describe how AI is reached today rather than what it could reach.

The target organization

Almost every meeting in a plant exists because a specialist knows something the flow needs. Quality knows whether that deviation can ship. Maintenance knows whether the bearing will hold until Friday. Materials knows whether the substitution is safe. Controls knows whether that parameter can be changed. None of that knowledge is in the room where the work is happening, so a meeting is arranged to bring it there, and the meeting runs at a cadence rather than at the moment the question came up.

That is the coordination Ju is measuring. It is not waste in the sense of people being idle. It is the cost of moving expertise to where a decision has to be made, one conversation at a time, in a plant where the expertise lives in people and people are in demand.

The change is to stop moving it conversation by conversation.

Functions publish instead of being consulted. Each specialist curates their own domain and puts it into a form that runs without them present. Quality publishes what a deviation means, what evidence a disposition needs, what closes a corrective action. Maintenance publishes failure signatures, the prior fixes on each asset, the conditions that warrant stopping. Materials publishes what a shortage means and what recovery looks like. Controls publishes what each machine can be asked and what it must never be asked. Each becomes a skill and a routine, held by a companion, available at the moment the question comes up rather than at the next scheduled review.

The specialist is not diminished by this. They stop being interrupted for the same fifteen questions and start owning the standard those fifteen questions were about. Their reach goes from whoever can get hold of them to everyone, all the time. That is the same trajectory World Class Manufacturing set in motion when quality moved from inspecting output to auditing the system and training the people doing the work. Everyone who has worked in manufacturing knows that a good portion of the day-to-day is firefighting to keep the line running. This is the path to invert it.

Operations consumes. The operations manager holds the flow and works that published capability into the decisions the day actually requires. This is what makes the broadened job possible at all. Nobody could carry several functions’ worth of technical depth, and nobody has to, because the depth is published rather than held.

And the meetings that were moving information no longer have to. That is the return, and it arrives in the currency an operations manager actually cares about, which is hours. The daily production meeting that exists so all functions can tell each other what they know becomes a shorter meeting about the decisions that are genuinely contested. The time that comes back goes to running the flow, which is the job.

AI companions sit between the two sides. They carry the published knowledge, skills and routines. The harness enforces which of them may act and which may only propose, and holds the record of what ran. The stack paper describes it as infrastructure. Organizationally, it is the thing that lets a function’s expertise reach the flow without the function being in the room.

Workflow engineering is what redesigns the process around this. Publishing a function’s knowledge is only half of it. The other half is going back through the process that used to require the meeting and rebuilding it without the handoff, which is Ju’s finding turned into a design instruction: for every step where late information cannot change the conclusion, the coordination comes out and the step runs on published capability instead. That is process engineering, not IT work, and it is why the assignment sits with someone who already understands the flow. The operations manager paper defines it, and its measure is its own redundancy: build the first two or three, teach each function to publish and each process owner to redesign, then shrink.

The risk this creates. A function that publishes badly is more dangerous than one that answers slowly, because a bad routine runs unattended and at scale. So published capability needs the same contract a data product needs: who owns it, what it promises, and how anyone would know it had drifted. A published routine with no owner is a historian tag with no owner, one layer up.

The boundary on operator empowerment

The same logic runs downward. Give AI to the operator in direct support of the task in front of them, rather than routing insight through an analytics layer above them. The operator stops waiting for an answer and gets one at the machine, which means they resolve what they can and pass on only what is genuinely novel. The specialist still exists. What changes is that the questions reaching them are the ones worth their time.

This has a limit. If a companion has expert capability and immature judgment, and if supervising it is itself expensive, then handing the least-supervised person in the building an unbounded supervisory load is a new coordination tax. The answer is guardrails built into the harness, audited by the responsible specialists.

What does not change

None of this makes the World Class Manufacturing pillars obsolete. Cost deployment still needs validated root-cause analysis rather than faster numbers. Autonomous maintenance still depends on operator ownership of the equipment closest to them. Quality at the source still means the person doing the work catches the defect first. Steelmakers are already putting copilots into the control room to surface procedures and equipment history to the operator rather than to an analytics team, which is quality at source with a new tool.

What changes is the shape of roles inside each pillar, and World Class Manufacturing described that direction before this technology existed. As operator-centred maintenance and quality matured, inspection and repair staff shrank while the remaining roles grew in judgment, pay and standing. AI accelerates a pattern the discipline started decades ago, because it lowers the cost of extending judgment rather than concentrating it.

What to own

Christensen supplies the mechanism. Early in a technology’s life, when the product is not yet mature enough, integrated architectures win, because only a company that controls the whole interdependent system can optimise across it. Once performance overshoots what customers will pay for, the architecture modularises and value moves to whoever owns the remaining performance-defining piece.

We are in the infancy of generative AI for manufacturing. Hence, this is the time for every organization to build their own tailored system.

The harness is where the technology is not yet good enough and the parts are still interdependent. Nobody can sell a manufacturer a finished answer to how its own value stream should run, which is Christensen’s early-stage condition exactly. The interface layer is a bit further advanced and is standardising visibly, which is why the Asset Administration Shell, Catena-X and i3X exist at all. Rebuilding a data-access contract in-house pays a premium for a piece that no longer defines performance.

Tesla shows the first half. Its integration runs past the vehicle into the factory, and gigacasting works only because product design and factory design are treated as one system rather than two disciplines handed between departments. TSMC is the counter-example that sharpens it. The pure-play foundry model works because the interfaces between design and fabrication matured into documented standards, which is a sign of a more mature industry rather than a less advanced one.

Section 5Permalink

The AI-Native Operations Manager

Two things follow from the previous section. The first is a role: one person per plant who owns the flow from order received to part shipped, held to it as one result rather than several functional ones. The second is that every other role changes shape around it, unevenly. Schonberger sorted plant support functions in 1986 into those that end up with better support and fewer people, and those that get drawn in further. That forty-year-old sort predicts which functions AI absorbs and which it amplifies.

The job that already exists

There is no new role here and no new title. The job is the operations manager, or the operations director in a larger business. What changes is the work, not the label. The label is left alone on purpose. A new title is a new box on the chart, and the argument against the edge twin is the argument for why a new box is the thing an organization knows how to reject.

Three things change. The scope widens to the whole flow instead of a functional slice. The measurement collapses to one number instead of several. The escalation route closes. The third is the real change, and the first two follow from it.

Escalation was never a bad habit. It was honest. The operations manager escalated because the depth genuinely sat elsewhere. Maintenance knew the equipment, quality knew the process capability, finance knew the cost model. Arbitration was the only fair way to resolve them against each other, and that is why every earlier attempt at this role produced a coordinator with a calendar instead of an owner with a result. AI puts enough of that depth on the operations manager’s side of the table that the decision no longer needs a specialist standing behind it. Nobody forbids the escalation. There is nothing left at the other end.

Software made this shift already. Twenty years ago a product shipped through a chain of functional owners: an architect, a QA lead, an operations engineer, a project manager coordinating between them. Today one product manager typically owns a feature end to end. The technical complexity did not go away. Tooling absorbed enough of it that one accountable owner could hold the whole outcome. Manufacturing is at the early edge of the same change.

Clark and Fujimoto named the two versions of the role in 1991. A lightweight manager assembles the positions and escalates for arbitration. A heavyweight manager decides. Their construct is broader, measuring integration inward to the functions and outward to the market, but the escalation route is the part that carries here, and the part invisible on an org chart. Both versions routinely carry the same title, which is why the performance gap between them was a finding rather than a definition.

The flow has been the acknowledged unit of optimization for decades without ever having an owner. Schonberger’s third geometry, the actual movement of jobs across a plant, is not a design in the way the process and the organization are designs. It is what those two produce between them, and no discipline owned it. Goldratt arrives at the same gap from the other direction. Subordinating everything to the constraint requires authority over everything being subordinated, and a plant organized by function has no such person by construction. Both identified the whole as the right unit. Neither could say who holds it. That is the question capability now answers.

The structure has to follow. A broadened operations manager only works inside an organization built around flow rather than function. Widening the scope inside a functional structure recreates the old coordination problem with more people reporting into it.

The change is easiest to see as a revision to the job itself rather than as a new box on a chart. What follows is the role most plants already staff in fragments, written out whole.

The deletions matter more than the additions. Nothing in the new column is a new activity, plants have always needed someone to make those calls. What changes is that the coordination work in the red lines was the price of not having anyone who could hold the whole flow, and it is that price, rather than the specialists themselves, that AI removes.

Two guards belong in the design rather than in the caveats. Nobody’s reporting line moves, but the operations manager now decides the trade-offs between several functions, and that is a decision about how functional time gets spent. It carries the risk the Toyota structure was built to avoid. Maintenance is the clearest case. Every week the operations manager decides whether the millwright runs the schedule or the preventive plan, and every week the schedule is the urgent one. The PM interval slips from four weeks to six. Condition data stops being reviewed because nobody has the hour. The failure history stops being written up. Two or three years later the equipment knowledge is gone and nobody can say which week it went.

So the functional standard stays with the function that publishes it. The quality specialist maintains and publishes the standard. The operations manager decides against it, not about it. The same holds for the PM plan, the tooling spec and the inspection frequency: the function sets the interval, the operations manager decides what runs when.

And functional capability is measured on what it publishes. Is the standard current, is it used on the floor, has it drifted from what the process actually does. That gives each function a number of its own that is not the flow’s output, which is what stops it becoming a cost line, because principle three predicts exactly what happens to the half nobody measures.

One per plant is the right shape, reporting where the role already reports. No function is consolidated and no box on the chart is redrawn, which is why a plant can grant the decision right, watch it for a quarter, and take it back if the person cannot carry it. Splitting the role across several value streams recreates the coordination problem one level down, because the trade-offs that matter most are the ones between streams competing for the same constraint. Lifting it above the plant into operations leadership puts the owner outside the building where the result is produced, which is the arrangement the whole role exists to correct.

Workflow Engineering for Business Processes

The operations manager decides. The operator holds the judgment. The companion does the functional work and runs whatever routine it has been given. What is missing is the person who writes the routine, and that conversion is what the whole approach depends on.

The task has two components. One is documenting what an experienced person knows into a skill and a routine. The other is identifying which task within a workflow can be automated through a companion.

Workflow engineering is a responsibility, not a job. Somebody already employed should hold it alongside what they already do, in the same way a plant assigns a safety representative or a kaizen lead. Nobody’s title changes, which is deliberate for the same reason the operations manager keeps theirs, and practical besides. Most importantly, you can get started without adding headcount. You can design it as a fractional role by freeing 20% of a person’s time to get started.

So how do we shape this fractional responsibility? In other places the market has shaped a role called forward deployed engineer. It sits at the vendor rather than at the plant. Postings grew roughly 42-fold between 2023 and 2025, against 13-fold for AI engineer roles, and AWS committed a billion dollars in June 2026 to an organization built around embedding these engineers with customers. The diagnosis behind that spending is one sentence: the bottleneck in enterprise AI moved from model access to deployment capability. The role is defined as someone who enters the operating environment, finds a high-value problem, builds against real data, navigates the organizational constraints, and stays until the thing is adopted.

That is the capability a plant should not rent. An outside integrator is right to prove the first workflow and wrong the moment the plant needs someone who can extend it without calling back.

Definition. Fractional responsibility held by one person per functional department. Responsible to serve the operations manager’s goals, while working to their function’s standards.

Four responsibilities. Build the first workflow products in the function. Elicit and codify tacit judgment into skills and routines. Coach others to do it themselves. Steward the harness and the standards.

One measure separates it from every adjacent role. The workflow engineer should be needed less on each successive build, because the specialists are doing more. If build five takes as much of them as build one, the role has become an internal forward deployed engineer and the capability never transferred.

Where it should sit, and where it should not. The default answer will be IT, and it is the wrong one. IT has the technical capability. What the job needs is credibility on the floor, because it means eliciting judgment from people who have held it for thirty years, and that is not something the IT function has or can quickly acquire. Putting it in IT also puts the work outside the flow, which is the arrangement this whole approach depends on avoiding.

Where to get started

Four starting points work well, and each produces a different version of the same assignment. The four responsibilities do not change. What changes is where the person starts and what they will get wrong.

Read the last column as a diagnostic, not a personality sketch. Every blind spot in it is the same failure: skipping one of the four responsibilities. The automation engineer skips codification. The lean practitioner skips build. The quality engineer skips coaching. Materials skips the floor, building the flow correctly and never eliciting what the person running it actually knows.

So pair people rather than appointing one. Two origins working the same flow produce something neither would alone: maximise the difference in orientation, minimise the difference in capability. The capability half is now the easy half.

How much of their time. Twenty percent, the fraction 3M settled on in the 1940s and Google adopted later. Not a fixed day.

What protects the time is a working group with clear goals. The builders across the functions meet on a fixed cadence to show what they built, what they codified and what broke.

At smaller scale this is the same person as the operations manager, which is unavoidable and fine. Defining it separately still matters, because permanently conflating the two produces one of two failures: an operations manager who cannot build, or a technical person held accountable for a result they do not control.

Derived roles: the kinds of contributions each function will have to make.

Two things have changed since I studied thought worlds in 2017. The designer is now plural, because publishing domain capability is something every function will have to do. And the intermediary is partly supplied on demand via AI companions.

Implications for existing roles

Every other current role changes shape around the above mental models, and the shape of the change is not uniform. Schonberger saw the split in 1986, before any of this technology existed: simplification does not affect all support functions the same way. Some get better support with fewer people. Others get more involved, because their work is design rather than transaction, and there is suddenly more of it worth doing. His two lists, forty years on, turn out to be the augmentation-versus-automation sort this blueprint argues for.

Core manufacturing: the value-adding work itself.

Supporting functions: better support, fewer people. Schonberger's first list covers the functions whose work was largely transactional coordination on behalf of the line. These shrink in headcount and rise in judgment, which is the trajectory World Class Manufacturing already set in motion decades ago through attrition and redeployment rather than through layoffs. The paper on job loss treats that distinction directly.

Supporting functions: more involvement. Schonberger's second list covers the functions whose output is design and judgment. These do not shrink. Their reach extends, because the analysis that used to gate their work now costs almost nothing, and the constraint moves to how many good decisions they can make.

Governance rhythm sits across all of them: tiered meetings that surfaced problems on a lag give way to signals surfacing as they occur, and the meetings that remain shift from status reporting to the decisions that genuinely require several people in a room.

Read the right-hand column carefully, because it is where most AI proposals fail. Every cell describes a loop that closes, it starts at a trigger and ends with a record written, a standard updated, or a decision teed up for a named person. None of them ends at detection. A companion that notices the bearing is failing and stops there has not taken a workflow; it has produced another alert for someone to triage, which is the group drive error in a new medium: the technology installed, the arrangement of the work left alone.

The pattern across every row in the table above is the same. AI does not remove the need for judgment. It moves judgment closer to the point of work and raises the bar on what judgment is worth. The operator who once escalated a problem now evaluates a proposed answer. That is a different job, and it requires a different kind of training, trust, and accountability than the World Class Manufacturing model was built around.

Section 6Permalink

Beyond the Organizational Edge

Everything proposed so far runs into the same obstacle, and it is worth naming before the next part describes what to build.

An organization defends its current arrangement. Not out of stupidity or fear, but because the arrangement is what produced every result anyone in it has been rewarded for. A new way of working arrives without a track record, competes for the same people and the same capital, and asks the organization to accept short-term disruption for a return nobody can yet demonstrate. The existing structure treats it the way an immune system treats an unfamiliar cell. This is a rational response, not a pathology, and it is why so many good ideas die at the second site rather than the first.

The standard answer to this problem is to stop fighting it. Build the new thing outside the reach of the immune system, prove it works there, and reintroduce it once the evidence is undeniable. The exponential-organization work that came out of Singularity University gave this a name, the edge twin: a separate unit with its own governance, its own metrics and its own permission to break the rules of the parent. The logic is sound and the recommendation is widespread.

The record is worse than the logic suggests.

What the edge actually delivered. General Electric built the most ambitious version anyone has attempted. GE Digital was created in 2015 as a standalone division headquartered in San Ramon, at its peak employing roughly 28,000 people, funded with more than four billion dollars over eight years. It was an edge twin with every advantage: executive sponsorship, separate location, its own talent, and a platform in Predix that was technically serious.

It was sold. And the reason it failed is the one that matters for this section. GE's own divisions did not want to use it. Aviation, the crown jewel, had already built its own analytics capability and regarded Predix as a step backward. The edge twin worked, in the narrow sense that it produced software. The core rejected it anyway.

This is not an isolated case. By the end of 2023 roughly 40% of the top 200 companies had established their own innovation labs, and from 2024 onward the trend reversed toward reintegration. Walmart shut down Store No. 8, its technology and business innovation unit, with its own COO observing that it is very difficult for any one team to be the subject matter expert and the technology expert at the same time. Ford closed its Silicon Valley innovation lab, saying its innovation efforts had evolved to be more integrated across departments. Mastercard's CTO put the diagnosis most plainly: treating innovation as something off to the side rather than something every team does daily is the mistake, and innovation is like ethics in that it has to pervade the whole organization.

The edge twin solves the wrong half of the problem. It is an effective answer to the immune system and no answer at all to what happens next. Proving a thing works at the edge does not make the core capable of running it. While your edge twin runs, the parent has usually spent the intervening years becoming less able to absorb it rather than more.

For manufacturing this matters more than for most sectors, because the thing being transformed is the core. A bank can run a digital brand at arm's length. A plant cannot run its production at arm's length. The value stream, the equipment, the operators and the customer commitments are all in the core, which means the core is where the change has to land or it does not land at all.

So the question this section has to answer is how to get past the immune system and define what the core organization has to become.

What the research says about the core

The relevant work here is on thought worlds (introduced earlier as “mental models”), a concept from product innovation research describing a community of people engaged in a domain of activity who share an understanding of that activity. In manufacturing firms these have traditionally been functional departments. Thought worlds differ along two dimensions: orientation, meaning the cognitive imprint a group has acquired from its own history, and resources, meaning its knowledge base and its capabilities.

A practical view would be to see orientation as the lens from which you look at a problem. Resources are the methods and approaches you learned. If you work in a quality department and your plant does not make enough parts, you likely look at it from the perspective of how many parts had to be scrapped and which part dimension did not achieve capability based on an SPC chart. Maintenance will not look at these and instead look through downtime codes.

I studied this in 2017 in commercial aircraft manufacturing, interviewing across OEMs, suppliers and adjacent digital entrants, and the central finding was counterintuitive enough to be worth restating carefully, because it contradicts what most transformation advice recommends.

The prevailing view held that cognitive distance between collaborating groups should be minimised, on the reasoning that a shared worldview drives successful innovation and reduces goal conflict. The evidence qualifies that. Differences between thought worlds have two opposing effects at once. They have a direct positive effect on the speed, quality and volume of innovation, because new combinations of knowledge are where innovation comes from. They have an indirect negative effect, because they degrade the quality of cooperation, which in turn degrades outcomes. The direct positive effect prevails.

That produces a design rule sharper than "reduce silos":

Maximise differences in orientation and knowledge. Minimise differences in capability.

The capabilities that must be held in common are three. Co-creation, the ability to integrate knowledge from customers and partners. Orchestration, the ability to manage innovation at the boundary of the firm rather than inside it. Dynamic capability, the ability to reconfigure the firm in response to what is learned. Where these three differ between the people who have to work together, cooperation quality falls and outcomes fall with it. Where orientation and knowledge differ, outcomes rise.

Two more findings carry forward. The first is that a firm doing this is running two structural frames simultaneously: the hierarchy of parts, which is how product and technological innovation has always been organized, and the network of patterns, which is how digital work is organized. Neither replaces the other. The core has to hold both, and the friction between them is not a transition problem that resolves.

The second is that the activity splits into three roles with different profiles. We introduced these earlier. Ideators hold deep product knowledge and an exploitative orientation, and their job is to share what they know rather than to integrate it. This is our core operations team. Designers are balanced across dimensions and work within the ecosystem, integrating knowledge across partners. These are our fractional workflow engineers. Intermediaries carry the strongest explorative orientation and the strongest co-creation, orchestration and dynamic capabilities, and their contribution is perspective from outside the ecosystem entirely. These are the external partner perspectives. Confusing the three is a common and expensive error, because an ideator placed at the boundary of the firm will underperform there and stop contributing what they were good at.

What nine years changed

Three things have moved since that work, and they move the answer.

The scarce input is no longer access to outside knowledge. The 2017 argument assumed that heterogeneous knowledge had to be reached for, through open innovation, ecosystem partnerships and external talent, because it was expensive and hard to find. That assumption is weaker now. A meaningful share of what intermediaries used to supply, meaning perspective and method from outside the industry, is available on demand.

Which makes the capability half of the rule much easier and the orientation half much harder. Capability differences were the friction, and capability is exactly what levels quickly when a companion carries codified method. Orientation differences were the fuel, and orientation is a product of who you hire, what they have lived through and how the organization has historically rewarded them. It does not level on demand and it cannot be trained in a workshop. So the constraint has moved. The binding question for a manufacturing organization is no longer whether its people have the skills. It is whether the organization contains enough genuinely different ways of seeing the problem, and whether it has arranged itself so those differences meet rather than escalate.

Innovation outside the firm boundary is less necessary than it seems. The 2017 recommendation was an organizational switch inside the firm and a venture arm outside it, precisely because bringing external orientation inside was so costly. The cost has fallen. What remains necessary is the switch, meaning a mechanism that reconfigures the core based on what is learned. This is the gap that will be filled by AI companions and AI-native workflows.

The path

Four things describe a core organization that can absorb this rather than reject it.

One. Accountability sits with the core, not beside it. The broadened operations manager is a line role inside the plant reporting to the plant manager. Not a transformation office, not a digital unit, not a centre of excellence. Every structure that puts the accountability outside the operation recreates the GE Digital failure at a smaller scale, and the small scale does not make it survivable.

Two. Difference is designed in, and capability is levelled. Put people with genuinely different orientations on the same workflow, which in practice means an operator, a controls person, a quality person and someone from outside manufacturing altogether. Then redesign it. Different lenses on the same workflow beat functional diversity for this work, and functional diversity is what most plants have. So go a level deeper into individual mental models when selecting your initial group.

Three. Incentives have to reach the new work. The activities this blueprint describes sit in the network-of-patterns frame, and almost no existing incentive plan measures them. Someone who spends a day a week codifying their own judgment is doing the highest-value work available to the plant and, on most scorecards, doing nothing at all. This is the same multitask result behind principle three: unmeasured effort decays, however willing the person.

Four. Senior commitment has to be structural rather than verbal. In the 2017 interviews, the arrangement that worked was one where responsibilities were held group-wide at the top, so no division could argue that a group initiative was somebody else's concern. The plant equivalent is that the operations manager's broadened remit is not negotiable department by department, and that the person they report to says so out loud, more than once.

And one warning that has aged unusually well. Kodak built the first digital camera in 1975 and the first digital photo-sharing service in 1996, fourteen years before Instagram. It did not fail because digital technology disrupted its business model. It failed because early success with digital technology was misread as evidence that the company could succeed at a digital business, so it never reorganized. That misreading has a name worth carrying: success bias. A plant with one working AI pilot and an unchanged organization is in exactly Kodak's position, and it feels like progress from the inside.