The Operating Model Is the Bottleneck
Five engineers, seventy days, same queue
Tom Godden at AWS recently shared a story I found interesting. A rebuild of an AWS service "was originally scoped at thirty engineers for a year. Instead, with AI, five engineers did it in seventy days."
That's the line everyone remembers. The part I care about came next. Rahul Pathak, who runs Data and AI Go-to-Market at AWS, explained: "Initially, we automated writing code, but our security review, our deployment process, and the UI review were still the bottleneck. And so we didn't get code out into production any quicker, even though we wrote it faster."
The build shrank from a year to ten weeks. The work still waited in the same line.
I think most organizations are about to live their own version of that story. It's why I wrote a new paper, The Operating Model Is the Bottleneck: Seven Principles for Product Delivery When AI Is in the Loop. I won't repeat the paper here. Instead, I want to say what I make of it, including the question it leaves open.
We've been here before
The obvious response is that AWS just needed AI in the rest of the process too: in security review, deployment, and UI review. There's some truth in that, but more tools only help if the operating model changes to use them. Every earlier wave of technology taught the same lesson. People adopt a tool, discover it doesn't work without the matching system change, and see little improvement. I'm not the first person to say this. Michael Hammer described the problem in 1990, in his Harvard Business Review article “Reengineering Work: Don't Automate, Obliterate”
“Heavy investments in information technology have delivered disappointing results—largely because companies tend to use technology to mechanize old ways of doing business. They leave the existing processes intact and use computers simply to speed them up.”
“It is time to stop paving the cow paths. Instead of embedding outdated processes in silicon and software, we should obliterate them and start over.”
Thirty-six years later, AI is running the same experiment. In my post “The Question I Get Asked Most Since Leaving Scrum.org”, I argued that AI made building cheap but didn't make deciding cheap. Most operating models were built for a world where building was the scarce part: annual project funding, business cases, phase gates and handoffs between the people who decide, build and run. Speed up the building inside that machinery, and you don't get a faster organization. You get a longer queue in front of the next gate, which is what AWS found.
What The Operating Model Is the Bottleneck paper argues
My answer, described in the paper, is that the operating model now exists to protect three things AI can't supply on its own: Ddirection (clear, measurable outcomes for people and agents), ownership (a named human accountable for every result), and evidence (short loops that show whether the work changed anything).
It builds on the Agile Product Operating Model (APOM), which I developed with colleagues and the Scrum.org community, and cuts APOM's 59 guiding principles to seven that a leadership team can carry into a meeting. Each principle comes with a signal or two to watch and a small experiment to try.
Why I land on evolve, not obliterate
The paper deliberately leaves one question open. Should organizations evolve their operating model, or redesign the structure around their teams? It sets out both readings, because the evidence doesn't settle it yet.
I'd love to see companies redesign their operating models. But the reality is that every product sits in a web of dependencies: shared platforms, other teams' roadmaps, funding cycles, governance. Pull on one thread and a dozen others move. That makes radical redesign very hard, no matter how good the case for it.
So Hammer had the diagnosis right, but for most organizations his treatment is out of reach. Unfortunately, we have to evolve. That's why the paper ends with a diagnostic rather than a blueprint. Score the seven principles with a product team and its stakeholders, pick the one where it hurts most, run one small experiment, and check the signal. Then do it again. It's slower than starting over, but it's a change the web of dependencies can absorb.
The full paper covers the evidence, the seven principles and their signals, and first moves for executives, product and engineering leaders, Product Owners and Scrum Masters. It's a companion to From Production to Judgment: What AI Changes in Agile Product Delivery, which I wrote with Alan W. Brown and which looks inside the team.
The queue was always there
The hardest parts of product delivery have always been human: choosing which problem matters, stopping work the evidence says is failing, and getting an organization to absorb change. For decades, the cost of building partly hid them. Now they're in plain sight.
I'd love to hear where the queue has formed in your organization. Is it funding, review, governance, or something else?
AI didn't create the bottleneck. It just stopped hiding it.
Thanks to the APOM contributors whose work this builds on, including Krystian Kaczor, Andy Brandt, Bogdan Onyschenko, Konstantin Razumovski, Chad Beier, Ziryan Salayi, Yuval Yeret and Olivier Ledru. Claude, made by Anthropic, helped research and draft this post.
Sources
Quotations checked against the original pages on November 4, 2026.
Godden, T., Announcing the new AWS Reimagine report on AI, AWS Enterprise Strategy blog, September 24, 2026.
Hammer, M., Reengineering Work: Don't Automate, Obliterate, Harvard Business Review, July–August 1990.
Scrum.org, The Agile Product Operating Model and APOM Guiding Principles Have Published.
Comments