Lessons from Electricity on Redesigning the Operating Model for AI

What happens to our ways of working when AI makes output cheap? I have spent 35 years in this industry and learned how to plan, estimate and manage product development. I recently joined an AI Native company, built around Claude, where people lead on outcomes and agents do the outputs. When I looked for the familiar things, such as stories, a backlog, sprint planning and daily standups, they were not there as I knew them. I had to shift my thinking and learn a new way of working.

There is a precedent. The first electric motors were sold on cost: they were cheaper to run than steam engines, so factories dropped them in where the engine had been, and productivity barely moved. Paul David's 1990 account is the best explanation I know: the engineers had spent their careers making the steam engine and its lineshaft layout work. Electric motors made a different layout possible, but the large economic gains came only after they unlearned their previous ways of working and designed a factory around the work instead of around the shaft.

I think we are in the same place. Much of the talk about AI is about cutting operating costs by replacing people in the processes we already have. Our traditional ways of working were built to manage outputs, because our capacity to create outputs was limited. Those practices are now our lineshaft. If the factories are a guide, the gain comes from redesigning how we work, not from swapping people out of the old design, so our operating models have to shift to managing outcomes.

I'll share the lessons so far: which of those practices we let go, including the ones I was most attached to. We run on AI-Native SAFe, the Scaled Agile Framework's version for AI, which organizes people and agents around outcomes instead of outputs. It is one example of an AI Native operating model, and you don't need to use SAFe to take something from it. You'll leave with a worksheet for finding the steps in your own process that exist because of an old constraint, and for asking why they are still there.

About Steve
Steve is a Strategic Advisor with Enterprise Movement with more than 35 years of experience building mission-critical systems, from digital telephone switches and metro railway signaling to a 32-million-subscriber billing platform. If you remember TTL, PDP-11s and macro assemblers, LISP, and can solder, you’re in his demographic.

That industrial grounding shaped his central conviction: technology adoption is a socio-technical problem. The biggest determinant of lasting success isn’t the technology, it’s an organization’s capability to learn how it decides, executes and adapts. Steve believes this applies double to AI adoption, where a purely technical focus puts attaining value with AI at risk.
Steve holds a PhD in Electrical and Computer Engineering from UBC, is a SAFe SPCT, and an AI Native Trainer. He has contributed to the IIBA’s BABOK Guide, published numerous papers and articles on software engineering. He is co-author of Patterns for Effective Use Cases and The Rock Crusher.