Swimming in Tech Debt — Practical Techniques to Keep Your Team from Drowning in Its Codebase | Lou Franco
Scrum Master Toolbox Podcast: Agile storytelling from the trenches13 Dec

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.

Avsnitt(200)

The No-Scroll Bar Rule—Empowering PO's Through Constraints | Joel Bancroft-Connors

The No-Scroll Bar Rule—Empowering PO's Through Constraints | Joel Bancroft-Connors

Joel Bancroft-Connors: The No-Scroll Bar Rule—Empowering PO's Through Constraints 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: The Collaborative Innovator Joel describes an exceptional Product Owner scenario at a large insurance organization where complementary skills created magic. Working with two different people - a business expert who understood insurance but lacked development knowledge, and a designer with user experience expertise - Joel suggested the designer take on the Product Owner role while collaborating closely with the business person. This collaboration between complementary skills produced outstanding results. The great Product Owner understood that their role wasn't to control every detail but to unleash developer creativity by providing problems and context rather than prescriptive solutions. Joel's approach of "give the developers a problem and a canvas" allowed the team to innovate while staying focused on customer needs. This Product Owner fostered innovation rather than preventing it, demonstrating how effective collaboration can transform product development. The Bad Product Owner: The Business Analyst That Couldn't Let Go Joel identifies a problematic anti-pattern: the Business Analyst who transitions to Product Owner but can't abandon their documentation-heavy approach. While Business Analysts can make excellent Product Owners with proper support, those who insist on documenting everything create communication bottlenecks and slow down delivery. This creates a "telephone game" effect between the BA/PO and developers. Joel encountered one such individual who would declare "the developers can't do that" without giving them the opportunity to explore solutions. Following his "no-scroll bar rule" for documentation, Joel emphasizes that Product Owners should provide just enough information to enable developer creativity, not overwhelming detail that stifles innovation. When the problematic BA was replaced with someone who understood customers and trusted developers, the team's innovation flourished. In this segment, we refer to the book Liftoff, by Larsen and Nies. Self-reflection Question: Are you enabling developer innovation by providing problems and context, or are you stifling creativity with excessive documentation and control? [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Joel Bancroft-Connors Joel Bancroft-Connors is The Gorilla Coach — a Certified Scrum Trainer and Agile disruptor focused on sustainable value and effectiveness. With a background in product, project, and coaching, Joel blends sharp insights with practical tools to help teams thrive. He is a Miro power user and rocks curated classroom playlists. You can link with Joel Bancroft-Connors on LinkedIn.

6 Juni 19min

Sustainable Value—Redefining Success Beyond Profit | Joel Bancroft-Connors

Sustainable Value—Redefining Success Beyond Profit | Joel Bancroft-Connors

Joel Bancroft-Connors: Sustainable Value—Redefining Success Beyond Profit 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. Joel has evolved his definition of Scrum Master success over time, moving beyond traditional metrics to focus on what truly matters: sustainable value delivery. While Agile principles clearly state the goal of delivering value continuously, Joel emphasizes that success isn't just about making profit - it's about creating sustainable profit through sustainable processes and people practices. He challenges Scrum Masters to consider their "people sustainability metric" and asks whether their approach supports long-term team health and organizational resilience. Joel's definition encompasses three pillars: delivering sustainable value, maintaining sustainable processes, and ensuring sustainability for people. This holistic view of success requires Scrum Masters to think beyond immediate outcomes and consider the long-term impact of their practices. In this segment, we refer to the book Turn the ship around! by David Marquet. Self-reflection Question: What is your people sustainability metric, and how are you measuring whether your Scrum practices support long-term team and organizational health? Featured Retrospective Format for the Week: Back to Basics Joel advocates for returning to the foundational retrospective format outlined in "Agile Retrospectives" by Derby and Larsen. Rather than getting caught up in complex or creative retrospective techniques, he emphasizes the power of following the basic steps: set the stage, gather data, generate insights, decide what to do, and close the retrospective. Joel stresses that there's an important arc to retrospectives that shouldn't be overlooked. By taking time to properly gather data and following the structured approach from the agile retrospectives book, teams can achieve more meaningful and actionable outcomes. Sometimes the most effective approach is simply executing the fundamentals exceptionally well. In this segment, we refer to the book Agile retrospectives, by Derby and Larsen. [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Joel Bancroft-Connors Joel Bancroft-Connors is The Gorilla Coach — a Certified Scrum Trainer and Agile disruptor focused on sustainable value and effectiveness. With a background in product, project, and coaching, Joel blends sharp insights with practical tools to help teams thrive. He is a Miro power user and rocks curated classroom playlists. You can link with Joel Bancroft-Connors on LinkedIn.

5 Juni 17min

The 90-Day Rule—Building Trust Before Disrupting the Status Quo | Joel Bancroft-Connors

The 90-Day Rule—Building Trust Before Disrupting the Status Quo | Joel Bancroft-Connors

Joel Bancroft-Connors: The 90-Day Rule—Building Trust Before Disrupting the Status Quo 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. Joel shares his first experience as a CSM at a traditional hard drive manufacturing company, where he learned the art of patient change management. Tasked with bridging the gap between a rigid mothership company and their agile startup division, Joel discovered the power of focusing on principles rather than processes. For six months, he concentrated on creating transparency and shifting focus from status reporting to "getting to done" without ever mentioning Scrum or Agile. His approach followed what he calls the 90-day rule: "In the first 90 days - do no harm, but then have a plan to do something." By listening first and building trust, Joel helped the team deliver a product in just three months. He emphasizes the importance of making people feel valued and using "future perfect thinking" to envision desired outcomes before introducing change. In this episode we refer to Luke Hohmann's Innovation Games, the website and resource Manager-Tools.com, and Daniel Pink's book Drive. Self-reflection Question: Are you rushing to implement changes, or are you taking time to build trust and understand the current state before introducing new practices? [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Joel Bancroft-Connors Joel Bancroft-Connors is The Gorilla Coach — a Certified Scrum Trainer and Agile disruptor focused on sustainable value and effectiveness. With a background in product, project, and coaching, Joel blends sharp insights with practical tools to help teams thrive. He is a Miro power user and rocks curated classroom playlists. You can link with Joel Bancroft-Connors on LinkedIn.

4 Juni 14min

How Performance Reviews Killed a Great Agile Team | Joel Bancroft-Connors

How Performance Reviews Killed a Great Agile Team | Joel Bancroft-Connors

Joel Bancroft-Connors: How Performance Reviews Killed a Great Agile Team 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. Joel tells the story of a team caught in the crossfire of a poorly executed large-scale agile transformation. While the CTO championed going agile, they quickly checked out, leaving the organization without clear direction or understanding of why they were adopting agile practices. The company measured success through output metrics like "number of teams trained" rather than meaningful outcomes. Joel worked with an exceptional team that had built their own collaborative workspace and was performing well, but external forces kept pulling them out of flow. Performance reviews created internal conflict, leading team members to focus on individual success rather than collective achievement. The team ultimately fell into their own traps, with everyone "focusing on themselves and throwing others under the bus." Joel recommends balancing performance evaluations with 50% team-based and 50% individual metrics to prevent this destructive pattern. Self-reflection Question: Does your team truly understand why they are using Scrum, or are they just going through the motions of the framework? Featured Book of the Week: Start with Why by Simon Sinek Joel credits Simon Sinek's "Start with Why" as a transformational influence on his coaching approach. The book's central principle that "people don't buy what you do, they buy why you do it" fundamentally changed how Joel teaches Scrum. He realized he had been teaching Scrum incorrectly by focusing on the mechanics rather than the purpose. Now Joel listens to this book annually and has shifted his focus to helping teams and organizations understand why Scrum matters and why it's important. This shift from teaching the "what" to emphasizing the "why" has made his coaching significantly more effective and meaningful. Joel also mentions the book Coaching Agile Teams by Lyssa Adkins. [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Joel Bancroft-Connors Joel Bancroft-Connors is The Gorilla Coach — a Certified Scrum Trainer and Agile disruptor focused on sustainable value and effectiveness. With a background in product, project, and coaching, Joel blends sharp insights with practical tools to help teams thrive. He is a Miro power user and rocks curated classroom playlists. You can link with Joel Bancroft-Connors on LinkedIn.

3 Juni 12min

When Great Scrum Masters Fail—The Hidden Cost of Poor Value Communication | Joel Bancroft-Connors

When Great Scrum Masters Fail—The Hidden Cost of Poor Value Communication | Joel Bancroft-Connors

Joel Bancroft-Connors: When Great Scrum Masters Fail—The Hidden Cost of Poor Value Communication 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. Joel shares a powerful lesson about the critical importance of communicating value beyond team performance. Despite achieving remarkable success with multiple teams as an agile coach, Joel and his colleagues ultimately failed because they couldn't effectively demonstrate their value to leadership. The teams were thriving, but when budget cuts came, the coaching support was eliminated first. Without ongoing support, these successful teams began to deteriorate. Joel emphasizes that as Scrum Masters and agile coaches, we must actively communicate our impact and connect team success to business outcomes. Simply assuming that good team performance speaks for itself is not enough - we need to interact more with stakeholders and clearly articulate the value we create. In this episode, we refer to the TV series Ted Lasso, and the books Start with Why by Simon Sinek, and Coaching Agile Teams by Lyssa Adkins. Self-reflection Question: How effectively are you communicating the business value of your Scrum Master activities to leadership, and what specific metrics or stories could better demonstrate your impact? [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Joel Bancroft-Connors Joel Bancroft-Connors is The Gorilla Coach — a Certified Scrum Trainer and Agile disruptor focused on sustainable value and effectiveness. With a background in product, project, and coaching, Joel blends sharp insights with practical tools to help teams thrive. He is a Miro power user and rocks curated classroom playlists. You can link with Joel Bancroft-Connors on LinkedIn.

2 Juni 15min

BONUS Martti Kuldma: How to Transform Century-Old Organizations Through Product-Driven Agile Transformation

BONUS Martti Kuldma: How to Transform Century-Old Organizations Through Product-Driven Agile Transformation

BONUS: Martti Kuldma shares how to transform century-old organizations through product-driven agile transformation In this BONUS episode we explore the remarkable transformation journey at Omniva with CEO Martti Kuldma. From traditional postal services to innovative logistics solutions, we explore how a 100+ year old company embraced product thinking, DevOps practices, and agile transformation to become a competitive force in modern logistics. Omniva's Digital Evolution—IT as a Revenue Center "We innovated the parcel machine business for a few years, and software has been an area of investment for us - software as a separate vertical in our business." Omniva represents a fascinating case study in organizational transformation. While many know it as Estonia's post office, the company has evolved into an international logistics powerhouse with significant revenue streams beyond traditional postal services. Under Martti's leadership, the organization has reimagined software not as a support function but as a core revenue driver, positioning itself for the dramatic shifts expected in logistics delivery over the next five years. The Vision: Physical Mailing as the Next IP Network "The Vision: physical mailing as the next IP network - this will give us a lot more freedom to adapt to changes in delivery demand." Martti's strategic vision extends far beyond conventional logistics thinking. By conceptualizing physical delivery networks similar to internet protocols, Omniva is preparing for a future where logistics companies leverage their physical infrastructure advantages. This approach addresses the fundamental challenge of fluctuating demand in e-commerce and traditional logistics, creating opportunities for crowd delivery solutions and gig economy integration that capitalize on existing network effects. Breaking Down Waterfall Barriers "When I came we had waterfall processes - annual budgeting, procurement for software development. It took a couple of weeks to do the first rounds, and understand what could be improved." The transformation from traditional procurement-based software development to agile product teams required dismantling entrenched processes. Martti discovered that the contractor model, while seemingly cost-effective, created expensive knowledge transfer cycles and left the organization vulnerable when external teams departed. His engineering background enabled him to recruit talent and build sustainable development capabilities that keep critical knowledge within the organization. Creating Cross-Functional Product Teams "We started to create cross-functional product area teams. We are not going to tell you what you need to build. You are accountable for the logistics efficiency." The shift from eleven distinct roles in software development to autonomous product teams represents more than organizational restructuring. By empowering teams with accountability for business outcomes rather than just deliverables, Omniva transformed how work gets planned and executed. This approach eliminates traditional handoffs and role silos, creating teams that own both the problem and the solution. The Product Manager Evolution "For me, the PM is directly accountable for the business results. The final step of the transformation started when I took the CEO role." Martti identifies a critical challenge in agile transformations: the misunderstanding of Product Manager responsibilities. Rather than falling into delivery or project management patterns, effective PMs at Omniva own business results directly. This shift required company-wide transformation because technical changes alone cannot sustain organizational evolution without corresponding changes in mindset and accountability structures. Leadership Through Storytelling "My main tool is just talking. All I do is story-telling internally and externally. I needed to become the best salesman in the company." The transition from technical leadership to CEO revealed that transformation leadership requires different skills than technical management. Martti discovered that his primary value comes through narrative construction and communication rather than direct technical contribution. This realization highlights how senior leaders must evolve their impact methods as organizations scale and transform. Real-Time Feedback Philosophy "The feedback needs to be given immediately. 'Last year, in May your performance was not the best' - this is completely useless feedback." Martti's rejection of annual reviews stems from practical experience with feedback effectiveness. Immediate, personal feedback creates learning opportunities and course corrections that annual cycles cannot provide. Anonymous 360 feedback systems often dilute accountability and actionability, whereas direct, timely conversations enable meaningful professional development and relationship building. Essential Transformation Practices "You need to tell the story - and convince people that this transformation is essential and needed. You need to trust and let them make their own decisions." Drawing from experiences at both Pipedrive and Omniva, Martti identifies three critical elements for leading complex organizational change: Compelling narrative: People need to understand why transformation is necessary and how it benefits both the organization and their individual growth Distributed decision-making: Trust enables teams to solve problems creatively rather than waiting for hierarchical approval Business accountability for engineers: When technical teams understand and own business outcomes, they innovate more effectively toward meaningful goals The dynamic team formation model used at Pipedrive, where engineers and PMs pitched ideas and assembled mission-focused teams, demonstrates how organizational structure can enable rather than constrain innovation. About Martti Kuldma Martti Kuldma is CEO of Omniva, leading its transformation into a product-driven logistics company. A former engineering leader at Pipedrive and CTO at Omniva, he brings deep expertise in scaling teams, agile transformation, and digital innovation. Martti is also a startup founder and passionate advocate for high-impact product organizations. You can link with Martti Kuldma on LinkedIn.

31 Maj 44min

BONUS Entertainment That Makes Change: Lessons in Product Thinking from Believe Ltd. With Patrick James Lynch

BONUS Entertainment That Makes Change: Lessons in Product Thinking from Believe Ltd. With Patrick James Lynch

BONUS: Patrick James Lynch on Entertainment That Makes Change - Lessons in Product Thinking from Believe Ltd. In this BONUS episode we explore how Patrick James Lynch, filmmaker, media executive, and rare disease advocate, has built Believe Limited around a powerful mission: entertainment that effects change. Patrick shares his journey from personal experience with his brother's hemophilia to creating award-winning content that empowers rare and chronic disease communities, offering valuable lessons for product managers on human-centered design, stakeholder alignment, and building emotionally viable products. The Genesis of Entertainment That Effects Change "This is more than a product." Patrick's journey began with a deeply personal question about his brother who had hemophilia. As an entrepreneur, he set out to respond to an identified need with one product to meet that need, but quickly realized the scope was much larger. His curiosity about what was different between him and his brother led him to understand that he needed to help people like his brother. This realization drove him to create valuable online videos to engage their audience, marking the beginning of Believe Ltd.'s mission of entertainment that effects change. Essential Product Lessons: Listen, Learn, and Do No Harm "The fact that I am my audience, does not mean that I'm an expert." Patrick emphasizes the critical importance of conducting thorough needs assessments and truly understanding your community before building products. Key insights include: Embed yourself in the community you're serving rather than making assumptions Follow the principle of "listen, learn and do no harm" as your starting point Involve community engagement as a dedicated role - Believe Ltd. has a VP of community engagement Define clear phrases that explain the value you deliver to your audience Use your personal story to establish credibility and relate experiences to your audience The goal is to get as familiar with your community as possible, then conduct your own research and development based on those deep insights. Navigating Multi-Stakeholder Complexity "Collaboration only succeeds when all points of view are respected." Working with patients, funders, healthcare professionals, and pharmaceutical companies requires careful orchestration. Patrick's approach centers on prioritizing the end game and identifying the north star goal that aligns all parties. He emphasizes focusing on combined skills and networks rather than trying to accomplish everything at the start. The key is ensuring that aligning stakeholders becomes a central part of the process, with everyone being accounted for throughout the journey. Human-Centered Storytelling as Product Strategy "What's the story that shows the value add of your product?" Patrick advocates for human-centered storytelling as a fundamental product approach. Rather than leading with features or specifications, he suggests crafting stories that demonstrate real value - like how a thermos saved someone's life while hiking. Stories have been humanity's primary communication tool since the beginning of time, and they remain the most effective way to show product value and connect with audiences on a meaningful level. Being a Value Fundamentalist "At any given moment, if anyone takes a screen grab, and set it against our five core values as a company - you see it's playing out." Patrick describes himself as a value fundamentalist, meaning that their company's core values are always present in everything they do. This requires courage, including the willingness to say "no" when opportunities don't align with their values. As CEO, he believes in embodying these values consistently, even when it's challenging, because who they are must always be visible in their work. Balancing Vision with Community Feedback "When you ask the audience for a solution, there's no innovation." Patrick warns against sacrificing vision simply because you're working closely with your audience. While being in the sandbox with your community is essential, maintaining your original vision for entertainment that changes minds is equally important. He recommends having someone you can bounce ideas off to help maintain this balance, and remembers that all great things start small and are inherently iterative. Creating Emotionally Viable Products "We can't develop emotional connection by going through a list of features." Beyond minimum viable products, Patrick focuses on emotional viability - the hook that makes people truly care. Emotional connection cannot be built through feature lists but rather through compelling stories that capture people's imagination. When audiences engage with products outside of direct supervision, storytelling becomes the bridge that helps them discover new uses and applications. This creates a dance between product creators and their audience, leading to better product design. The Currency of Attention "Attention is the only currency - there's great wisdom in that." Patrick recognizes that in today's landscape, capturing and maintaining attention is the fundamental challenge. Since everyone is an audience member at different times, this perspective helps inform both strategy and tactics. Products must compete not just on functionality but on their ability to engage and maintain audience interest over time. As a recommended reading, Patrick suggests that we should read "Save The Cat! The Last Book on Screenwriting You'll Ever Need" to understand how to better tell stories about our products. About Patrick James Lynch Patrick James Lynch is a filmmaker, media executive, and rare disease advocate. CEO of Believe Limited and founder of BloodStream Media, he uses his experience with hemophilia to drive award-winning storytelling, health advocacy, and mission-driven content that inspires and empowers rare and chronic disease communities worldwide. You can link with Patrick James Lynch on LinkedIn and follow Patrick James Lynch's work on his website.

29 Maj 41min

BONUS The Startup CTO's Handbook With Zach Goldberg

BONUS The Startup CTO's Handbook With Zach Goldberg

BONUS: Zach Goldberg shares how to build high-performing engineering teams and master the startup CTO role In this BONUS episode, we dive deep into the world of startup leadership with Zach Goldberg, author of The Startup CTO's Handbook. We explore the critical transition from engineering to leadership, the art of balancing technical debt with startup urgency, and the communication skills that separate great CTOs from the rest. The Genesis of The Startup CTO's Handbook "My original training in software engineering was not enough for being a leader. All the people and leadership skills, I had to learn on my own." Zach's journey to writing The Startup CTO's Handbook began with a stark realization about the gap between technical training and leadership reality. Despite his classical software engineering background, he discovered that the people and leadership skills required for CTO success had to be self-taught. The book emerged from a growing Google Doc of topics and frameworks addressing the leadership and management challenges that CTOs consistently face - from hiring and performance management to making strategic decisions under pressure. Today, we can either buy the digital/print book on Amazon, or read the book on GitHub. In this segment, we also refer to the book The Great CEO Within. Learning to Truly Learn: The Max Mintz Story "Max only cared about my ability to learn - to get curious about something hard. He wanted to help me deal with complexity." Zach opens his book with a deeply personal story about his mentor, Max Mintz, who fundamentally changed his approach to learning during what he calls "the most impactful single coffee" of his life. Over 1.5 years of conversations, Max taught him that true learning isn't about accumulating facts, but about developing curiosity for hard problems and building the capacity to handle complexity. This lesson forms the foundation of effective CTO leadership - the ability to continuously learn and adapt in an ever-changing technical landscape. The Three Critical CTO Mistakes "As a CTO, the most important 3 things: people, people, people. Do the people have the right energy, the right passion? Assemble the right team." Zach identifies consistent patterns in startup CTO failures across his experience. The first and most critical mistake is undervaluing people decisions - failing to prioritize team energy, passion, and the right assembly of talent. The second category involves investment mistakes, particularly the challenge of balancing short-term survival needs with long-term technical goals. In startups, the ROI timespan is exceptionally short, requiring optimization for immediate objectives rather than hypothetical scale. The third mistake is treating technology as religion rather than tools, losing sight of what the business actually needs. Optimizing for Velocity and Developer Experience "You are optimizing for velocity! What are you doing to help developers get their work done? Look at developer experience as a metric." Successful startup CTOs understand that velocity - the time from idea to valuable market delivery - is paramount. This requires a fundamental shift in thinking about technology decisions, focusing on features that deliver real customer value rather than technical elegance. Zach emphasizes measuring developer experience as a key metric, recognizing that anything that helps developers work more effectively directly impacts the company's ability to survive and thrive in competitive markets. The Professional Skill Tree Concept "It's like a character progression in an RPG. When we learn one type of skills, we don't learn other types of skills. We make investments every day and we have a choice on where we learn." Drawing from gaming metaphors, Zach explains how technical professionals often reach Level 100 in engineering skills while remaining Level 1 in management. The skill tree concept highlights that every learning investment is a choice - time spent developing one skill area means less time available for others. For engineers transitioning to leadership, the key is recognizing opportunities to serve as tech leads, where they can begin setting culture and quality standards while still leveraging their technical expertise. Balancing Kaizen with Startup Urgency "Pick the high-impact debt, and pay that down. This is not always easy, especially because we also need to pick what debt we don't invest on." The tension between continuous improvement and startup speed requires sophisticated thinking about technical debt. Using financial analogies, Zach explains that technical debt has both principal and interest components. The key is identifying which debt carries the highest interest rates and can be paid down most quickly, while consciously choosing which debt to carry forward. This approach maintains the healthy tension between quality and speed that defines successful startup engineering. The Power of Audience Empathy "The single hardest skill, especially for very tech leaders is that of 'audience empathy.' When you explain ideas to people, you usually assume a lot - but they might not." According to Zach, the most undervalued communication habit for startup tech leaders is developing audience empathy. Technical leaders often suffer from the curse of knowledge, assuming their audience shares their context and understanding. The solution requires deliberately considering what the audience already knows before crafting any communication, whether it's explaining technical concepts to non-technical stakeholders or providing clear direction to team members. In this segment we refer to the concept of "the curse of knowledge", a cognitive bias that occurs when a person who has specialized knowledge assumes that others share in that knowledge. About Zach Goldberg Zach Goldberg is a seasoned technical entrepreneur, executive coach, and author of The Startup CTO's Handbook. With a founder's mentality and a passion for systems thinking, Zach helps engineering leaders build high-performing teams. He also founded Advance The World, a nonprofit inspiring youth in STEM through immersive experiences. You can link with Zach Goldberg on LinkedIn, and visit Zach's website at CTOHB.com.

28 Maj 41min

Populärt inom Politik & nyheter

svenska-fall
aftonbladet-krim
motiv
p3-krim
fordomspodden
flashback-forever
rss-viva-fotboll
rss-krimstad
aftonbladet-daily
rss-sanning-konsekvens
spar
blenda-2
rss-krimreportrarna
rss-frandfors-horna
rss-vad-fan-hande
dagens-eko
olyckan-inifran
krimmagasinet
rss-flodet
spotlight