AI can significantly compress enterprise software implementation timelines. That does not eliminate the constraint. It moves it.

Consulting firms are telling engineering leaders that coding agents mean you can flatten the org, cut coordination layers, and move to autonomous tiny teams. But in the enterprise trenches, most teams aren't decoupled feature teams—they are system teams with heavy cross-team dependencies. 10x-ing code generation without fixing organizational coupling doesn't eliminate scaling overhead; it just floods downstream queues with unintegrated PRs and dependency waits.

In this solo episode, Yuval Yeret breaks down what scaling frameworks (SAFe, LeSS) actually do in the age of AI, why procedural coordination collapses while structural complexity remains, and how to use coding agents at your system bottlenecks to continuously descale without breaking delivery.

Notable Quotes:

"If your organization requires 4 portfolios, 8 value chains, and 16 pods to align before a single customer epic can ship, 10x-ing code generation just produces more unintegrated PRs and longer dependency queues. That isn't throughput—it's activity theater."

"Scaling frameworks exist for one reason: to manage the coordination overhead forced on you by your current dependencies. As long as those dependencies exist, you need to manage them somewhere."

"Don't just create smaller teams, call them tiny, and assume they will 10x without fixing the architecture and the system around them."

Links & Resources:

- Read the companion article: https://yuvalyeret.com/blog/most-of-your-scaling-apparatus-is-now-optional

- Organizing teams around outcomes: https://yuvalyeret.com/blog/when-and-why-do-we-need-a-product-operating-model

- Kevin Fox's Blue Light (Theory of Constraints): https://theoryofconstraints.blogspot.com/2007/06/toc-stories-2-blue-light-creating.html

Scaling AI: From Activity to Impact — For leaders trying to turn AI activity into real business impact.

Insights (and help/advice) on scaling AI from activity to impact — yuvalyeret.com/insights

Yuval's Linkedin – https://www.linkedin.com/in/yuvalyeret/

"We are now developers, not of the code. We are developers of the system."

Most AI coding rollouts end up with faster typing and the same delivery system. Shay Mandel's team at Ergo-Next Insurance went after the system instead. They broke the whole product development lifecycle into skills an agent runs — problem definition, PRD, engineering review, technical design, implementation, testing, code review — and told everyone to stop writing the artifacts and start fixing the thing that writes them.

00:00 Welcome, and why this conversation
00:31 Shay Mandel, Ergo-Next Insurance, and 200 people building product
03:46 What you should get out of this conversation
05:14 Breaking the development lifecycle into skills
06:37 The engineering review skill that runs before engineering reviews
08:38 How the engineers actually feel about it
10:40 Developers of the system, not of the code
11:11 Auto-improvement loops: pointing an agent at a KPI
14:21 Where humans still decide, and where they don't
21:21 Digital twins of your best insurance experts
22:20 Ask-engineering and ask-product agents across time zones
24:21 What changed in how the work is managed, and what didn't
29:24 Epic-level Kanban and flow metrics for human and agent handoffs
30:39 Advice for leaders starting the journey
31:32 Setting expectations: 60% to 95%, and why the last 5% needs a human
33:29 When you tell a PM to open a terminal, you lose them
35:24 Avoiding skill sprawl: one shared brain, not 200
37:44 Beyond product and engineering: actuaries, finance, HR

"They are not supposed to write anything on their own anymore. They just need to fix the skills or fix the context." - Shay Mandel

"The initial version will probably be sixty or seventy percent accurate, and we'll get to ninety or ninety-five. The extra five percent is why we need a human in the loop." - Shay Mandel

"You need to think from a product perspective, even about your AI harness and your AI capabilities." - Yuval Yeret

Links and resources
Shay on LinkedIn: https://www.linkedin.com/in/shaymandel/
Product Leaders AI meetup: https://luma.com/ProductLeaders.ai
Yuval's Linkedin – https://www.linkedin.com/in/yuvalyeret/
Scaling AI: From Activity to Impact — yuvalyeret.com/insights

Don't Redesign Your Process Yet. Change Who Writes the Artifacts. – https://yuvalyeret.com/blog/change-who-writes-the-artifacts-before-your-process

How Next Insurance Broke Its Whole Lifecycle Into Agent Skills – https://yuvalyeret.com/blog/how-next-insurance-broke-its-lifecycle-into-agent-skills

Most enterprise AI conversations get stuck on the wrong number: how many tokens an employee should be allowed to burn. Tomer Elias argues the cap is the least interesting question in the room. The hard part is attribution, knowing whether any of that spend moved a business metric at all. We compare notes on what enterprises are actually doing right now, why AI keeps exposing organizational problems that predate it, and what has to be in place before "AI impact" means anything.

About the Guest

Tomer Elias is a product executive with more than 15 years leading startups from zero to one and one to 100, through unicorn and IPO stages. His focus has been AI and data throughout. He was part of the first AI lab in Israel, helped build a cybersecurity unicorn, and served on a committee defining agentic identity standards alongside OpenAI, AWS, and Cloudflare. He is currently mapping how enterprises adopt AI and where they sit on the maturity curve.

Chapters
00:00 Why this conversation
00:54 Tomer's background: AI labs, a cyber unicorn, agentic identity standards
02:26 What actually changed with gen AI: ambiguity
02:50 Human operating systems and agent operating systems
06:17 Setting a token cap, and why the number isn't the point
07:19 Measuring outcomes was broken long before AI
08:43 Activity, output, outcome, impact: what the work really looks like
10:55 AI surfaces the organizational DNA you never fixed
11:19 The factory lens: an industrial engineer's view of the enterprise
14:31 Goldratt and the constraint: where AI actually pays
15:56 Two levels of observability: spec conformance vs. value
19:00 A worked example: meeting transcripts as context
20:33 Kill criteria and staged funding for AI experiments
22:41 Build vs. buy, and the question nobody asks first
25:09 The rise of the business engineer
25:50 The digital twin that knows your stack
28:06 Data infrastructure: the real enterprise blocker
30:05 Closing the loop: telemetry, usage, decisions
34:12 Psychological safety and toxic token usage
39:32 Security guardrails: MCP safety, DLP, sandboxes
42:54 Who builds beyond product and engineering?
46:54 Teaching product skills instead of staffing PMs

Notable Quotes

"AI puts the credit card at the hand of the employees. But without the oversight and training, costs can spiral. But high usage doesn't really mean a bad thing. It's not good or bad. The question is what's the impact that you get out of that." — Tomer Elias

"Once you implement AI in your organization, it surfaces your DNA and the organizational culture that didn't change for a while and now needs to change if you really want to push impact with AI." — Tomer Elias

"Any improvement away from the bottleneck or from the constraint is meaningless, and any improvement directly at the constraint is a real multiplier." — Yuval Yeret

"If it's a healthy DNA, people would feel safe to experiment. And if it's a toxic culture, you would get toxic token usage and activity theater." — Yuval Yeret

Links and Resources
Tomer Elias on LinkedIn: https://www.linkedin.com/in/tomer-elias1

If you're working on turning AI activity into business impact, I write about this every week in the Scaling w/ Agility newsletter.

Scaling AI: From Activity to Impact — yuvalyeret.com
The Scaling w/ Agility Newsletter – yuvalyeret.com/insights
Yuval's Linkedin – https://www.linkedin.com/in/yuvalyeret/

How to Measure AI Impact Beyond Token Caps – https://yuvalyeret.com/blog/how-to-measure-ai-impact-beyond-token-caps

Is Your Agent Harness Still Learning? Check Its Last Updated Time. – https://yuvalyeret.com/blog/your-agent-config-is-standard-work

In this special episode, host Yuval Yeret flips the script with guest Philip Morgan, an expert on positioning and point of view. They discuss the recent rebranding of the podcast and dive deep into the striking parallels between historical Agile Theater and the emerging risks of AI Theater. Discover why measuring raw activity—like tokens consumed or lines of code written—is a trap, and how organizations can shift toward measuring tangible business outcomes and flow efficiency. You'll also learn about Unreasonable Agility and what happens when R&D goes on the offense.

Chapters

00:08 The Agile Shift in AI and Podcast Rebranding

01:07 Philip Morgan's Background in Positioning

02:36 Yuval's Role as a Plumber for Engineering Pipelines

06:53 How Pain and Opportunity Drive Change (Gillette & Biotech Examples)

15:51 Introspective and Compound Engineering

17:08 Exploring AI Theater vs. Agile Theater

21:44 Shifting Bottlenecks: From Coding to Code Review and Adoption

28:04 The Trap of Vanity Metrics and Token Maxing

33:26 Moving from Output to Outcomes and Business Impact

40:50 Breaking the Status Quo and Resisting AI Mandates

56:21 Unreasonable Agility: Taking R&D on the Offense

Notable Quotes

"If you want to succeed with it, find somebody who talks about the principles, who understands it in depth, who can make changes while still being aligned to the spirit." - Yuval Yeret

"People will find a way to use AI without really getting any value. They will find a way to generate a lot of activity, but not really create any change in the impact." - Yuval Yeret

"There's a sense in which it seems like Agile was sort of waiting for AI." - Philip Morgan

Ready to stop measuring tokens and start measuring real business outcomes?

Reach out to Yuval at yuvalyeret.com or [email protected] to discuss how to build unreasonable agility into your organization.

About PhilipPhilip Morgan is a positioning and point-of-view expert who helps independent service providers thrive by leveraging effective market positioning. He is the author of multiple books on the topic and shares his insights freely at ⁠philipmorgan.net⁠.Scaling AI: From Activity to Impact — yuvalyeret.com

The Scaling w/ Agility Newsletter – yuvalyeret.com/insights

Yuval's Linkedin – https://www.linkedin.com/in/yuvalyeret/

Agility Might Have Been Waiting for AI – https://yuvalyeret.com/blog/agility-might-have-been-waiting-for-ai

Claude and Codex have a relatively new feature — `/goal` — that lets you set a completion condition and keep the AI running autonomously until it's met.

This capability exposes a real challenge with agentic AI and explains why its shifting the bottleneck to its assymetric capabilities in different stages and domains of value creation.

00:09 The new /goal capability — what it does and how it works

02:07 What the official examples reveal: all output, no outcome

03:02 The missing examples — what outcome-oriented goals would actually look like

04:00 Output vs. outcome: why the gap matters for AI impact

04:45 The real bottleneck — observability and closing the feedback loop

05:45 Live demo: setting an outcome-oriented /goal on a blog post

08:30 What the loop did — changes made, open items, what's next

Are your AI goals output-oriented or outcome-oriented? What are you doing to enable outcome-oriented goals in your AI sessions?

And as a final thought - What would happen if your human teams were empowered to seek a /goal?

Insights on Scaling AI from Activity to Impact

Join the Activity to Impact Conversation on Linkedin

Goal-Based Loop Engineering: From Spec-Driven to Outcome-Driven – https://yuvalyeret.com/blog/ai-agent-completion-goals-aim-at-outcomes

AI coding assistants are genuinely good now — coding, debugging, tests, docs. But faster engineering output doesn't automatically become faster business impact. AI has quietly moved the bottleneck: from building working software to validating whether that software creates value for anyone who adopts it.

This episode uses flow thinking, cumulative flow, and the theory of constraints to help leaders see where AI speed is creating congestion — and where human + AI effort should be aimed next.

Key takeaways:• AI creates speed, not automatic value — speed only counts if it improves end-to-end flow• AI impact is asymmetric: engineering scales faster than discovery, adoption, and value validation• Local productivity can create system-level congestion once the bottleneck moves• Tech debt hides the new bottleneck — engineering absorbs extra capacity into easy-to-validate cleanup• Inventory is the signal: watch where work waits, loops, or gets reworked• Subordinate human and AI effort to the current constraint — don't spread enablement evenly

Chapters:00:00 — The promise of AI in engineering02:04 — Why AI's impact is asymmetric05:02 — Spotting the moved bottleneck07:56 — From activity to impact: visualizing flow10:19 — Driving adoption, not just output13:15 — Subordinating people and AI to the constraint15:47 — Continuous improvement and real value

Monday morning diagnostic — pick one AI initiative and ask: What outcome should it improve? Where does work wait or get reworked? If this team gets 2x faster, which group becomes the constraint — and what AI support should be redirected toward them?

"You can 10x engineering and still not 10x the business. Don't force everybody to scale - help the constraint scale."

If this helped, share it with a leader trying to turn AI activity into real business value.

Most AI programs start by measuring activity: licenses, prompts, token usage, and pilots. Some move on to output: more code, content, or analysis. Neither tells you whether the business moved.

In this solo episode, I explain the three levels of AI adoption: activity, output, and impact. The common trap is local productivity. One team can produce more while end-to-end delivery gets slower because the real constraint is somewhere else.

The practical test is simple. Name the business outcome that is stuck, identify the constraint holding it back, and ask whether AI is moving that constraint. If you cannot answer that, you are probably measuring AI theater.

Chapters
00:00 From AI activity to impact
03:59 Why more output can make flow worse
07:24 Use AI at the business constraint

Read more
Why Your AI Effort Has Activity But Not Impact
More on moving from AI activity to impact

Follow Yuval on LinkedIn

Zoetis is reducing a 26-day infrastructure workflow to 2-3 days with a three-agent pipeline. One agent designs, another produces infrastructure as code, and a third executes.

I talk with Kumar Venugopal, CTO of Zoetis, about moving from personal AI productivity to organization-wide impact. We cover the four levels of AI integration, the operating-model changes behind faster delivery, and why design thinking becomes more important as agents get faster.

Kumar also explains how fast prototypes change build-versus-buy decisions, which skills employees need, and why Zoetis is doubling down on Agile while delivery cycles compress.

"The real opportunity with AI isn't strictly automation. It's how you embed it into how we make decisions." - Kumar Venugopal

"We are doubling down on Agile. Even the agentic approach has to be built with a minimum viable product approach, with proper user stories. The cycles are a lot faster, but the process doesn't go away." - Kumar Venugopal

Chapters
00:00 Introduction - from 8086 to the AI era
03:01 Why this AI wave feels systemically different
05:30 AI in veterinary diagnostics and decision-making
08:12 The four levels of AI integration
11:01 Infrastructure automation - 26 days to 2-3 days
13:57 Design thinking as the missing AI skill
16:29 Build vs. buy - can vibe coding replace SaaS?
19:26 Who does this work and what is the real constraint?
21:58 Three competencies every employee needs
25:11 Why Agile is more important now
27:45 Scaling AI beyond the technology organization
30:30 Kumar's three-step change model for leaders

Links and resources
Kumar Venugopal on LinkedIn
Zoetis CTO on AI operating-model change
Scaling AI: From Activity to Impact
Yuval Yeret on LinkedIn

The question isn't how many product owners you need. It's how many genuine product problems your product actually has.

In the final episode of this three-part series, Yuval Yeret works through the most complex version of the product ownership question: what happens when a product has grown to multiple teams? The default answer — one team, one product owner — often creates titles without real ownership, especially when teams are organized around technical components rather than product value. Yuval walks through when multi-team product leadership genuinely works, when it doesn't, and what the more uncomfortable conversation underneath usually turns out to be about.

This episode lands the series with the most structurally challenging scenario, and connects product ownership topology directly to team design — one of the most consequential and often avoided conversations in scaling organizations. Essential listening for product directors, heads of engineering, and CTOs navigating a growing product org.

• The right question: Not "how many product owners do we need?" but "how many genuine product problems does this product have?" — a reframe that clarifies the structure instantly.
• Mini-products inside a larger product: When teams are organized around real, independently deliverable slices of product value, multi-leader structures work well. The razor example makes this concrete: shaving experience, handle design, packaging, and price viability are all genuine product problems that can be owned semi-independently.
• The symptom vs. the diagnosis: If your teams can't deliver value independently, giving them product owner titles won't fix it. The ownership problem is a symptom. The team design problem is the diagnosis.

"Product ownership only really makes sense when a team can deliver something of genuine value independently. When they can take a customer problem, work on it, and ship something that actually moves the needle — without needing three other teams to complete it first."

"Giving each of those teams a product owner doesn't change the underlying dynamic. It adds titles without adding real ownership. And what you often end up with is product owners who feel like they should have more authority than they do, and teams that are still fundamentally waiting on each other."

"If your teams can't deliver value independently, the product ownership question is a symptom. The underlying question is whether the team structure is set up to enable that kind of independence — and if not, what it would take to get there."— Yuval Yeret

Related reading on yuvalyeret.com:

• When and Why Do We Need a Product Operating Model?

Are your teams structured around genuine product problems they can own end to end? Or around technical components that make independent ownership hard?

Experiment to try this week: Pick one team in your product org. Ask them: what's the last thing you shipped that delivered value to a customer without depending on another team to complete it? If they struggle to answer, you have a team design question hiding inside your product ownership question.

Yuval Yeret helps leaders maximize outcomes through strategic, nuanced agility. As both a SAFe Fellow/SPCT and Professional Scrum Trainer, Yuval is frequently brought in to help organizations evolve from agile theater and feature factories toward product-oriented agility — building on existing investments rather than starting over.

📩 Start here: Scaling w/ Agility Crash Course — a free email course to help you scale without falling into the process theater trap.

🔗 Follow Yuval on LinkedIn: linkedin.com/in/yuvalyeret