The podcast explores how leadership culture significantly impacts software quality, advocating for systemic approaches over isolated testing, while critiquing traditional roles and emphasizing cultural and policy levers in agile development. It highlights the author’s career shift from QA to systems thinking, co-authoring a book on using signals and levers to improve software delivery through holistic, non-linear strategies.

AB Testing

AB Testing - Each episode is a chat between Brent Jensen and Alan Page with an occasional special guest.

• https://www.moderntesting.org/

Episode Details

• Show Notes: https://podcasters.spotify.com/pod/show/abtesting/episodes/Episode-227-Elisabeth-Hendrickson-e3fcf00
• Published: 2026-02-20T19:08:27Z
• Duration: 00:55:14
• Author: AB Testing

Overview

The podcast delves into the evolution of testing, leadership, and agile practices through a conversation between two industry professionals. The discussion covers their career journeys, starting with early experiences in testing and technical writing and progressing into leadership roles within agile environments. A central theme is the importance of systems thinking in software development, with the argument that quality is more significantly influenced by leadership culture than by technical checks or testing alone.

The conversation critiques traditional testing roles and the concept that “everyone is responsible for quality,” suggesting that systemic issues rather than individual errors are often responsible for failures. Key ideas explored include using “levers” like culture and policy to drive outcomes, applying statistical process control and causal modeling to understand variability, and the importance of feedback loops in improving development processes. The dialogue also addresses the challenges of moving from QA to leadership, the shortcomings of end-of-cycle testing, and the benefits of adopting continuous, integrated quality assurance practices.

What If

• What if you replaced your QA silo with a culture of shared responsibility for quality, starting with a 1-week “quality ownership” sprint?

  • Move: Implement a policy where every developer is required to write and maintain automated tests for their code, with peer reviews focused on test coverage and reliability.
  • Why now: The text highlights that leadership culture (e.g., fostering shared ownership of quality) is 10100x more impactful than technical checks. This mirrors the Unity case study where dissolving the QA team led to faster development.
  • Expected upside: Reduced bottlenecks, faster feedback loops, and a more resilient codebase as developers internalize quality as a shared goal, not a QA role.

• What if you used a “sweet spot” batch size model to optimize your release cadence, starting with a 2-week minimum release cycle?

  • Move: Apply the sweet spot curve principle from the Duke Nukem Forever example to your project. Experiment with releasing smaller, more frequent updates (e.g., weekly) while monitoring technical debt and risk.
  • Why now: The text emphasizes that batching too little or too much destabilizes systems. This aligns with the systems thinking tools (e.g., statistical process control) described in Signals and Levers.
  • Expected upside: Reduced risk of large-scale failures, faster user feedback, and improved alignment with modern DevOps practices.

• What if you introduced a symbolic incentive (e.g., a pie) to address a specific cultural bottleneck in your teams workflow?

  • Move: Identify a recurring pain point (e.g., slow test execution) and create a public, low-cost incentive (e.g., a “pie” award) for the first person to reduce it by 20% in a week.
  • Why now: The text describes how a pie symbolically shifted Pivotals culture. This leverages the power of cultural incentives to drive behavioral change without formal authority.
  • Expected upside: Improved team morale, faster resolution of process bottlenecks, and a scalable cultural lever for future challenges.

Takeaway

• Prioritize Leadership Culture Over Technical Checks: Focus on building a culture where quality is systemic and shared, not reliant on individual roles. Implement policies that reinforce accountability, such as mandatory automated testing before code merges, and lead by example to shape team behavior organically.
• Incentivize Systemic Improvements with Creative Levers: Use symbolic or tangible rewards (like the “pie” example) to motivate your team or yourself to fix systemic issues, such as reducing pipeline execution times. Publicly recognize and reinforce behaviors that align with long-term quality goals.
• Apply Systems Thinking Tools to Your Workflow: Invest time in learning and applying tools like causal modeling and statistical process control to identify root causes of variability in your projects. For example, track how frequent releases (batch size) impact your development cycle and adjust cadence based on empirical data, not intuition.
• Integrate Quality into Development, Not Just Testing: Shift from end-of-cycle testing to early and continuous quality assurance. Use CI/CD pipelines to automate testing and integrate quality checks directly into your codebase, ensuring developers own testing outcomes rather than siloed testers.
• Experiment with Batch Size Optimization: Test different release frequencies (weekly, biweekly, etc.) to find your projects “sweet spot” between overhead and risk. Analyze trade-offs (e.g., technical debt vs. user feedback) to determine the optimal release cadence for your specific context.