Scrum Master Toolbox Podcast: Agile storytelling from the trenches

Lai-Ling Su: Why the Us-Versus-Them Mentality Is the Fastest Path to Team Self-Destruction Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The quickest way to self-destruction is to have an us-versus-them mentality. Because it permeates into every behavior, every action or inaction, and it impacts every single outcome as a result of it." - Lai-Ling Su Lai-Ling shares a compelling story about a leadership team in healthcare technology that was self-sabotaging their way into non-delivery—so much so that critical commercial outcomes were at serious risk. Yet the team themselves couldn't see it; it was invisible to them. She identifies three layers of the us-versus-them dynamic that needed unpicking. First, recent M&A activity had merged a larger corporate entity with a smaller, more nimble one, and people remained ferociously loyal to leaders from their old organizations. Second, business goals were separate from technology goals, causing people to fall back to people-pleasing within their direct reporting lines rather than collaborating on shared purpose. Third, the tension between growth ambitions and addressing legacy activities created another divide. What struck Lai-Ling most was how these "classic" patterns were invisible to those experiencing them—they just accepted it as part of doing business. The destruction wasn't always stormy and visible; sometimes it was silent, with work piling up, nothing getting done, yet no one overtly upset. In this segment, we talk about the importance of creating awareness and how Scrum Masters must be willing to point out these patterns, even at the risk of being seen as the odd ones out. Self-reflection Question: What "classic" anti-patterns might be invisible in your organization right now because everyone has accepted them as just part of doing business? Featured Book of the Week: The Checklist Manifesto by Atul Gawande Lai-Ling approaches the book recommendation differently—she believes no single book has fundamentally influenced her, but books as a collective have made her who she is. She emphasizes reading far and wide across all topics and genres, looking for patterns in unexpected places. One standout is The Checklist Manifesto by Atul Gawande, which challenges the perception that checklists take away autonomy. Gawande writes about how checklists are a rapid-fire communication tool that can mean the difference between a seriously injured soldier dying on the battlefield or making it to a hospital with a good chance of survival. Lai-Ling also recommends When Breath Becomes Air by Paul Kalanithi, about a surgeon who became a cancer patient and had to navigate a massive identity shift—much like the identity shift we ask leaders to make during transformations. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Lai-Ling Su Lai-Ling fixes the gap between operating model design and real-world delivery through her interim executive, consulting, capability building, and executive coaching work. She also equips product and transformation leaders with the capability everyone expects but no one teaches - how to navigate the people, politics, and performance expectations that come with their jobs. You can link with Lai-Ling Su on LinkedIn.

Lai-Ling Su: The Product and Service Story That Every Scrum Master Needs to Hear Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "It was kind of at that moment that I realized, like, community was about providing people with the opportunities that they otherwise wouldn't have had. And whilst you could technically execute your product or service well, the customer experience is fundamentally a deeply emotional one." - Lai-Ling Su Lai-Ling shares a powerful story from when she was just 11 years old, running front of house at her family's restaurant inside an Australian workers' club. When a popular band was booked to play on a Saturday night, the venue reached max capacity—and almost everyone wanted food. With no ticketed order system and only her memory to match orders to customers, chaos ensued. One father approached her, yelling about how long his food was taking. At the end of the night, Lai-Ling mustered the courage that only an 11-year-old possesses and asked him point-blank why he had reacted so strongly. His answer floored her: he only got to see his son every other weekend, and this evening was supposed to create a cherished memory together. Instead, they were hangry most of the night. This moment taught Lai-Ling that customer experience is fundamentally emotional—it's not about the food, but about what the interaction means to the people we serve. For the next decade, she continuously inspected every aspect of their restaurant operations, always seeking to improve how they served customers while remaining commercially viable. In this episode, we refer to the "Scrum Masters are the future CEO's, and a podcast by the Lean Enterprise Institute" blog post by Vasco. Self-reflection Question: When was the last time you paused to understand the deeper meaning behind a stakeholder's frustration, rather than just addressing the surface-level complaint? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Lai-Ling Su Lai-Ling fixes the gap between operating model design and real-world delivery through her interim executive, consulting, capability building, and executive coaching work. She also equips product and transformation leaders with the capability everyone expects but no one teaches - how to navigate the people, politics, and performance expectations that come with their jobs. You can link with Lai-Ling Su on LinkedIn.

BONUS: From Combat Pilot to Scrum Master - How Military Leadership Transforms Agile Teams In this bonus episode, we explore a fascinating career transition with Nate Amidon, a former Air Force combat pilot who now helps software teams embed military-grade leadership principles into their Agile practices. Nate shares how the high-stakes discipline of aviation translates directly into building high-performing development teams, and why veterans make exceptional Scrum Masters. The Brief-Execute-Debrief Cycle: Aviation Meets Agile "We would mission brief in the morning and make sure everyone was on the same page. Then we problem-solved our way through the day, debriefed after, and did it again. When I learned about what Agile was, I realized it's the exact same thing." Nate's transition from flying C-17 cargo planes to working with Agile teams wasn't as jarring as you might expect. Flying missions that lasted 2-3 weeks with a crew of 5-7 people taught him the fundamentals of iterative work: daily alignment, continuous problem-solving, and regular reflection. The brief-execute-debrief cycle that every military pilot learns mirrors the sprint cadence that Agile teams follow. Time-boxing wasn't new to him either—when you're flying, you only have so much fuel, so deadlines aren't arbitrary constraints but physical realities that demand disciplined execution. In this episode with Christian Boucousis, we also discuss the brief-execute-debrief cycle in detail. In this segment, we also refer to Cynefin, and the classification of complexity. Alignment: The Real Purpose Behind Ceremonies "It's really important to make sure everyone understands why you're doing what you're doing. We don't brief, execute, debrief just because—we do it because we know that getting everybody on the same page is really important." One of the most valuable insights Nate brings to his work with software teams is the understanding that Agile ceremonies aren't bureaucratic checkboxes—they're alignment mechanisms. The purpose of sprint planning, daily stand-ups, and retrospectives is to ensure everyone knows the mission and can adapt when circumstances change. Interestingly, Nate notes that as teams become more high-performing, briefings get shorter and more succinct. The discipline remains, but the overhead decreases as shared context grows. The Art of Knowing When to Interrupt "There are times when you absolutely should not interrupt an engineer. Every shoulder tap is a 15-minute reset for them to get back into the game. But there are also times when you absolutely should shoulder tap them." High-performing teams understand the delicate balance between deep work and necessary communication. Nate shares an aviation analogy: when loadmasters are loading complex cargo like tanks and helicopters, interrupting them with irrelevant updates would be counterproductive. But if you discover that cargo shouldn't be on the plane, that's absolutely worth the interruption. This judgment—knowing what matters enough to break flow—is something veterans develop through high-stakes experience. Building this awareness across a software team requires: Understanding what everyone is working on Knowing the bigger picture of the mission Creating psychological safety so people feel comfortable speaking up Developing shared context through daily stand-ups and retrospectives Why Veterans Make Exceptional Scrum Masters "I don't understand why every junior officer getting out of the military doesn't just get automatically hired as a Scrum Master. If you were to say what we want a Scrum Master to do, and what a junior military officer does—it's line for line." Nate's company, Form100 Consulting, specifically hires former military officers and senior NCOs for Agile roles, often bringing them on without tech experience. The results consistently exceed expectations because veterans bring foundational leadership skills that are difficult to develop elsewhere: showing up on time, doing what you say you'll do, taking care of team members, seeing the forest through the trees. These intangible qualities—combined with the ability to stay calm, listen actively, and maintain integrity under pressure—make for exceptional servant leaders in the software development space. The Onboarding Framework for Veterans "When somebody joins, we have assigned everybody a wingman—a dedicated person that they check in with regularly to bounce ideas off, to ask questions." Form100's approach to transitioning veterans into tech demonstrates the same principles they advocate for Agile teams. They screen carefully for the right personality fit, provide dedicated internal training on Agile methodologies and program management, and pair every new hire with a wingman. This military unit culture helps bridge the gap between active duty service and the private sector, addressing one of the biggest challenges: the expectation gap around leadership standards that exists between military and civilian organizations. Extreme Ownership: Beyond Process Management "To be a good Scrum Master, you have to take ownership of the team's execution. If the product requirements aren't good, it's a Scrum Master's job to help. If QA is the problem, take ownership. You should be the vessel and ownership of the entire process of value delivery." One of Nate's core philosophies comes from Jocko Willink's Extreme Ownership. Too many Scrum Masters limit themselves to being "process people" who set meetings and run ceremonies. True servant leadership means owning everything that affects the team's ability to deliver value—even things technically outside your job description. When retrospectives devolve into listing external factors beyond the team's control, the extreme ownership mindset reframes the conversation: "Did we give the stakeholder the right information? Did they make a great decision based on bad information we provided?" This shift from blame to ownership drives genuine continuous improvement. Building Feedback Loops in Complex Environments "In the military, we talk about the OODA loop. Everything gets tighter, we get better—that's why we do the debrief." Understanding whether you're operating in a complicated or complex domain (referencing the Cynefin framework) determines how tight your feedback loops need to be. In complex environments—where most software development lives—feedback loops aren't just for reacting to what happened; they're for probing and understanding what's changing. Sprint goals become essential because without knowing where you're headed, you can't detect when circumstances have shifted. The product owner role becomes critical as the voice connecting business priorities to team execution, ensuring the mission stays current even when priorities change mid-sprint. Recommended Resources Nate recommends the following books: Team of Teams by General McChrystal Extreme Ownership by Jocko Willink About Nate Amidon Nate is a former Air Force combat pilot and founder of Form100 Consulting. He helps software teams embed leadership at the ground level, translating military principles into Agile practices. With a focus on alignment, accountability, and execution, Nate empowers organizations to lead from within and deliver real results in a dynamic tech landscape. You can link with Nate Amidon on LinkedIn and learn more at Form100 Consulting.

BONUS: From Individual AI Wins to Team-Wide Transformation What happens when the leaders we trust to guide transformation become the bottleneck slowing it down? In this episode, Monica Marquez—with 25+ years in people transformation at Goldman Sachs, Google, and beyond—reveals why the old equation of effort equals success is breaking down, and what leaders must unlearn to thrive in the age of AI. The Leadership Crisis Nobody Trained You For "No one ever really teaches you what it really takes to be a leader. You know what you do really well, but how do you help other people do that too? That's when I realized it comes down to becoming a really good leader." Monica's origin story captures a universal struggle: being promoted for technical excellence, then discovering that leading people requires completely different skills. She spent her career at organizations like Goldman Sachs, Bank of America, Ernst & Young, and Google realizing that systems weren't built for everyone—and that the real work of leadership is redesigning those systems to unlock human potential. Today, through her company Flipwork, she helps leaders and teams become what she calls "agentic humans"—people who leverage AI to get ahead rather than getting left behind. The Command and Control Trap "Most leadership development still rewards the command and control archetype. The person who has all the answers, the decisive hero. But AI moves so fast that when you think you've fixed something, it changes the next day. Leaders are starting to become bottlenecks." The research shows the problem clearly: middle management is where AI adoption stalls. These leaders cling to command and control because relinquishing it feels like losing their value. Worse, they have an unspoken fear of managing AI agents—they don't want to be liable for outputs they don't fully control. Monica reframes this: treat your AI tools like an artificial intern, not artificial intelligence. You wouldn't take an intern's first draft and hand it to leadership. You train them, provide context, and finesse the output. The same discipline applies to LLMs. Rewriting the Success Equation "Effort = success is the old equation. That's pre-AI. The new equation is impact equals success. Output equals success, and impact equals worth." This might be the most important shift leaders need to make. When tasks that took 4 hours now take 30 minutes, deeply conditioned beliefs about work ethic get threatened. Monica sees leaders questioning their worth because they're producing faster. "I was always taught I have to work twice as hard to get half as far," she shares. "Now what used to take me 10 hours, I can get done in 4. Am I not worthy anymore of being a high performer?" The answer is to measure impact, not effort—and that requires rewiring beliefs that may be decades old. Why Individual AI Adoption Doesn't Scale "Teams are using AI as individual contributors, but they aren't using AI in their actual workflows and the handoffs. That's why leaders are scratching their heads, like, why aren't we seeing the ROI bubble up into the team?" Here's the gap most organizations miss: individuals save an hour or two per day using AI for personal productivity, but the team never sees compounding benefits. The handoffs between team members remain manual. The friction points persist. Monica's solution is "flip labs"—90-day sprints where teams take one critical workflow, dissect it, and rebuild it with AI. Where can AI handle the $10 tasks so humans can focus on $10,000 decisions? Where should humans remain in the loop? IKEA did this with customer service, retraining displaced workers into design roles. Revenue increased without adding headcount. Leading Through Uncertainty "We're humans wired for certainty, but Agile is a system designed for uncertainty. That's where the behavioral psychology comes in—how do you help people move forward despite the uncertainty?" The fundamental challenge is biological: our brains seek certainty, but the only certain thing now is that change will come faster than we can adapt. Monica works with teams to create psychologically safe spaces for experimentation—AB testing old workflows against AI-augmented ones, measuring outputs, and learning from failures. "Sometimes we learn more from the failures than we do the successes," she notes. The leaders who create permission for testing and learning will pull ahead; those who demand control will become the bottleneck that slows their entire organization. About Monica Marquez Monica Marquez is a leadership and workplace AI advisor with 25+ years in people transformation. She coined the "returnship" at Goldman Sachs, helped found Google's Product Inclusion Council, and now guides leaders and teams to adopt AI, agile, and inclusion practices that drive results through her company Flipwork, Inc. You can connect with Monica Marquez on LinkedIn and subscribe to her Ay, Ay, Ay! AI newsletter at themonicamarquez.com.

BONUS: The Future of Seeing—Why AI Vision Will Transform Medicine and Human Perception What if the next leap in AI isn't about thinking, but about seeing? In this episode, Daniel Sodickson—physicist, medical imaging pioneer, and author of "The Future of Seeing"—argues we're on the edge of a vision revolution that will change medicine, technology, and even human perception itself. From Napkin Sketch to Parallel Imaging "I was doodling literally on a napkin in a piano bar in Boston and came up with a way to get multiple lines at once. I ran to my mentor and said, 'Hey, I have this idea, never mind my paper.' And he said, 'Who are you again? Sure, why not.' And it worked." Daniel's journey into imaging began with a happy accident. While studying why MRI couldn't capture the beating heart fast enough, he realized the fundamental bottleneck: MRI machines scan one line at a time, like old CRT screens. His insight—imaging in parallel to capture multiple lines simultaneously—revolutionized the field. This connection between natural vision (our eyes capture entire scenes at once) and artificial imaging systems set him on a 29-year journey exploring how we can see what was once invisible. Upstream AI: Changing What We Measure "Most often when we envision AI, we think of it as this downstream process. We generate our data, make our image, then let AI loose instead of our brains. To me, that's limited. Why aren't we thinking of tasks that AI can do that no human could ever do?" Daniel introduces a crucial distinction between "downstream" and "upstream" AI. Downstream AI takes existing images and interprets them—essentially competing with human experts. Upstream AI changes the game entirely by redesigning what data we gather in the first place. If we know a machine learning system will process the output, we can build cheaper, more accessible sensors. Imagine monitoring devices built into beds or chairs that don't produce perfect images but can detect whether you've changed since your last comprehensive scan. AI fills in the gaps using learned context about how bodies and signals behave. The Power of Context and Memory "The world we see is a lie. Two eyes are not nearly enough to figure out exactly where everything is in space. What the brain is doing is using everything it's learned about the world—how light falls on surfaces, how big people are compared to objects—and filling in what's missing." Our brains don't passively receive images; they actively construct reality using massive amounts of learned context. Daniel argues we can give imaging machines the same superpower. By training AI on temporal patterns—how healthy bodies change over time, what signals precede disease—we create systems with "memory" that can make sophisticated judgments from incomplete data. Today's signal, combined with your history and learned patterns from millions of others, becomes far more informative than any single pristine image could be. From Reactive to Proactive Health "I've started to wonder why we use these amazing MRI machines only once we already know you're sick. Why do we use them reactively rather than proactively?" This question drove Daniel to leave academia after 29 years and join Function Health, a company focused on proactive imaging and testing to catch disease before it develops. The vision: a GPS for your health. By combining regular blood panels, MRI scans, and wearable data, AI can monitor whether you look like yourself or have changed in worrisome ways. The goal isn't replacing expert diagnosis but creating an early warning system that surfaces problems while they're still easily treatable. Seeing How We See "Sometimes when I'm walking along, everything I'm seeing just fades away. And what I see instead is how I'm seeing. I imagine light bouncing off of things and landing in my eye, this buzz of light zipping around as fast as anything in the universe can go." After decades studying vision, Daniel experiences the world differently. He finds himself deconstructing his own perception—tracing sight lines, marveling at how we've evolved to turn chaos of sensation into spatially organized information. This meta-awareness extends to his work: every new imaging modality has driven scientific discovery, from telescopes enabling the Copernican Revolution to MRI revealing the living body. We're now at another inflection point where AI doesn't just interpret images but transforms our relationship with perception itself. In this episode, we refer to An Immense World: How Animal Senses Reveal the Hidden Realms Around Us by Ed Young on animal perception, and A Path Towards Autonomous Machine Intelligence by Yann LeCun on building AI more like the brain. About Daniel Sodickson Daniel K. Sodickson is a physicist in medicine and chief medical scientist at Function Health. Previously at NYU, and a gold medalist and past president of the International Society for Magnetic Resonance in Medicine, he pioneers AI-driven imaging and is author of The Future of Seeing.

AI Assisted Coding: How Spending 4x More on Code Quality Doubled Development Speed What happens when you combine nearly 30 years of engineering experience with AI-assisted coding? In this episode, Eduardo Ferro shares his experiments showing that AI doesn't replace good practices—it amplifies them. The result: doubled productivity while spending four times more on code quality. Vibe Coding vs Production-Grade AI Development "Vibe coding is flow-driven, curiosity-based way of building software with AI. It's less about meticulously reviewing each line of code, and more about letting the AI steer the process—perfect for quick experiments, side projects, MVPs, and prototypes." Edu draws a clear distinction between vibe coding and production AI development. Vibe coding is exploration-focused, where you let AI drive while you learn and discover. Production AI coding is goal-focused, with careful planning, spec definition, and identification of edge cases before implementation. Both use small, safe steps and continuous conversation with the AI, but production code demands architectural thinking, security analysis, and sustainability practices. The key insight is that even vibe coding benefits from engineering discipline—as experiments grow, you need sustainable practices to maintain flexibility. How AI Doubled My Productivity "I was investing four times more in refactoring, cleanup, deleting code, introducing new tests, improving testability, and security analysis than in generating new features. And at the same time, globally, I think I more or less doubled my pace of work." Edu's two-month experiment with production code revealed a counterintuitive finding: by spending 4x more time on code quality activities—refactoring, cleanup, test improvement, and security analysis—he actually doubled his overall delivery speed. The secret lies in fast feedback loops. With AI, you can implement a feature, run automated code review, analyze security, prioritize improvements, and iterate—all within an hour. What used to be a day's work happens in a single focused session, and the quality improvements compound over time. The Positive Spiral of Code Removal "We removed code, so we removed all the features that were not being used. And whenever I remove this code, the next step is to automatically try to see, okay, can I simplify the architecture." One of the most powerful practices Edu discovered is using AI to accelerate code removal. By connecting product analytics to identify unused features, then using AI to quickly remove them, you trigger a positive spiral: removing code makes architecture changes easier, easier architecture changes enable faster feature development, which leads to more opportunities for simplification. This creates a self-reinforcing cycle that humans historically have been reluctant to pursue because removal was as expensive as creation. Preparing the System Before Introducing Change "What I want to generate is this new functionality—how should I change my system to make it super easy to introduce this one? It's not about making the change, it's about making the change easy." Edu describes a practice that was previously too expensive: preparing the system before introducing changes. By analyzing architecture decision records, understanding the existing design, and adapting the codebase first, new features become trivial to implement. AI makes this preparation cheap enough to do routinely. The result is systems that evolve cleanly rather than accumulating technical debt with each new feature. AI as an Amplifier: The Double-Edged Sword "AI is an amplifier. People who already know how to develop software well will continue to develop it well and faster. People who did not know how to develop software well will probably get in trouble much faster than they would otherwise." Edu's central metaphor is AI as an amplifier—it doesn't replace engineering judgment, it magnifies its presence or absence. Teams with strong practices will see accelerated improvement; teams without them will generate technical debt faster than ever. This has implications beyond individual productivity: the market will be saturated with solutions, making product discovery and distribution channels more important than implementation capability. In this episode, we refer to Edu's blog post Fast Feedback, Fast Features: My AI Assisted Coding Experiment and Vibe Coding by Gene Kim. About Eduardo Ferro Edu Ferro is Head of Engineering and Data Platform at ClarityAI, with nearly 30 years' experience. He helps teams deliver value through Lean, XP, and DevOps, blending technical depth with product thinking. Recently he explores AI-assisted product development, sharing insights and experiments on his site eferro.net. You can connect with Edu Ferro on LinkedIn.

Adam Bilišič, former CTO and current CEO of Nodion Labs focused on AI-powered developer tooling. He contrasts vibe coding with true AI-augmented coding. He explains shifting from building single features to designing reusable systems, recipes, and agent teams. He walks through context management, prompt templates, and five progressive levels for mastering AI-augmented development.

BONUS: When AI Decisions Go Wrong at Scale—And How to Prevent It We've spent years asking what AI can do. But the next frontier isn't more capability—it's something far less glamorous and far more dangerous if we get it wrong. In this episode, Ran Aroussi shares why observability, transparency, and governance may be the difference between AI that empowers humans and AI that quietly drifts out of alignment. The Gap Between Demos and Deployable Systems "I've noticed that I watched well-designed agents make perfectly reasonable decisions based on their training, but in a context where the decision was catastrophically wrong. And there was really no way of knowing what had happened until the damage was already there." Ran's journey from building algorithmic trading systems to creating MUXI, an open framework for production-ready AI agents, revealed a fundamental truth: the skills needed to build impressive AI demos are completely different from those needed to deploy reliable systems at scale. Coming from the EdTech space where he handled billions of ad impressions daily and over a million concurrent users, Ran brings a perspective shaped by real-world production demands. The moment of realization came when he saw that the non-deterministic nature of AI meant that traditional software engineering approaches simply don't apply. While traditional bugs are reproducible, AI systems can produce different results from identical inputs—and that changes everything about how we need to approach deployment. Why Leaders Misunderstand Production AI "When you chat with ChatGPT, you go there and it pretty much works all the time for you. But when you deploy a system in production, you have users with unimaginable different use cases, different problems, and different ways of phrasing themselves." The biggest misconception leaders have is assuming that because AI works well in their personal testing, it will work equally well at scale. When you test AI with your own biases and limited imagination for scenarios, you're essentially seeing a curated experience. Real users bring infinite variation: non-native English speakers constructing sentences differently, unexpected use cases, and edge cases no one anticipated. The input space for AI systems is practically infinite because it's language-based, making comprehensive testing impossible. Multi-Layered Protection for Production AI "You have to put in deterministic filters between the AI and what you get back to the user." Ran outlines a comprehensive approach to protecting AI systems in production: Model version locking: Just as you wouldn't randomly upgrade Python versions without testing, lock your AI model versions to ensure consistent behavior Guardrails in prompts: Set clear boundaries about what the AI should never do or share Deterministic filters: Language firewalls that catch personal information, harmful content, or unexpected outputs before they reach users Comprehensive logging: Detailed traces of every decision, tool call, and data flow for debugging and pattern detection The key insight is that these layers must work together—no single approach provides sufficient protection for production systems. Observability in Agentic Workflows "With agentic AI, you have decision-making, task decomposition, tools that it decided to call, and what data to pass to them. So there's a lot of things that you should at least be able to trace back." Observability for agentic systems is fundamentally different from traditional LLM observability. When a user asks "What do I have to do today?", the system must determine who is asking, which tools are relevant to their role, what their preferences are, and how to format the response. Each user triggers a completely different dynamic workflow. Ran emphasizes the need for multi-layered access to observability data: engineers need full debugging access with appropriate security clearances, while managers need topic-level views without personal information. The goal is building a knowledge graph of interactions that allows pattern detection and continuous improvement. Governance as Human-AI Partnership "Governance isn't about control—it's about keeping people in the loop so AI amplifies, not replaces, human judgment." The most powerful reframing in this conversation is viewing governance not as red tape but as a partnership model. Some actions—like answering support tickets—can be fully automated with occasional human review. Others—like approving million-dollar financial transfers—require human confirmation before execution. The key is designing systems where AI can do the preparation work while humans retain decision authority at critical checkpoints. This mirrors how we build trust with human colleagues: through repeated successful interactions over time, gradually expanding autonomy as confidence grows. Building Trust Through Incremental Autonomy "Working with AI is like working with a new colleague that will back you up during your vacation. You probably don't know this person for a month. You probably know them for years. The first time you went on vacation, they had 10 calls with you, and then slowly it got to 'I'm only gonna call you if it's really urgent.'" The path to trusting AI systems mirrors how we build trust with human colleagues. You don't immediately hand over complete control—you start with frequent check-ins, observe performance, and gradually expand autonomy as confidence builds. This means starting with heavy human-in-the-loop interaction and systematically reducing oversight as the system proves reliable. The goal is reaching a state where you can confidently say "you don't have to ask permission before you do X, but I still want to approve every Y." In this episode, we refer to Thinking in Systems by Donella Meadows, Designing Machine Learning Systems by Chip Huyen, and Build a Large Language Model (From Scratch) by Sebastian Raschka. About Ran Aroussi Ran Aroussi is the founder of MUXI, an open framework for production-ready AI agents. He is also the co-creator of yfinance (with 10 million downloads monthly) and founder of Tradologics and Automaze. Ran is the author of the forthcoming book Production-Grade Agentic AI: From Brittle Workflows to Deployable Autonomous Systems, also available at productionaibook.com. You can connect with Ran Aroussi on LinkedIn.

BONUS: Why Embedding Sales with Engineering in Stealth Mode Changed Everything for Snowflake In this episode, we talk about what it really takes to scale go-to-market from zero to billions. We interview Chris Degnan, a builder of one of the most iconic revenue engines in enterprise software at Snowflake. This conversation is grounded in the transformation described in his book Make It Snow—the journey from early-stage chaos to durable, aligned growth. Embedding Sales with Engineering While Still in Stealth "I don't expect you to sell anything for 2 years. What I really want you to do is get a ton of feedback and get customers to use the product so that when we come out of stealth mode, we have this world-class product." Chris joined Snowflake when there were zero customers and the company was still in stealth mode. The counterintuitive move of embedding sales next to engineering so early wasn't about driving immediate revenue, it was about understanding product-market fit. Chris's job was to get customers to try the product, use it for free, and break it. And break it they did. This early feedback led to material changes in the product before general availability. The approach helped shape their ideal customer profile (ICP) and gave the engineering team real-world validation that shaped Snowflake's technical direction. In a world where startups are pressured to show revenue immediately, Snowflake's investors took the opposite approach: focus on building a product people cannot live without first. Why Sales and Marketing Alignment Is Existential "If we're not driving revenue, if the revenue is not growing, then how are we going to be successful? Revenue was king." When Denise Persson joined as CMO, she shifted the conversation from marketing qualified leads (MQLs) to qualified meetings for the sales team. This simple reframe eliminated the typical friction between sales and marketing. Both leaders shared challenges openly and held each other accountable. When someone in either organization wasn't being respectful to the other team, they addressed it directly. Chris warns founders against creating artificial friction between sales and marketing: "A lot of founders who are engineers think that they want to create this friction between sales and marketing. And that's the opposite instinct you should have." The key insight is treating sales and marketing as a symbiotic system where revenue is the shared north star. Coaching Leaders Through Hypergrowth "If there's a problem in one of our organizations, if someone comes with a mentality that is not great for us, we're gonna give direct feedback to those people." Chris and Denise maintained tight alignment at the top level of their organizations through four CEO transitions. Their partnership created a culture of accountability that cascaded through both teams. When either hired senior people who didn't fit the culture, they investigated and addressed it. The coaching approach wasn't about winning by authority—it was about maintaining partnership and shared accountability for results. This required unlearning traditional management approaches that pit departments against each other and instead fostering genuine collaboration. Cultural Behaviors That Scale (And Those That Don't) "We got dumb and lazy. We forgot about it. And then we decided, hey, we're gonna go get a little bit more fit, and figure out how to go get the new logos again." Chris describes himself as a "velocity salesperson" with a hyper-focus on new customer acquisition. This focus worked brilliantly during Snowflake's growth phase—land customers, and the high net retention rate would drive expansion. However, as Snowflake prepared to go public, they took their foot off the gas on new logo acquisition, believing not all new logos were equal. This turned out to be a mistake. In his final year at Snowflake, working with CEO Sridhar Ramaswamy, they redesigned the sales team to reinvigorate the new logo acquisition machine. The lesson: the cultural behaviors that fuel early success must be consciously maintained and sometimes redesigned as you scale. Keeping the Message Narrow Before Going Platform "Eventually, I know you want to be a platform. But having a targeted market when you're initially launching the company, that people are spending money on, makes it easier for your sales team." Snowflake intentionally positioned itself in the enterprise data warehousing market—a $10-12 billion annual market with 5,000-7,000 enterprise customers—rather than trying to sound "bigger" as a platform play. The strategic advantage was accessing existing budgets. When selling to large enterprises that go through annual planning processes, fitting into an existing budget means sales cycles of 3-6 months instead of 9-18 months. Yes, competition eventually tried to corner Snowflake as "just a cute data warehouse," but by then they had captured significant market share and could stretch their wings into the broader data cloud opportunity. Selling Consumption-Based Products to Fixed-Budget Buyers "Don't believe anything I say, try it." One of Snowflake's hardest challenges was explaining their elastic, consumption-based architecture to procurement and legal teams accustomed to fixed budgets. In 2013-2015, many CIOs still believed data would stay in their data centers. Snowflake's model—where customers could spin up a thousand servers for 4 hours, load data, while analysts ran queries without performance impact—seemed impossible. Chris's approach was simple: set up proof of concepts and pilots. Let the technology speak for itself. The shift from fixed resources to elastic architecture required changing not just technology but entire mindsets about how data infrastructure could work. About Chris Degnan Chris Degnan is a builder of one of the most iconic revenue engines in enterprise software. As the first sales hire at Snowflake, he helped scale the company from zero customers to billions in revenue. Chris co-authored Make It Snow: From Zero to Billions with Denise Persson, documenting their journey of building Snowflake's go-to-market organization. Today, Chris advises early-stage startups on building their go-to-market strategies and works with Iconiq Capital, the venture firm that led Snowflake's Series D round. You can link with Chris Degnan on LinkedIn and learn more about the book at MakeItSnowBook.com.

Prabhleen Kaur: The Art of Coaching Product Owners on What vs. How Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Master of Stakeholder Relationships and the Power of No "The best PO is the person who has the superpower of saying no, and they can deal with the stakeholders with the same prowess." - Prabhleen Kaur Prabhleen describes working with a Product Owner who managed multiple stakeholders—not just a handful, but a significant number with competing priorities. What made him exceptional was his deep understanding of each stakeholder's pulse and motivations. He knew when to push back and how to frame the "no" in a way that stakeholders could accept. This wasn't random resistance—it came from thorough preparation manifested in clear roadmaps that made most incoming work predictable for the team. His user stories stood out for their richness in context: beyond the business requirements, they included information about who would be impacted, which proved invaluable for a team dealing with multiple interconnected systems. He leveraged JIRA's priority field effectively, ensuring the moment anyone opened the board, they could immediately understand what mattered most. Prabhleen emphasizes that this PO understood his role as the "what" while respecting the team as the "how." By maintaining strong stakeholder relationships built on mutual understanding, he created space for the team to prepare, plan, and deliver without constant firefighting. Self-reflection Question: Does your Product Owner have the preparation and stakeholder relationships needed to confidently say "no" when priorities compete, or does every request become an emergency? The Bad Product Owner: Technical Experts Who Manage the Sprint Backlog "The PO is the what, and the team is the how. When POs start directing the team about how to do things, the sprint goal gets compromised." - Prabhleen Kaur Prabhleen addresses a common anti-pattern she's observed repeatedly: Product Owners with technical backgrounds who cross the line from "what" into "how." When POs come from developer or technical roles, their expertise can become a liability if they start prescribing solutions rather than defining problems. They direct the team on implementation approaches, suggest specific technical solutions in user stories, and effectively manage the sprint backlog instead of focusing on the product backlog. The consequences are predictable: stories keep getting added or removed mid-sprint, the sprint goal becomes meaningless, and the team ends up delivering nothing because focus is constantly shifting. Prabhleen's solution starts in backlog refinement, where she ensures conversations about technical approaches happen openly with the whole team during estimation. When a PO suggests a specific implementation, she facilitates discussion about alternatives, allowing the team to voice their perspective. The key insight: everyone comes from a good place—the PO suggests solutions because they believe they're helping. The Scrum Master's role is to create space for the team to own the "how" while helping the PO see the value in stepping back. Self-reflection Question: When your Product Owner has technical expertise, how do you help them contribute their knowledge without directing the team's implementation choices? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Prabhleen Kaur Prabhleen is a Certified Scrum Master with 7+ years of experience helping teams succeed with SAFe, Scrum and Kanban. Passionate about clean backlogs, powerful metrics, and dashboards that actually mean something. She is also known for making JIRA behave, driving Agile transformations, and helping teams ship value consistently and confidently. You can link with Prabhleen Kaur on LinkedIn.