Philip Jennings explores systems thinking as a holistic approach to quality, emphasizing collaboration, process alignment, and cultural values over isolated testing. She critiques narrow interpretations of “shift left” and highlights the need for systemic integration, leadership accountability, and feedback loops to sustain quality across development workflows.

Quality Talks

Quality Talks is Stu Day and Chris Henderson and different guest each episode. Released as audio and video. The official Show notes have summary, key points and time stamped chapters.

• https://qualitytalks.co.uk/podcast
• https://www.youtube.com/@QualityTalksPodcast
• https://anchor.fm/s/f6e76df4/podcast/rss

Episode Details

• Show Notes: https://www.youtube.com/watch?v=U9LGDHAdKWg
• Published: 2026-02-11T08:00:41Z
• Duration: 00:00:00
• Author: Quality Talks Podcast

Overview

The podcast examines the concept of systems thinking applied to quality in software development, highlighting a transition from isolated testing methods to a more comprehensive, integrated approach. It argues that quality is not solely the responsibility of testers but is a systemic process that involves collaboration across product, engineering, and quality roles from the earliest stages of development. This shift left strategy should focus on building a shared understanding of the problem and fostering early communication rather than just pushing testing earlier in the pipeline.

Key themes include defining quality as an interconnected system that encompasses people, workflows, tools, feedback loops, organizational culture, and leadership. The discussion emphasizes how miscommunication, unclear requirements, and misaligned metrics can undermine quality, and how continuous feedback and proper monitoring across all environments are essential to maintaining it. The podcast also warns against relying too heavily on tools without considering their context and using flawed metrics that prioritize speed over actual quality improvements.

Furthermore, it underscores the importance of creating psychological safety within teams to encourage open dialogue and collaboration. The conversation critiques practices that reduce quality to mere testing and instead advocates for aligning organizational values with metrics that truly reflect sustainable quality and effective teamwork. The overall message is that systemic quality requires a holistic view and collective responsibility across all parts of the development process.

What If

• What if you mapped your entire software development system as a systemic quality diagram?

  • Concrete Move: Create a visual flowchart of your development process, highlighting all interconnected components (people, processes, tools, feedback loops). Identify potential bottlenecks or misalignments (e.g., unclear requirements, fragmented handoffs).
  • Why Now: Your solo workflow may lack visibility into systemic flaws that compound over time (e.g., poor testability, incomplete feedback loops). A systemic view helps prioritize areas for intervention.
  • Expected Upside: Early detection of root causes (e.g., misaligned metrics, under-resourced testing), reducing rework and improving long-term reliability.

• What if you applied the “Three Amigos” collaboration method to your solo projects?

  • Concrete Move: Role-play as product, engineering, and quality roles during planning. Use example mapping to define user stories and acceptance criteria. Document assumptions and risks collaboratively.
  • Why Now: Isolation as a solo developer often leads to gaps in requirements or test coverage. This practice simulates cross-role alignment to catch issues early.
  • Expected Upside: Reduced ambiguity in specs, fewer post-development surprises, and higher-quality deliverables through structured collaboration.

• What if you implemented monitoring in lower environments (non-production) to capture systemic feedback?

  • Concrete Move: Set up lightweight monitoring tools (e.g., Prometheus, Grafana) in your development and staging environments to track performance metrics, error rates, and system behavior.
  • Why Now: Relying solely on production feedback is reactive. Monitoring in lower environments allows you to detect systemic issues (e.g., architectural flaws) before they escalate.
  • Expected Upside: Faster root-cause identification, reduced deployment risks, and data-driven adjustments to improve quality throughout the pipeline.

Takeaway

• Define the core problem upfront before coding by explicitly asking, “What problem are we solving?” and involving stakeholders (product, QA, developers) to align on requirements and avoid misaligned solutions.

• Implement early feedback loops using static analysis, code reviews, and exploratory testing in lower environments (not just production) to detect issues early and reduce rework.

• Revise metrics to prioritize quality over speed by avoiding velocity points or bug-count-based KPIs; instead, measure outcomes like system reliability, team collaboration, or customer satisfaction.

• Collaborate early and often with product, engineering, and QA teams using practices like “Three Amigos” or “Example Mapping” to co-define requirements, reduce handoffs, and integrate quality from the start.

• Map your entire process flow using techniques like Value Stream Mapping to identify bottlenecks, gaps, or inefficiencies in how work moves from idea to production, ensuring quality is built into each stage.