Yuval Yeret: Scaling AI from Activity to Impact

In this conversation, Yuval Yeret discusses the challenges and strategies for managing software development in the age of AI. He emphasizes the importance of transitioning from mere activity to impactful outcomes through evidence-based management and spec-driven development. In this conversation, Yuval Yeret discusses the transformation of software development practices through AI and the importance of empowering teams to focus on outcomes rather than just outputs. He emphasizes the need for organizations to adapt their processes to leverage AI effectively while maintaining core principles of agile and product-oriented development.TakeawaysAI doesn't guarantee impactSpec-driven development enhances discipline Empowering teams enhances outcomesAI reshapes software development processesChapters00:00 Navigating AI in Software Development02:59 The Role of Evidence-Based Management07:17 The Shift to Spec-Driven Development14:52 Understanding AI's Impact on Innovation19:55 Managing Workflow and Bottlenecks25:46 Empowering Teams for AI Success27:19 Empowering Teams for Effective Problem Solving28:30 AI's Role in Software Development30:29 Shifting Focus from Requirements to Outcomes32:10 Navigating the Transition to AI-Ready Practices34:38 From Output to Impact: Measuring Success35:03 The Importance of Intent and Outcomes in Development40:50 Continuous Improvement in Product Development42:57 Building a System for Future DevelopmentLinkedin Live Event - https://www.linkedin.com/events/7514364891558785024/?viewAsMember=trueMore insights on Scaling AI in Software from Activity to Impact - https://yuvalyeret.com/category/agentic-development-lifecycle/

When nobody can predict the next five months, let alone five years, what does it mean for a leader to be agile? Brad Farris coaches owners and CEOs of professional services firms through what he calls a polycrisis: AI reshaping the work, shifting expectations between owners and the people who deliver it, and geopolitical shocks on top.We talk about what agility looks like in practice for a managing partner, not a product team: admit you don't know how this will go, stay anchored on the mission and the people you serve, agree on outcomes before debating how, and take the smallest step that moves you toward them. Then we turn to the harder question for anyone who built their reputation in product and engineering: how do you bring these ideas to the rest of the organization without arriving as the person who is there to fix them?Key takeaways:Start by admitting "I don't know how this is going to go." Without that, planning is pretending.Get agreement on the mission and outcomes before anyone jumps to the how.In the fog, take the smallest step toward the outcome, check what you learned, and repeat. More people running experiments means more information.Don't show up as the fixer. Sit on the same side of the table and let people create the solution through small experiments.Move from expectations to agreements: both sides can negotiate, and that is the first step toward trust.Agile principles fit well beyond product and engineering, but distill them to first principles and leave the mandates behind.Chapters:00:00 Fog, uncertainty, and the need for agility01:09 Brad's path from consulting to executive coaching02:22 The polycrisis facing professional services firms05:30 What agility means in practice for a CEO06:27 Admitting "I don't know" and renewing the mission08:16 Outcomes as the North Star10:13 Developing your company like a product13:39 Small experiments when you can't see ahead16:07 Bringing agility beyond product and engineering20:03 Getting on the same side of the table22:41 Consulting vs. coaching: who owns the problem24:29 Agile coaches and leader accountability29:54 Co-creation and accountability34:31 What leaders do between sessions36:05 Agreements vs. expectations37:49 Principles without the mandates40:02 Where to find BradAbout Brad:Brad Farris is an executive coach at Anchor Advisors in Chicago. For 25 years he has worked with leaders of growing businesses, mostly professional services and creative firms in the $2M to $50M range.Join Brad's weekly email, The Conversation: https://anchoradvisors.com/join-the-conversation/Brad on LinkedIn: https://www.linkedin.com/in/bradfarris/Brad on why there are no generalized solutions: https://anchoradvisors.com/there-are-no-generalized-solutions/Further reading from Yuval on developing your company like a product: https://yuvalyeret.com/category/develop-the-company-as-a-product/Scaling AI: From Activity to Impact — yuvalyeret.comInsights (and help/advice) on scaling AI from activity to impact — yuvalyeret.com/insightsYuval's Linkedin – https://www.linkedin.com/in/yuvalyeret/

AI can significantly compress enterprise software implementation timelines. That does not eliminate the constraint. It moves it.Julie Hodge, AI Strategy & Operations Leader at Zuora, joins me to discuss how AI is changing professional services, customer onboarding, and the relationship between product and services. We use Zuora's Milo implementation agent and digital quote-to-cash twin as a concrete example, then follow the implications downstream: customer testing and change capacity can become the next bottleneck, customer-facing experts can become builders, and faster teams still need shared direction and lightweight governance.Key takeaways:• Start with the implementation bottlenecks customers already feel.• Digital twins create an early working model from existing business inputs.• When everyone can build, the product–services boundary starts to blur.• Faster engineering can move the bottleneck into customer testing, training, or change readiness.• Tiny teams still need shared context, priorities, and traceability.• Human effort alone is a poor test for whether an AI-generated change needs governance.Chapters:00:00 Why AI matters in professional services01:49 Where enterprise implementation time goes03:27 Start with customer-visible bottlenecks04:32 Milo, digital twins, and the first working tenant07:02 Mapping the customer onboarding value stream08:38 Product, engineering, and services working together11:38 When everyone can build13:25 Engineering stops being the only constraint16:38 Prioritizing the services AI backlog17:06 When delivery outpaces customer capacity18:00 Following the moving constraint20:14 Using AI to build AI solutions22:19 Ownership across product and services23:34 Speed without abandoning governance24:08 What project management survives AI acceleration27:02 Tiny teams and coordination costs29:17 Start with one or two visible winsAbout Julie:Julie Hodge is an AI Strategy & Operations Leader at Zuora. Her work focuses on how AI operates inside the enterprise and how professional-services teams turn AI capabilities into faster, more dependable customer outcomes.Julie on LinkedIn: https://www.linkedin.com/in/jdhodgeLearn about Zuora Milo: https://www.zuora.com/products/milo/Scaling AI: From Activity to Impact — yuvalyeret.comInsights (and help/advice) on scaling AI from activity to impact — yuvalyeret.com/insightsYuval's Linkedin – https://www.linkedin.com/in/yuvalyeret/

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.htmlScaling 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/insightsYuval'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 conversation00:31 Shay Mandel, Ergo-Next Insurance, and 200 people building product03:46 What you should get out of this conversation05:14 Breaking the development lifecycle into skills06:37 The engineering review skill that runs before engineering reviews08:38 How the engineers actually feel about it10:40 Developers of the system, not of the code11:11 Auto-improvement loops: pointing an agent at a KPI14:21 Where humans still decide, and where they don't21:21 Digital twins of your best insurance experts22:20 Ask-engineering and ask-product agents across time zones24:21 What changed in how the work is managed, and what didn't29:24 Epic-level Kanban and flow metrics for human and agent handoffs30:39 Advice for leaders starting the journey31:32 Setting expectations: 60% to 95%, and why the last 5% needs a human33:29 When you tell a PM to open a terminal, you lose them35:24 Avoiding skill sprawl: one shared brain, not 20037: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 YeretLinks and resourcesShay on LinkedIn: https://www.linkedin.com/in/shaymandel/Product Leaders AI meetup: https://luma.com/ProductLeaders.aiYuval's Linkedin – https://www.linkedin.com/in/yuvalyeret/Scaling AI: From Activity to Impact — yuvalyeret.com/insightsDon't Redesign Your Process Yet. Change Who Writes the Artifacts. – https://yuvalyeret.com/blog/change-who-writes-the-artifacts-before-your-processHow Next Insurance Broke Its Whole Lifecycle Into Agent Skills – https://yuvalyeret.com/blog/how-next-insurance-broke-its-lifecycle-into-agent-skills