Steve Adolph — SPCT, Advisor, Enterprise Movement · 24 September 2026
Co-written with Claude.
Every AI conversation eventually arrives at the same question: when does this pay off? The answer may be buried in a piece of factory history.
The Shaft That Ran the Factory
Steam powered the 1880s factory, and that power was mechanically distributed using a "line shaft." The line shaft was a long rotating spine running the length of the building, driving machines below through a tangle of belts and pulleys. It worked, but it was rigid. Friction losses were a well-known drawback of the design, with energy bleeding off at every belt and pulley before it ever reached a machine. The greater drawback was the line shaft dictated the factory's layout, because every machine had to sit near the shaft. Workflow bent to physics.
Very little about the factory changed with the arrival of electricity. The electric motor simply took the steam engine's spot at the end of the shaft. It was cleaner, more reliable, and cheaper to run. Those were real improvements. But the belts and shaft stayed. The layout stayed. Productivity, as measured by output, barely moved. In modern architectural terms, factories had replaced one implementation with another without changing the architecture around it. The motor was better, but the system continued to organize work around the same constraint.
The real transformative change came a generation later, when small, reliable "unit" motors became cheap enough to put one on every machine, breaking the dependency on the shaft entirely. Factory owners could now arrange equipment around the optimal flow of material rather than around the geometry of mechanical power transmission, and the productivity gains were substantial. Yet, as economic historian Paul A. David argued in "The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox" (American Economic Review 80, no. 2, May 1990, pp. 355–361), the transition was constrained by more than the sunk cost of existing factories. The knowledge of how to design and operate those factories had also accumulated around the old architecture. Engineers, factory architects, managers and workers had learned how to make the line shaft system work. Exploiting electricity therefore required learning how to design an entirely different kind of factory. Eventually the electric motor ceased to be the bottleneck; the harder problem was replacing an operating model built around a constraint that no longer existed. Extending David's insight to today's context: organizational information structures can become a form of sunk capital too — and unlike machinery, they do not physically wear out and force us to replace them.
Today's Line Shaft
That's the arc electricity took, long before AI: a slow, underwhelming first act, followed by a payoff nobody expected until people stopped treating the new technology as a faster version of the old one. Don't automate the line shaft — that's the lesson for us. This piece is about outcomes the old way of working couldn't reach at all. Along the way, AI will also make existing work faster — more stories drafted, more code generated, more output per hour — and that's a fine thing to take too.
Most AI adoption inside agile teams right now looks like electricity's first act. For example, product owners use AI to draft user stories faster, or developers use it to generate code and tests. Meetings are summarized by AI. These are real gains, just as replacing the steam engine with an electric motor produced real gains. There is nothing wrong with taking them. But like that early phase, these gains aren't transformative. To transform, like the managers of those newly electrified factories, we have to learn to change our thinking.
Consider how work commonly moves through an agile software development organization. Strategic intent is decomposed into progressively more detailed artifacts, translated into work items, prioritized, placed into backlogs, refined, assigned and eventually pulled into execution. Much of that architecture exists because humans have limited capacity to continuously interpret strategy, maintain context, coordinate dependencies, assess changing evidence and decide what should happen next. AI can make many of those activities faster. But if all we do is accelerate the creation, refinement and movement of the same artifacts through the same system, we may simply have installed a better motor on the line shaft.
Whether a backlog, user story or planning artifact should disappear isn't the point — those constructs may still be useful. What matters is whether the architecture connecting strategy to execution still needs to work the way it does today.
That is where AI-Native SAFe begins to point toward something more interesting. Rather than assuming that a human must continuously translate strategic intent through a hierarchy of manually curated artifacts, it introduces an outcome tree that connects strategy more directly to execution. Teams can use AI to help maintain context, interpret evidence, explore options and continuously adjust the path toward an outcome. The important word here is outcome. AI is making the production of many outputs dramatically cheaper. We can create more stories, more analysis, more code and more documentation than before. But producing more artifacts does not necessarily mean we have created more value.
AI-Native SAFe — Scaled Agile's own evolution of the framework — doesn't call this construct an output tree. That distinction matters more than it might seem, because it's where the line shaft metaphor needs a caveat of its own: in an 1880s factory, more output was the winning outcome, because the market for manufactured goods was nowhere near saturated. That's not the case for most knowledge work today, and it's especially not the case as AI makes output cheap. A team that ships more stories and more code faster hasn't necessarily produced anything anyone needs more of. What matters now is which outcomes become reachable that weren't before — which is exactly what an outcome tree, and the faster learning cycles AI-Native SAFe builds around, are trying to answer.
From Faster Work to Faster Learning
The distinctive capability of AI may ultimately be less about how quickly it can produce an artifact and more about how dramatically it can reduce the cost of learning. Organizations spend enormous amounts of time gathering information, reconciling competing views and deciding what to do next. Those activities form the feedback loops through which an organization learns. Historically, many of those loops have been slow and expensive. As a result, we designed operating models around that limitation. Decisions were aggregated upward. Planning happened periodically. Information was packaged into reports. Work was decomposed into increasingly detailed artifacts so that intent could survive its journey through the organization.
Those practices were not irrational. They evolved around real constraints. AI changes some of those constraints. If teams can continuously sense changes, interpret evidence, preserve context and explore alternatives at much lower cost, then we can begin asking whether the operating model itself should change. The bigger opportunity is shortening the distance between sensing something, understanding it, deciding what it means, and adapting what we do next — not just doing the existing work faster. That is a very different kind of productivity.
Where You Sit on the Continuum
This isn't a situation where you're either AI-Native or an AI laggard. AI-Native won't look the same for every organization, and it shouldn't. Enterprise Movement was built AI-Native from the ground up. That gives us opportunities to organize work and make decisions in ways that would be much more difficult inside an established enterprise. Two conditions make that possible for us: we had a greenfield opportunity, and we operate in a market where the ability to learn and adapt quickly matters competitively.
Many organizations operate in a different context. An established enterprise may have decades of technology, governance, regulation and organizational history embedded in the way it works. A safety-critical organization will appropriately retain constraints that a consulting company does not have. Those constraints are real.
What actually matters is sorting the constraints worth keeping from the ones nobody has questioned in years. That is why AI-Native is better understood as a continuum than a destination. The right answer might be augmentation, automation, or a structural change — it depends on which constraint you're looking at. The question remains the same: where could faster sensing, feedback and learning produce better outcomes than simply doing what we already do more quickly? The answer will be different for every organization. In many cases, adopting the technology will be easier than unlearning the shape of the system we built before it arrived.
The Real Lesson of the Line Shaft
The real lesson of the line shaft has nothing to do with speed. A faster motor didn't touch the constraint underneath in 1900, and generating more AI output, faster, doesn't touch it now. The payoff comes from asking, honestly, whether the constraint you're optimizing around still needs to be there at all, and what faster feedback and learning could do for you within the constraints that remain.
- Where are decisions slow because information previously had to travel through people and hierarchy?
- Where are handoffs necessary because context was difficult to preserve?
- Where are planning cycles long because analyzing alternatives was expensive?
- Where are teams maintaining artifacts because the organization once needed those artifacts to coordinate work?
Some of those practices will remain necessary. Others may turn out to be line shafts: structures we continue to optimize simply because we have forgotten why they were there in the first place. Redesigning how the organization senses, learns, decides and adapts — not just automating the work we already know how to do — is what AI-Native thinking is actually for, now that some of the constraints that shaped the old system are changing.
So perhaps the most useful question to ask about your AI strategy is not:
Where can we use AI?
It is:
Where are the line shafts in our operating model?
If you want to find the line shafts in your own operating model, talk to us.
Go deeper:
- AI-Native SAFe Big Picture — Scaled Agile's own framework for this evolution, straight from the source.
- Why Traditional Project Management Fails for AI Initiatives — the backlog problem, examined from the delivery-model side.
- Creating a Decision Vacuum — the leadership counterpart to what an outcome tree does mechanically: giving up top-down control so others can decide faster.
