Swimming in Tech Debt — Practical Techniques to Keep Your Team from Drowning in Its Codebase | Lou Franco

Swimming in Tech Debt — Practical Techniques to Keep Your Team from Drowning in Its Codebase | Lou Franco

BONUS: Swimming in Tech Debt — Practical Techniques to Keep Your Team from Drowning in Its Codebase

In this fascinating conversation, veteran software engineer and author Lou Franco shares hard-won lessons from decades at startups, Trello, and Atlassian. We explore his book "Swimming in Tech Debt," diving deep into the 8 Questions framework for evaluating tech debt decisions, personal practices that compound over time, team-level strategies for systematic improvement, and leadership approaches that balance velocity with sustainability. Lou reveals why tech debt is often the result of success, how to navigate the spectrum between ignoring debt and rewriting too much, and practical techniques individuals, teams, and leaders can use starting today.

The Exit Interview That Changed Everything

"We didn't go slower by paying tech debt. We went actually faster, because we were constantly in that code, and now we didn't have to run into problems." — Lou Franco

Lou's understanding of tech debt crystallized during an exit interview at Atalasoft, a small startup where he'd spent years. An engineer leaving the company confronted him: "You guys don't care about tech debt." Lou had been focused on shipping features, believing that paying tech debt would slow them down. But this engineer told a different story — when they finally fixed their terrible build and installation system, they actually sped up. They were constantly touching that code, and removing the friction made everything easier. This moment revealed a fundamental truth: tech debt isn't just about code quality or engineering pride. It's about velocity, momentum, and the ability to move fast sustainably. Lou carried this lesson through his career at Trello (where he learned the dangers of rewriting too much) and Atlassian (where he saw enterprise-scale tech debt management). These experiences became the foundation for "Swimming in Tech Debt."

Tech Debt Is the Result of Success

"Tech debt is often the result of success. Unsuccessful projects don't have tech debt." — Lou Franco

This reframes the entire conversation about tech debt. Failed products don't accumulate debt — they disappear before it matters. Tech debt emerges when your code survives long enough to outlive its original assumptions, when your user base grows beyond initial expectations, when your team scales faster than your architecture anticipated. At Atalasoft, they built for 10 users and got 100. At Trello, mobile usage exploded beyond their web-first assumptions. Success creates tech debt by changing the context in which code operates. This means tech debt conversations should happen at different intensities depending on where you are in the product lifecycle. Early startups pursuing product-market fit should minimize tech debt investments — move fast, learn, potentially throw away the code. Growth-stage companies need balanced approaches. Mature products benefit significantly from tech debt investments because operational efficiency compounds over years. Understanding this lifecycle perspective helps teams make appropriate decisions rather than applying one-size-fits-all rules.

The 8 Questions Framework for Tech Debt Decisions

"Those 8 questions guide you to what you should do. If it's risky, has regressions, and you don't even know if it's gonna work, this is when you're gonna do a project spike." — Lou Franco

Lou introduces a systematic framework for evaluating whether to pay tech debt, inspired by Bob Moesta's push-pull forces from product management. The 8 questions create a complete picture:

  1. Visibility — Will people outside the team understand what we're doing?

  2. Alignment — Does this match our engineering values and target architecture?

  3. Resistance — How hard is this code to work with right now?

  4. Volatility — How often do we touch this code?

  5. Regression Risk — What's the chance we'll introduce new problems?

  6. Project Size — How big is this to fix?

  7. Estimate Risk — How uncertain are we about the effort required?

  8. Outcome Uncertainty — How confident are we the fix will actually improve things?

High volatility and high resistance with low regression risk? Pay the debt now. High regression risk with no tests? Write tests first, then reassess. Uncertain outcomes on a big project? Do a spike or proof of concept. The framework prevents both extremes — ignoring costly debt and undertaking risky rewrites without proper preparation.

Personal Practices That Compound Daily

"When I sit down at my desk, the first thing I do is I pay a little tech debt. I'm looking at code, I'm about to change it, do I even understand it? Am I having some kind of resistance to it? Put in a little helpful comment, maybe a little refactoring." — Lou Franco

Lou shares personal habits that create compounding improvements over time. Start each coding session by paying a small amount of tech debt in the area you're about to work — add a clarifying comment, extract a confusing variable, improve a function name. This warms you up, reduces friction for your actual work, and leaves the code slightly better than you found it. The clean-as-you-go philosophy means tech debt never accumulates faster than you can manage it. But Lou's most powerful practice comes at the end of each session: mutation testing by hand. Before finishing for the day, deliberately break something — change a plus to minus, a less-than to less-than-or-equal. See if tests catch it. Often they don't, revealing gaps in test coverage. The key insight: don't fix it immediately. Leave that failing test as the bridge to tomorrow's coding session. It connects today's momentum to tomorrow's work, ensuring you always start with context and purpose rather than cold-starting each day.

Mutation Testing: Breaking Things on Purpose

"Before I'm done working on a coding session, I break something on purpose. I'll change a plus to a minus, a less than to a less than equals, and see if tests break. A lot of times tests don't break. Now you've found a problem in your test." — Lou Franco

Manual mutation testing — deliberately breaking code to verify tests catch the break — reveals a critical gap in most test suites. You can have 100% code coverage and still have untested behavior. A line of code that's executed during tests isn't necessarily tested — the test might not actually verify what that line does. By changing operators, flipping booleans, or altering constants, you discover whether your tests protect against actual logic errors or just exercise code paths. Lou recommends doing this manually as part of your daily practice, but automated tools exist for systematic discovery: Stryker (for JavaScript, C#, Scala) and MutMut (for Python) can mutate your entire codebase and report which mutations survive uncaught. This isn't just about test quality — it's about understanding what your code actually does and building confidence that changes won't introduce subtle bugs.

Team-Level Practices: Budgets, Backlogs, and Target Architecture

"Create a target architecture document — where would we be if we started over today? Every PR is an opportunity to move slightly toward that target." — Lou Franco

At the team level, Lou advocates for three interconnected practices. First, create a target architecture document that describes where you'd be if starting fresh today — not a detailed design, but architectural patterns, technology choices, and structural principles that represent current best practices. This isn't a rewrite plan; it's a North Star. Every pull request becomes an opportunity to move incrementally toward that target when touching relevant code. Second, establish a budget split between PM-led feature work and engineering-led tech debt work — perhaps 80/20 or whatever ratio fits your product lifecycle stage. This creates predictable capacity for tech debt without requiring constant negotiation. Third, hold quarterly tech debt backlog meetings separate from sprint planning. Treat this backlog like PMs treat product discovery — explore options, estimate impacts, prioritize based on the 8 Questions framework. Some items fit in sprints; others require dedicated engineers for a quarter or two. This systematic approach prevents tech debt from being perpetually deprioritized while avoiding the opposite extreme of engineers disappearing into six-month "improvement" projects with no visible progress.

The Atlassian Five-Alarm Fire

"The Atlassian CTO's 'five-alarm fire' — stopping all feature development to focus on reliability. I reduced sync errors by 75% during that initiative." — Lou Franco

Lou shares a powerful example of leadership-driven tech debt management at scale. The Atlassian CTO called a "five-alarm fire" — halting all feature development across the company to focus exclusively on reliability and tech debt. This wasn't panic; it was strategic recognition that accumulated debt threatened the business. Lou worked on reducing sync errors, achieving a 75% reduction during this focused period. The initiative demonstrated several leadership principles: willingness to make hard calls that stop revenue-generating feature work, clear communication of why reliability matters strategically, trust that teams will use the time wisely, and commitment to see it through despite pressure to resume features. This level of intervention is rare and shouldn't be frequent, but it shows what's possible when leadership truly prioritizes tech debt. More commonly, leaders should express product lifecycle constraints (startup urgency vs. mature product stability), give teams autonomy to find appropriate projects within those constraints, and require accountability through visible metrics and dashboards that show progress.

The Rewrite Trap: Why Big Rewrites Usually Fail

"A system that took 10 years to write has implicit knowledge that can't be replicated in 6 months. I'm mostly gonna advocate for piecemeal migrations along the way, reducing the size of the problem over time." — Lou Franco

Lou lived through Trello's iOS navigation rewrite — a classic example of throwing away working code to start fresh, only to discover all the edge cases, implicit behaviors, and user expectations baked into the "old" system. A codebase that evolved over several years contains implicit knowledge — user workflows, edge case handling, performance optimizations, and subtle behaviors that users rely on even if they never explicitly requested them. Attempting to rewrite this in six months inevitably misses critical details. Lou strongly advocates for piecemeal migrations instead. The Trello "Decaffeinate Project" exemplifies this approach — migrating from CoffeeScript to TypeScript incrementally, with public dashboards showing the percentage remaining, interoperable technologies allowing gradual transition, and the ability to pause or reverse if needed. Keep both systems running in parallel during migrations. Use runtime observability to verify new code behaves identically to old code. Reduce the problem size steadily over months rather than attempting big-bang replacements. The only exception: sometimes keeping parallel systems requires scaffolding that creates its own complexity, so evaluate whether piecemeal migration is actually simpler or if you're better off living with the current system.

Making Tech Debt Visible Through Dashboards

"Put up a dashboard, showing it happen. Make invisible internal improvements visible through metrics engineering leadership understands." — Lou Franco

One of tech debt's biggest challenges is invisibility — non-technical stakeholders can't see the improvement from refactoring or test coverage. Lou learned to make tech debt work visible through dashboards and metrics. The Decaffeinate Project tracked percentage of CoffeeScript files remaining, providing a clear progress indicator anyone could understand. When reducing sync errors, Lou created dashboards showing error rates declining over time. These visualizations serve multiple purposes: they demonstrate value to leadership, create accountability for engineering teams, build momentum as progress becomes visible, and help teams celebrate wins that would otherwise go unnoticed. The key is choosing metrics that matter to the business — error rates, page load times, deployment frequency, mean time to recovery — rather than pure code quality metrics like cyclomatic complexity that don't translate outside engineering. Connect tech debt work to customer experience, reliability, or developer productivity in ways leadership can see and value.

Onboarding as a Tech Debt Opportunity

"Unit testing is a really great way to learn a system. It's like an executable specification that's helping you prove that you understand the system." — Lou Franco

Lou identifies onboarding as an underutilized opportunity for tech debt reduction. When new engineers join, they need to learn the codebase. Rather than just reading code or shadowing, Lou suggests having them write unit tests in areas they're learning. This serves dual purposes: tests are executable specifications that prove understanding of system behavior, and they create safety nets in areas that likely lack coverage (otherwise, why would new engineers be confused by the code?). The new engineer gets hands-on learning, the team gets better test coverage, and everyone wins. This practice also surfaces confusing code — if new engineers struggle to understand what to test, that's a signal the code needs clarifying comments, better naming, or refactoring. Make onboarding a systematic tech debt reduction opportunity rather than passive knowledge transfer.

Leadership's Role: Constraints, Autonomy, and Accountability

"Leadership needs to express the constraints. Tell the team what you're feeling about tech debt at a high level, and what you think generally is the appropriate amount of time to be spent on it. Then give them autonomy." — Lou Franco

Lou distills leadership's role in tech debt management to three elements. First, express constraints — communicate where you believe the product is in its lifecycle (early startup, rapid growth, mature cash cow) and what that means for tech debt tolerance. Are we pursuing product-market fit where code might be thrown away? Are we scaling a proven product where reliability matters? Are we maintaining a stable system where operational efficiency pays dividends? These constraints help teams make appropriate trade-offs. Second, give autonomy — once constraints are clear, trust teams to identify specific tech debt projects that fit those constraints. Engineers understand the codebase's pain points better than leaders do. Third, require accountability — teams must make their work visible through dashboards, metrics, and regular updates. Autonomy without accountability becomes invisible engineering projects that might not deliver value. Accountability without autonomy becomes micromanagement that wastes engineering judgment. The balance creates space for teams to make smart decisions while keeping leadership informed and confident in the investment.

AI and the Future of Tech Debt

"I really do AI-assisted software engineering. And by that, I mean I 100% review every single line of that code. I write the tests, and all the code is as I would have written it, it's just a lot faster. Developers are still responsible for it. Read the code." — Lou Franco

Lou has a chapter about AI in his book, addressing the elephant in the room: will AI-generated code create massive tech debt? His answer is nuanced. AI can accelerate development tremendously if used correctly — Lou uses it extensively but reviews every single line, writes all tests himself, and ensures the code matches what he would have written manually. The problem emerges with "vibe coders" — non-developers using AI to generate code they don't understand, creating unmaintainable messes that become someone else's problem. Developers remain responsible for all code, regardless of how it's generated. This means you must read and understand AI-generated code, not blindly accept it. Lou also raises supply chain security concerns — dependencies can contain malicious code, and AI might introduce vulnerabilities developers miss. His recommendation: stay six months behind on dependency updates, let others discover the problems first, and consider separate sandboxed development machines to limit security exposure. AI is a powerful tool, but it doesn't eliminate the need for engineering judgment, testing discipline, or code review practices.

The Style Guide Beyond Formatting

"Have a style guide that goes beyond formatting to include target architecture. This is the kind of code we want to write going forward." — Lou Franco

Lou advocates for style guides that extend beyond tabs-versus-spaces formatting rules to include architectural guidance. Document patterns you want to move toward: how should components be structured, what state management approaches do we prefer, how should we handle errors, what testing patterns should we follow? This creates a shared understanding of the target architecture without requiring a massive design document. When reviewing pull requests, teams can reference the style guide to explain why certain approaches align with where the codebase is headed versus perpetuating old patterns. This makes tech debt conversations less personal and more objective — it's not about criticizing someone's code, it's about aligning with team standards and strategic direction. The style guide becomes a living document that evolves as the team learns and technology changes, capturing collective wisdom about what good code looks like in your specific context.

Recommended Resources

Some of the resources mentioned in this episode include:

About Lou Franco

Lou Franco is a veteran software engineer and author of Swimming in Tech Debt. With decades of experience at startups, as well as Trello, and Atlassian, he's seen both sides of debt—as coder and leader. Today, he advises teams on engineering practices, helping them turn messy codebases into momentum.

You can link with Lou Franco on LinkedIn and learn more at LouFranco.com.

Jaksot(200)

When Teams Lose Trust—How Scrum Masters Rebuild It One Small Change at a Time | Sara Di Gregorio

When Teams Lose Trust—How Scrum Masters Rebuild It One Small Change at a Time | Sara Di Gregorio

Sara Di Gregorio: When Teams Lose Trust—How Scrum Masters Rebuild It One Small Change at a Time 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.   "I continue to approach this situation with openness, positivity, and trust, because I truly believe that even the smallest changes can make a difference over time." - Sara Di Gregorio   Sara faced one of the most challenging situations a Scrum Master can encounter—a team member who had lost all trust in change, creating a negative atmosphere that weighed heavily on the entire team. She remembers the heaviness on her shoulders, feeling personally responsible for the team's wellbeing. The negativity was palpable during every meeting, and it threatened to undermine the team's progress.  But Sara refused to give up. She started experimenting with different approaches: one-to-one conversations to understand what was happening, bringing intentional energy to meetings, and trying new facilitation techniques in retrospectives. She added personal check-ins, asking "How are you today?" at the start of stand-ups, consciously bringing positive energy even on days when she didn't feel it herself.  She discovered that listening—truly listening, not just hearing—means understanding how people feel, not just what they're saying. Sara learned that the energy you bring to interactions matters deeply. Starting the day with genuine interest, asking about the team's wellbeing, and even making small comments about the weather could create tiny shifts—a small smile that signaled something had changed.  Her approach was rooted in persistence and belief: she continued approaching the situation with openness, positivity, and trust, knowing that even the smallest changes can make a difference over time. For Sara, reestablishing a good environment wasn't about quick fixes—it was about showing up every day with the right energy and never giving up on her team.   Self-reflection Question: What energy are you bringing to your interactions with the team today, and how might that be shaping the team's atmosphere?   [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 Sara Di Gregorio   Sara is a people-centered Scrum Master who champions trust, collaboration, and real value over rigid frameworks. With experience introducing Agile practices, she fosters empathy, inclusion, and clarity in every team. As an Advanced Scrum Master, she helps teams grow, perform, and deliver with enthusiasm and purpose.   You can link with Sara Di Gregorio on LinkedIn.

17 Marras 15min

BONUS: Flawless Execution — Translating Fighter Pilot Precision to Business Results | Christian "Boo" Boucousis

BONUS: Flawless Execution — Translating Fighter Pilot Precision to Business Results | Christian "Boo" Boucousis

BONUS: Flawless Execution — Translating Fighter Pilot Precision to Business Results In this powerful conversation, former fighter pilot Christian "Boo" Boucousis reveals how military precision translates into agile business leadership. We explore the FLEX model (Plan-Brief-Execute-Debrief), the critical difference between control-based and awareness-based leadership, and why most organizations fail to truly embrace iterative thinking. From Cockpit to Boardroom: An Unexpected Journey "I learned over time that it doesn't matter what you do if you're always curious, and you're always intentional, and you're always asking questions." — Christian "Boo" Boucousis   Christian's path from fighter pilot to leadership consultant wasn't planned—it was driven by necessity and curiosity. After 11 years as a fighter pilot (7 in Australia, 4 in the UK), an autoimmune condition ended his flying career at age 30. Rather than accepting a comfy job flying politicians around, he chose entrepreneurship. He moved to Afghanistan with a friend and built a reconstruction company that grew to a quarter billion dollars in four years. The secret? The debrief skills he learned as a fighter pilot. By constantly asking "What are you trying to achieve? How's it going? Why is there a gap?" he approached business with an agile mindset before he even knew what agile was. This curiosity-driven, question-focused approach became the foundation for everything that followed. The FLEX Model: Plan-Brief-Execute-Debrief "Agile and scrum were co-created by John Sutherland, who was a fighter pilot, and its origins sit in the OODA loop and iteration. Which is why it's a circle." — Christian "Boo" Boucousis   The FLEX model isn't new—fighter pilots have used this Plan-Brief-Execute-Debrief cycle for 60 years. It's the ultimate simple agile model, designed to help teams accelerate toward goals using the same accelerated learning curve the Air Force uses to train fighter pilots. The key insight: everything in this model is iterative, not linear. Every mission has a start, middle, and end, and every stage involves constant adaptation. Afterburner (the company Christian now leads as CEO) has worked with nearly 3,800 companies and 2.8 million people over 30 years, teaching this model. What's fascinating is that the DNA of agile is baked into fighter pilot thinking—John Sutherland, co-creator of Scrum, wrote the foreword for Christian's book "The Afterburner Advantage" because they share the same roots in the OODA loop and iterative thinking. Why Iterative Thinking Doesn't Come Naturally "Iterative thinking is not a natural human model. Most of the time we learn from mistakes. We don't learn as a habit." — Christian "Boo" Boucousis   Here's the hard truth: agile as a way of working is very different from the way human beings naturally think. Business leadership models still hark back to Frederick Winslow Taylor's 1911 book on scientific management—industrial era leadership designed for building buildings, not creating software. Time is always linear (foundation, then structure, then finishing), and this shapes how we think about planning. Humans also tend to organize like villages with chiefs, warriors, and gatherers—hierarchical and political. Fighter pilots created a parallel system where politics exist outside missions, but during execution, personality clashes can't interfere. The challenge for business isn't the method—it's getting human minds to embrace iteration as a habit, not just a process they follow when forced. Planning: Building Collective Consciousness, Not Task Lists "Planning isn't all about sequencing actions—that's not planning. That's the byproduct of planning, which is collectively agreeing what good looks like at the end." — Christian "Boo" Boucousis   Most people plan in their head or in front of a spreadsheet by themselves. That's not planning—that's collecting thoughts. Real planning means bringing everyone on the team together to build collective consciousness about what's possible. The plan is always "the best idea based on what we know now." Once airborne, everything changes because the enemy doesn't cooperate with your plan. Planning is about the destination, not the work to get there. Think about airline pilots: they don't tell you about traffic delays on their commute or maintenance issues. They say "Welcome aboard, our destination is Amsterdam, there's weather on the way, we'll land 5 minutes early." That's a brief—just the effect on you based on all their work. Most business meetings waste 55 minutes on backstory and 5 minutes deciding to have another meeting. Fighter pilots focus entirely on: What are we trying to achieve? What might get in the way? Let's go. Briefing: The 25-Minute Focus Window "You need 25 minutes of focus before your brain really focuses on the task. You program your brain for the mission at hand." — Christian "Boo" Boucousis   The brief is the moment between planning and execution when the plan is as accurate as it'll ever get. It's called "brief" for a reason—it's really short. The team checks that everyone understands the plan in today's context, accounting for last-minute changes (broken equipment, weather, personnel changes). Then comes the critical part: creating the mission bubble. From the brief until mission end, there are no distractions, no notifications. If someone tries to interrupt a fighter pilot walking to the jet, the response is clear: "I'm in my mission bubble. No distractions." This isn't optional—research shows it takes 25 minutes of uninterrupted focus before your brain truly locks onto a task. Yet most business leaders expect constant availability, with notifications pinging every few minutes. If you need everyone to have notifications on to run your business, you're doing a really bad job at planning. Execution: Awareness-Based Leadership vs. Control-Based Leadership "The reason we have so many meetings is because the leader is trying to control the situation and own all the awareness. It's not humanly possible to do that." — Christian "Boo" Boucousis   During execution, fighter pilots fly the plan until it doesn't work anymore—then they adapt. A mission commander might lead 70 airplanes, but can't possibly track all 69 others. Instead, they create "gates"—checkpoints where everyone confirms they're in the right place within 10 seconds. They plan for chaos, creating awareness points where the team is generally on track or not. The key shift: from control-based leadership (the leader tries to control everything) to awareness-based leadership (the leader facilitates and listens for divergences). This includes "subordinated leadership"—any of the four pilots in a formation can take the lead if they have better awareness. If a wingman calls out a threat the leader doesn't see, the immediate response is "Press! You take the lead." This works because they planned for it and have criteria. Business teams profess to want this kind of agile collaboration, but struggle because they haven't invested in the planning and shared understanding that makes fluid leadership transitions possible. Abort Criteria: Knowing When to Stop "We have this concept called abort criteria. If certain criteria are hit, we abort the mission. I think that's a massive opportunity for business." — Christian "Boo" Boucousis   There are degrees of things going wrong: a little bit, a medium amount, and everything going wrong. When everything's going wrong, fighter pilots stop and turn around—they don't keep pressing a bad situation. This "abort criteria" concept is massively underutilized in business. Too often, teams press bad situations, transparency disappears, people stop talking, and everyone goes into survival mode (protect myself, blame others). This never happens with fighter pilots. If something goes wrong, they take accountability and make the best decision. The most potent team size is four people: a leader, deputy leader, and two wingmen. This small team size with clear roles and shared abort criteria creates psychological safety to call out problems and adapt quickly. The Retrospective Mindset: Not Just a Ritual "A retrospective isn't a ritual. It's actually a way of thinking. It's a cognitive model. If you approached everything as a retrospective—what are we trying to achieve? How's it going? Why is it not going where we want? What's the one action to get back on track?" — Christian "Boo" Boucousis   The debrief—the retrospective—is the most important part of fighter pilot culture translated into agile. It's not just a meeting you have at the end of a sprint. It's a mindset you apply to everything: projects, relationships, personal development. Christian introduces "Flawless Leadership" built on three M's: Method (agile practices), Mindset (growth mindset developed through acting iteratively), and Moments (understanding when to show up as a people leader vs. an impact leader). The biggest mistake in technology: teams do retrospectives internally but don't include the business. They get a brief from the business, build for two months, come back, and the business says "What is this? This isn't what I expected." If they'd had the business in every scrum, every iteration, trust would build naturally. Everyone involved in the mission must be part of the planning, briefing, executing, and debriefing. Leading in the Moment: Three Layers of Leadership "Your job as a scrum master, as a leader—it doesn't matter if you're leading a division of people—is to be aware. And you're only going to be aware by listening." — Christian "Boo" Boucousis   Christian breaks leadership into three layers: People Leadership (political, emotional, dealing with personalities and overwhelm), Impact Leadership (the agile layer, results-driven, scientific), and Leading Now (the reactive, amygdala-driven panic response when things go wrong). The mistake: mixing these layers. Don't try to be a people leader during execution—that's not the time. But if you're really good at impact leadership (planning, breaking epics into stories, getting work done), you become high trust and high credibility. People leadership becomes easier because success eliminates excuses. During execution, watch for individual traits and blind spots. Use one-on-ones with a retrospective mindset: "What does good look like for you? How do we get to where you're not frustrated?" When leaders aren't present—checking phones and watches during meetings—they lose people. Your job as a leader is to turn your ears on, facilitate (not direct), and listen for divergences others don't see. The Technology-Business Disconnect "Every time you're having a scrum, every time you're coming together to talk about the product, just have the business there with you. It's easy." — Christian "Boo" Boucousis   One of the biggest packages of work Afterburner does: technology teams ask them to help build trust with the business. The solution is shockingly simple—include the business in every scrum, every planning session, every retrospective. Agile is a tech-driven approach, creating a disconnect. Technology brings overwhelming information about how hard they're working and problems they've solved, but business doesn't care about the past. They care about the future: what are you delivering and when? During the Gulf War, the military scaled this fighter pilot model to large-scale planning. Fighter pilots work with marines, special forces, navy, CIA agents—everyone is part of the plan. If one person is missing from planning, execution falls apart. If someone on the ground doesn't know how an F-18 works, the jet is just expensive decoration. Planning is about learning what everyone else does and how to support them best—not announcing what you'll do and how you'll do it. High-Definition Destinations: Beyond Goals "Planning is all about the destination, not the work to get there. Think about when you hop on an airplane—the pilot doesn't tell you the whole backstory. They say 'Welcome aboard, our destination is Amsterdam, there's weather on the way, we'll land 5 minutes early.' All you want is the effect on you." — Christian "Boo" Boucousis   Christian uses the term "High-Definition Destinations" rather than goals. The difference is clarity and vividness. When you board a plane, you don't get the pilot's commute story or maintenance details—you get the destination, obstacles, and estimated arrival. That's communication focused on effect, not process. Most business communication does the opposite: overwhelming context, backstory, and detail, with the destination buried somewhere in the middle. The brief should always be: Here's where we're going. Here's what might get in the way. Let's go. This communication style—focused on outcomes and effects rather than processes and problems—transforms how teams align and execute. It eliminates the noise and centers everyone on what actually matters: the destination.   About Christian "Boo" Boucousis   Christian "Boo" Boucousis is a former fighter pilot who now helps leaders navigate today's fast-moving world. As CEO of Afterburner and author of The Afterburner Advantage, he shares practical, people-centered tools for turning chaos into clarity, building trust, and delivering results without burning out.   You can link with Christian "Boo" Boucousis on LinkedIn, visit Afterburner.com, check out his personal site at CallMeBoo.com, or interact with his AI tool at AIBoo.com.

15 Marras 42min

When Product Owners Facilitate Vision Instead of Owning It | Alidad Hamidi

When Product Owners Facilitate Vision Instead of Owning It | Alidad Hamidi

Alidad Hamidi: When Product Owners Facilitate Vision Instead of Owning It 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: Co-Creating Vision Through Discovery "The best product owner I worked with was not a product owner, but a project manager. And she didn't realize that she's acting as a product owner." - Alidad Hamidi   The irony wasn't lost on Alidad. The best Product Owner he ever worked with didn't have "Product Owner" in her title—she was a project manager who didn't even realize she was acting in that capacity. The team was working on a strategic project worth millions, but confusion reigned about what value they were creating. Alidad planned an inception workshop to create alignment among stakeholders, marketing, operations, advisors, and the team.   Twenty minutes into the session, Alidad asked a simple question: "How do we know the customer has this problem, and they're gonna pay for it?" Silence. No one knew. To her immense credit, the project manager didn't retreat or deflect. Instead, she jumped in: "What do we need to do?" Alidad suggested assumptions mapping, and two days later, the entire team and stakeholders gathered for the workshop. What happened next was magic. "She didn't become a proxy," Alidad emphasizes. She didn't say, "I'll go find out and come back to you." Instead, she brought everyone together—team, stakeholders, and customers—into the same room.   The results were dramatic. The team was about to invest millions integrating with an external vendor. Through the assumption mapping workshop, they uncovered huge risks and realized customers didn't actually want that solution. "We need to pivot," she declared. Instead of the expensive integration, they developed educational modules and scripts for customer support and advisors. The team sat with advisors, listening to actual customer calls, creating solutions based on real needs rather than assumptions. The insight transformed not just the project but the project manager herself. She took these discovery practices across the entire organization, teaching everyone how to conduct proper discovery and fundamentally shifting the product development paradigm. One person, willing to facilitate rather than dictate, made this impact. "Product owner can facilitate creation of that [vision]," Alidad explains. "It's not just product owner or a team. It's the broader stakeholder and customer community that need to co-create that."   Self-reflection Question: Are you facilitating the creation of vision with your stakeholders and customers, or are you becoming a proxy between the team and the real sources of insight? The Bad Product Owner: Creating Barriers Instead of Connections "He did the opposite, just creating barriers between the team and the environment." - Alidad Hamidi   The Product Owner was new to the organization, technically skilled, and genuinely well-intentioned. The team was developing solutions for clinicians—complex healthcare work requiring deep domain understanding. Being new, the PO naturally leaned into his strength: technical expertise. He spent enormous amounts of time with the team, drilling into details, specifying exactly how everything should look, and giving the team ready-made solutions instead of problems to solve.   Alidad kept telling him: "Mate, you need to spend more time with our stakeholder, you need to understand their perspective." But the PO didn't engage with users or stakeholders. He stayed comfortable in his technical wheelhouse, designing solutions in isolation. The results were predictable and painful. Halfway through work, the PO would realize, "Oh, we really don't need that." Or worse, the team would complete something and deliver it to crickets—no one used it because no one wanted it. "Great person, but it created a really bad dynamic," Alidad reflects. What should have been the PO's job—understanding the environment, stakeholder needs, and market trends—never happened. Instead of putting people in front of the environment to learn and adapt, he created barriers between the team and reality.   Years later, Alidad's perspective has matured. He initially resented this PO but came to realize: "He was just being human, and he didn't have the right support and the environment for him." Sometimes people learn only after making mistakes. The coaching opportunity isn't to shame or blame but to focus on reflection from failures and supporting learning. Alidad encouraged forums with stakeholders where the PO and team could interact directly, seeing each other's work and constraints. The goal isn't perfection—it's creating conditions where Product Owners can connect teams to customers rather than standing between them.   Self-reflection Question: What barriers might you be unintentionally creating between your team and the customers or stakeholders they need to serve, and what would it take to remove yourself from the middle?   [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 Alidad Hamidi   Alidad is a strategic advisor in human-centred transformation, focused on organisational design for autonomy, ownership, and impact. A recovering Agility Coach, he draws on years across delivery and coaching roles to help build organisations truly fit for humans—resilient, adaptive, and designed for people, not just processes.   You can link with Alidad Hamidi on LinkedIn. You can also visit his website at desirablefutures.group.

14 Marras 15min

Maximizing Human Potential as the Measure of Success | Alidad Hamidi

Maximizing Human Potential as the Measure of Success | Alidad Hamidi

Alidad Hamidi: Maximizing Human Potential as the Measure of Success 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.   "Does my work lead into maximizing human potential? Maximizing the ability of the human to use their potential and freedom." - Alidal Hamidi   Alidad calls himself a "recovering agility coach," and for good reason. For years, he struggled to define success in his work. As an enterprise coach, he plants seeds but never sees the trees grow. By the time transformation takes root, he's moved on to the next challenge. This distance from outcomes forced him to develop a more philosophical definition of success—one rooted not in deliverables or velocity charts, but in human potential and freedom.   His measure of success centers on three interconnected questions. First, are customers happy with what the teams create? Notice he says "create," not "deliver"—a deliberate choice. "I really hate the term product delivery, because delivery means you have a feature factory," he explains. Creating value requires genuine interaction between people who solve problems and people who have problems, with zero distance between them. Second, what's the team's wellbeing? Do they have psychological safety, trust, and space for innovation? And third, is the team growing—and by "team," Alidad means the entire organization, not just the squad level.   There's a fourth element he acknowledges: business sustainability. A bank could make customers ecstatic by giving away free money, but that's not viable long-term. The art lies in balance. "There's always a balance, sometimes one grows more than the other, and that's okay," Alidad notes. "As long as you have the awareness of why, and is that the right thing at the right time." This definition of success requires patience with the messy reality of organizations and faith that when humans have the freedom to use their full potential, both people and businesses thrive.   Self-reflection Question: If you measured your success solely by whether you're maximizing human potential and freedom in your organization, what would you start doing differently tomorrow? Featured Retrospective Format for the Week: Six Intrinsic Motivators Alidad's favorite retrospective format comes from Open Systems Theory—the Six Intrinsic Motivators. This approach uses the OODA Loop philosophy: understanding reality and reflecting on actions. "Let's see what actually happened in reality, rather than our perception," Alidad explains.   The format assesses six elements. Three are personal and can have too much or too little (rated -10 to +10): autonomy in decision making, continuous learning and feedback, and variety in work. Three are team environment factors that you can't have too much of (rated 0 to 10): mutual support and respect, meaningfulness (both socially useful work and seeing the whole product), and desirable futures (seeing development opportunities ahead).   The process is elegantly simple. Bring the team together and ask each person to assess themselves on each criterion. When individuals share their numbers, fascinating conversations emerge. One person's 8 on autonomy might surprise a teammate who rated themselves a 3. These differences spark natural dialogue, and teams begin to balance and adjust organically. "If these six elements don't exist in the team, you can never have productive human teams," Alidad states. He recommends running this at least every six months, or every three months for teams experiencing significant change. The beauty? No intervention from outside is needed—the team naturally self-organizes around what they discover together.   [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 Alidad Hamidi   Alidad is a strategic advisor in human-centred transformation, focused on organisational design for autonomy, ownership, and impact. A recovering Agility Coach, he draws on years across delivery and coaching roles to help build organisations truly fit for humans—resilient, adaptive, and designed for people, not just processes.   You can link with Alidad Hamidi on LinkedIn. You can also visit his website at desirablefutures.group.

13 Marras 12min

The Tax Teams Pay for Organizational Standards | Alidad Hamidi

The Tax Teams Pay for Organizational Standards | Alidad Hamidi

Alidad Hamidi: The Tax Agile Teams Pay for Organizational Standards 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.   "If you set targets for people, they will achieve the target, even if that means destroying the system around them." - W. Edwards Deming (quoted by Alidad)   The tension is familiar to every Scrum Master working in large organizations: leadership demands standard operating models, flow time metrics below specific numbers, and reporting structures that fit neat boxes. Meanwhile, teams struggle under the weight of context-insensitive measurements that ignore the nuanced reality of their work. Alidad faces this challenge daily—creating balance between organizational demands and what teams actually need to transform and thrive.   His approach starts with a simple but powerful question to leaders: "What is it that you want to achieve with these metrics?" Going beyond corporate-speak to have real conversations reveals that most leaders want outcomes, not just numbers. Alidad then involves teams in defining strategies to achieve those outcomes, framing metrics as "the tax we pay" or "the license to play." When teams understand the intent and participate in the strategy, something surprising happens—most metrics naturally improve because teams are delivering genuine value, customers are happy, and team dynamics are healthy.   But context sensitivity remains critical. Alidad uses a vivid analogy: "If you apply lean metrics to Pixar Studio, you're gonna kill Pixar Studio. If you apply approaches of Pixar Studio to production line, they will go bankrupt in less than a month." Toyota's production line and Pixar's creative studio both need different approaches based on their context, team evolution, organizational maturity, and market environment. He advocates aligning teams to value delivery with end-to-end metrics rather than individual team measurements, recognizing that organizations operate in ecosystem models beyond simple product paradigms.   Perhaps most important is patience. "Try to not drink coffee for a week," Alidad challenges. "Even for a single person, one practice, it's very hard to change your behavior. Imagine for organization of hundreds of thousands of people." Organizations move through learning cycles at their own rhythm. Our job isn't to force change at the speed we prefer—it's to take responsibility for our freedom and find ways to move the system, accepting that systems have their own speed.   Self-reflection Question: Which metrics are you applying to your teams without considering their specific context, and what conversation do you need to have with leadership about the outcomes those metrics are meant to achieve?   [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 Alidad Hamidi   Alidad is a strategic advisor in human-centred transformation, focused on organisational design for autonomy, ownership, and impact. A recovering Agility Coach, he draws on years across delivery and coaching roles to help build organisations truly fit for humans—resilient, adaptive, and designed for people, not just processes.   You can link with Alidad Hamidi on LinkedIn. You can also visit his website at desirablefutures.group.

12 Marras 18min

When a Billion-Dollar Team Becomes Invisible | Alidad Hamidi

When a Billion-Dollar Team Becomes Invisible | Alidad Hamidi

Alidad Hamidi: When a Billion-Dollar Team Becomes Invisible 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.   "Most of the times, it's not teams that are self-destructive or anything... Simple analogy is when a flower is not blooming, you don't fix the flower, you fix the soil." - Alidad Hamidi   The team sat on the sidelines, maintaining a large portfolio of systems while the organization buzzed with excitement about replatforming initiatives. Nobody seemed to care about them. Morale was low. Whenever technical challenges arose, everyone pointed to the same person for help. Alidad tried the standard playbook—team-building activities, bonding exercises—but the impact was minimal. Something deeper was broken, and it wasn't the team.   Then Alidad shifted his lens to systems thinking. Instead of fixing the flower, he examined the soil. Using the Viable Systems Model, he started with System 5—identity. Who were they? What value did they create? He worked with stakeholders to map the revenue impact of the systems this "forgotten" team maintained. The number shocked everyone: one billion dollars. These weren't legacy systems gathering dust—they were revenue-generating engines critical to the business. Alidad asked the team to run training series for each other, teaching colleagues about the ten different systems they managed. They created self-assessments of skill sets, making visible what had been invisible for too long. When Alidad made their value explicit to the organization, everything shifted. The team's perspective transformed. Later, when asked what made the difference, their answer was unanimous: "You made us visible. That's it." People have agency to change their environment, but sometimes they need someone to help the system see what it's been missing. Ninety percent of the time, when teams struggle, it's not the team that needs fixing—it's the soil they're planted in.   Self-reflection Question: What teams in your organization are maintaining critical systems but remain invisible to leadership, and what would happen if you made their value explicit? Featured Book of the Week: More Time to Think by Nancy Kline Alidad describes Nancy Kline's More Time to Think as transformative for his facilitation practice. While many Scrum Masters focus on filling space and driving conversations forward, this book teaches the opposite—how to create space and listen deeply. "It teaches you to create a space, not to fill it," Alidad explains. The book explores how to design containers—meetings, workshops, retrospectives—that allow deeper thinking to emerge naturally among team members.   For Alidad, the book answered a fundamental question: "How do you help people to find the solution among themselves?" It transformed his approach from facilitation to liberation, helping teams slow down so they can think more clearly. He first encountered the audiobook and was so impacted that he explored both "Time to Think" and this follow-up. While both are valuable, "More Time to Think" resonated more deeply with his coaching philosophy. The book pairs beautifully with systems thinking, helping Scrum Masters understand that creating the right conditions for thinking is often more powerful than providing the right answers. In this segment, we also refer to the book Confronting our freedom, by Peter Block et al.    [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 Alidad Hamidi   Alidad is a strategic advisor in human-centred transformation, focused on organisational design for autonomy, ownership, and impact. A recovering Agility Coach, he draws on years across delivery and coaching roles to help build organisations truly fit for humans—resilient, adaptive, and designed for people, not just processes.   You can link with Alidad Hamidi on LinkedIn. You can also visit his website at desirablefutures.group.

11 Marras 15min

When Silence Becomes Your Most Powerful Coaching Tool | Alidad Hamidi

When Silence Becomes Your Most Powerful Coaching Tool | Alidad Hamidi

Alidad Hamidi: When Silence Becomes Your Most Powerful Coaching Tool 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.   "I purposefully designed a moment of silence. Staying in the anxiety of being silenced. Do not interrupt the team. Put the question there, let them come up with a solution. It is very hard. But very effective." - Alidad Hamidi   Alidad walked into what seemed like a straightforward iteration manager role—what some use, instead of Scrum Master. The organization was moving servers to the cloud, a transformation with massive implications. When leadership briefed him on the team's situation, they painted a clear picture of challenges ahead. Yet when Alidad asked the team directly about the transformation's impact, the response was uniform: "Nothing."   But Alidad knew better. After networking with other teams, he discovered the truth—this team maintained software generating over half a billion dollars in revenue, and the transformation would fundamentally change their work. When he asked again, silence filled the room. Not the comfortable silence of reflection, but the heavy silence of fear and mistrust. Most facilitators would have filled that void with words, reassurance, or suggestions. Alidad did something different—he waited. And waited. For what felt like an eternity, probably a full minute, he stood in that uncomfortable silence, about to leave the room.   Then something shifted. One team member picked up a pen. Then another joined in. Suddenly, the floodgates opened. Debates erupted, ideas flew, and the entire board filled with impacts and concerns. What made the difference? Before that pivotal moment, Alidad had invested in building relationships—taking the team to lunch, standing up for them when managers blamed them for support failures, showing through his actions that he genuinely cared. The team saw that he wasn't there to tell them how to do their jobs. They started to trust that this silence wasn't manipulation—it was genuine space for their voices. This moment taught Alidad a profound lesson about Open Systems Theory and Socio-Technical systems—sometimes the most powerful intervention is creating space and having the courage to hold it.   Self-reflection Question: When was the last time you designed a moment of silence for your team, and what held you back from making it longer?   [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 Alidad Hamidi   Alidad is a strategic advisor in human-centred transformation, focused on organisational design for autonomy, ownership, and impact. A recovering Agility Coach, he draws on years across delivery and coaching roles to help build organisations truly fit for humans—resilient, adaptive, and designed for people, not just processes.   You can link with Alidad Hamidi on LinkedIn. You can also visit his website at desirablefutures.group.

10 Marras 15min

From Requirements Documents to Customer Obsession—Redefining the PO Role | Karim Harbott

From Requirements Documents to Customer Obsession—Redefining the PO Role | Karim Harbott

Karim Harbott: From Requirements Documents to Customer Obsession—Redefining the PO Role 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: Strategic, Customer-Obsessed, and Vision-Driven   "The PO role in the team is strategic. These POs focus on the customer, outcomes, and strategy. They're customer-obsessed and focus on the purpose and the why of the product." - Karim Harbott   Karim believes the industry fundamentally misunderstands what a Product Owner should be. The great Product Owners he's seen are strategic thinkers who are obsessed with the customer. They don't just manage a backlog—they paint a vision for the product and help the entire team become customer-obsessed alongside them.  These POs focus relentlessly on outcomes rather than outputs, asking "why are we building this?" before diving into "what should we build?" They understand the purpose of the product and communicate it compellingly.  Karim references Amazon's "working backwards" approach, where Product Owners start with the customer experience they want to create and work backwards to figure out what needs to be built. Great POs also embrace the framework of Desirability (what customers want), Viability (what makes business sense), Feasibility (what's technically possible), and Usability (what's easy to use). While the PO owns desirability and viability, they collaborate closely with designers on usability and technical teams on feasibility.  This is critical: software is a team sport, and great POs recognize that multiple roles share responsibility for delivery. Like David Marquet teaches, they empower the team to own decisions rather than dictating every detail. The result? Teams that understand the "why" and can innovate toward it autonomously.   Self-reflection Question: Does your Product Owner paint a compelling vision that inspires the team, or do they primarily manage a list of tasks? The Bad Product Owner: The User Story Writer "The user story writer PO thinks it's their job to write full, long requirements documents, put it in JIRA, and assign it to the team. This is far away from what the PO role should be." - Karim Harbott   The anti-pattern Karim sees most often is the "User Story Writer" Product Owner. These POs believe their job is to write detailed requirements documents, load them into JIRA, and assign them to the team. It's essentially waterfall disguised as Agile—treating user stories like mini-specifications rather than conversation starters. This approach completely misses the collaborative nature of product development.  Instead of engaging the team in understanding customer needs and co-creating solutions, these POs hand down fully-formed requirements and expect the team to execute without question. The problem is that this removes the team's ownership and creativity. When POs act as the sole source of product knowledge, they become bottlenecks.  The team can't make smart tradeoffs or innovate because they don't understand the underlying customer problems or business context. Using the Desirability-Viability-Feasibility-Usability framework, bad POs try to own all four dimensions themselves instead of recognizing that designers, developers, and other roles bring essential perspectives. The result is disengaged teams, slow delivery, and products that miss the mark because they were built to specifications rather than shaped by collaborative discovery. Software is a team sport—but the User Story Writer PO forgets to put the team on the field.   Self-reflection Question: Is your Product Owner engaging the team in collaborative discovery, or just handing down requirements to be implemented?   [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 Karim Harbott   Karim is a consultant, trainer, and non-executive director. He bridges the gap between strategy, business agility, digital transformation, innovation, AI, and board governance. He is a Certified Scrum Trainer, and is the author of The 6 Enablers of Business Agility.   You can link with Karim Harbott on LinkedIn.

7 Marras 13min

Suosittua kategoriassa Politiikka ja uutiset

rss-ootsa-kuullut-tasta
aikalisa
tervo-halme
ootsa-kuullut-tasta-2
politiikan-puskaradio
viisupodi
rss-podme-livebox
et-sa-noin-voi-sanoo-esittaa
otetaan-yhdet
rss-vaalirankkurit-podcast
aihe
the-ulkopolitist
rss-polikulaari-humanisti-vastaa-ja-muut-ts-podcastit
rss-hyvaa-huomenta-bryssel
rss-kuka-mina-olen
politbyroo
linda-maria
rss-lets-talk-about-hair
rss-50100-podcast
rss-tekoalyfoorumi