Two industries, same arc — different timescale70 years vs ~10-15 yearsMANUFACTURING — 70 years1911Taylor1931Shewhart1950sDeming1980sOhnoDEMING MOMENTSOFTWARE — ~10-15 years (compressed)2017Transformers2022ChatGPT2025agents2030?Meta-Software matureDEMING MOMENTthe compression is the story

Software's Deming moment is already here

1 de junio de 2026·Foundations

Manufacturing took about 70 years to move its center of gravity. Not 70 years to invent new tools — 70 years to shift what the dominant human work actually was. From producing the parts, to governing the systems that produce the parts.

Software is doing the same thing right now, and I think we're going to do it in a decade instead of seven. That compression is the part that keeps me up.

The curve you already know

Let me lay the manufacturing arc down quickly, because it's the cleanest analogy I have for what's happening to our profession.

Taylor, 1911. Scientific management. The human task gets codified — broken into measurable, repeatable steps. The worker still does the work, but the work is now legible enough to be studied.

Shewhart, 1931. Statistical process control. Now the variance gets codified. You're no longer just measuring the worker; you're measuring the process the worker is inside, and you're modeling when it's drifting out of spec before the defect ships.

Deming and Ohno, the 1950s through the 1980s. The shift completes. The line does the production. The dominant human work becomes governing the line — quality systems, kaizen, andon cords, the discipline of stopping the line when the system tells you something's wrong. Same job at the highest level (good products to the customer). Entirely different center of gravity for where humans spent their hours.

That's the curve. Roughly 70 years from Taylor to a settled post-Deming, post-Ohno operating model.

The parallel with software in the mid-2020s

Producing code is becoming cheap. Not instantly, not uniformly, but structurally — the marginal cost of generating a reasonable first draft of a function, a service, a migration script is collapsing toward zero in a way that's already irreversible.

Which means the dominant work is shifting. Toward what? Toward governing the systems that produce code. Observability over what the agents are doing. Structural validation that the output is shaped correctly. Contextual continuity so the agent doesn't lose the thread. Automated governance so policy isn't enforced by code review at 11pm.

That category — the supervisory layer over agentic production — is what I call Meta-Software in paper §4. Meta-Software is to software what SPC was to manufacturing: the category that becomes central precisely once what used to be central turns into commodity.

That's the Deming moment. The point where you stop trying to make production better at the unit level and start trying to make the system that does production better at the system level. Manufacturing crossed it once. Software is crossing it now.

Analogy mappingMANUFACTURINGSOFTWAREScientific managementcodified prompting / spec-as-codeStatistical Process ControlMeta-Software (obs/val/ctx/gov)Operator governs the lineOperator governs the agentswhere analogy BREAKStimeline · contestability · agency

Three places where the analogy breaks (honestly)

I'd rather name where the analogy strains than pretend it doesn't. Three places.

Timeline. Manufacturing had 70 years. Software likely has 10–15. That compression changes the political dynamics inside organizations. In manufacturing, a worker who started cutting parts in 1920 could plausibly retire before the Ohno-era operating model fully took hold. In software, the practitioner who joined in 2020 will live through the entire transition during their career, and probably during their current job. That doesn't just change training; it changes the social contract between the person and the work. There's no "wait for the next generation to adjust." The current generation has to adjust, mid-flight.

Tangibility of quality. A part out of spec gets measured against a micrometer. A partially-correct agent output gets debated in PR comments. Manufacturing had the enormous advantage of physical measurement — the part either fits the tolerance or it doesn't. Software quality has always been more contested, and agent-produced software is contested at a new level. "Is this code correct?" is harder to answer than "is this part round?". That makes the governance layer harder to build, because the rules it has to enforce are themselves under negotiation.

Agency of the operator. The milling machine doesn't choose what to attack. It does exactly what the program tells it. The agent does choose — within a scope, within a prompt, within a context, but it chooses. That difference demands governance categories SPC never needed: intent verification, scope containment, refusal pathways, escalation logic. The manufacturing playbook gives us the shape of the answer but not the specifics, because the thing being governed has a kind of agency milling machines never had.

Those three are real. The analogy doesn't survive being pushed too hard on them. I'd rather you know that going in than discover it later.

Why the analogy still earns its keep

Despite the strain, I keep coming back to it. Because it hands you two operating questions that I haven't found a better source for.

The first: what fraction of your team's hours go to producing versus governing production? Not the org chart. The actual time, this week. If you sat with each engineer for an hour and asked them what they did, how much of it was generating new code versus reviewing, validating, contextualizing, governing what agents (or other engineers) produced?

The second: which direction is that fraction moving, quarter over quarter? Because that's the leading indicator. The fraction itself tells you where you are. The trajectory tells you where you're going.

If your org has already crossed 50% — if more than half the dominant work has shifted from production to governance — you're on the other side of the Deming moment. Even if nobody told you. Even if you still describe yourselves as a software shop and not a Meta-Software shop. The center of gravity moved while you were heads down.

What this is and isn't

This isn't a prediction that everyone becomes a manager. The Deming-era operator in a Toyota plant wasn't a manager in any conventional sense. They were a highly skilled practitioner whose skill had shifted from making the part to making the line make the part well. The skill didn't disappear; it relocated.

That's what I expect for our profession too. The Mixer-fluent practitioner I write about isn't a junior turned PM. They're someone whose technical depth has been redirected — from generating code directly to governing the system that generates it, while still being close enough to the substrate to know when the system is lying to them.

The manufacturing analogy gives us permission to take that shift seriously instead of treating it as a side effect. SPC was a category invention. Meta-Software is a category invention. The shape of the response — new metrics, new roles, new training, new tools — is going to look more like what Toyota built after 1955 than what most software orgs are building today.

And we have to do it in a tenth the time.


Where do you sit on that fraction? If you had to guess your team's number — production hours vs. governance-of-production hours — what would it be, and how much has it shifted in the last 12 months?

#AI #DigitalTransformation #FutureOfWork #TechLeadership #Innovation

Escríbenos por WhatsApp