I’ve only recently started digging deeper into the work of W. Edwards Deming, and the deeper I go, the more I find myself nodding along.
Though he made his name in manufacturing and management decades ago, I keep stumbling on his ideas in unexpected corners of my own work—particularly in software quality, and especially now, in an AI-heavy, fully remote environment.
There’s something refreshing about how clearly he speaks into problems we’re still facing:
Short-term thinking. Blame-shifting. Siloed teams. Sloppy systems. Metrics that create the illusion of control.
He may not have written a line of code in his life, but I think Deming still has a lot to say to testers, developers, and engineering teams in 2025.
What Deming Believed (and Why It Still Hits)
If you’re new to Deming, like I am, here’s a quick overview.
Deming was a statistician and systems thinker who helped transform industrial production in postwar Japan and later brought his ideas back to the U.S. He insisted that quality isn’t the result of catching defects—it’s the result of building better systems that prevent defects in the first place.
Some of his most compelling principles include:
- Drive out fear
- Cease dependence on inspection
- Break down barriers between departments
- Improve constantly and forever the system of production and service
- Institute leadership (not just supervision)
At the center of it all is this:
“A bad system will beat a good person every time.”
It’s a sobering idea—but also a freeing one. Because it shifts our focus from blame to design. From people to process. From fault-finding to system-shaping.
And honestly? That shift is just as relevant today as it was 50 years ago.
The PDSA Cycle: A Rhythm for Real Improvement
One of the most useful tools Deming left us is the PDSA cycle:
Plan → Do → Study → Act
This is not a checklist—it’s a mindset. A rhythm of inquiry and iteration that invites teams to slow down just enough to learn from what they’re building.
In software, I see PDSA show up in subtle but powerful ways:
- Plan – Define your hypothesis. What are we trying to change or improve? What assumptions are we making? What’s the risk?
- Do – Build it. Test it. Try it out. But keep your ears and eyes open.
- Study – Did it behave as expected? Did it solve the problem? What unintended consequences showed up?
- Act – Decide what to carry forward, what to revise, and what to scrap. Then start again.
This framework pairs beautifully with agile and lean development—but only when teams have the discipline to actually pause and study before reacting or shipping again.
PDSA is one way to build learning into the bones of your software process, instead of treating it like a fire drill.
Deming for Remote Teams
One of Deming’s core principles was this:
Break down barriers between departments.
In his context, that meant getting marketing, engineering, design, production, and leadership to stop working in silos and start seeing themselves as part of one system with a shared aim: delivering quality.
That’s still the work today—but the barriers have changed.
We’re not just talking about different floors in the same building anymore.
Now those “departments” might be:
- In different time zones
- Operating across cultural norms
- Reporting to different companies (contractors, vendors, offshore teams)
- Speaking different native languages
- Working on different platforms or backlogs
And instead of walls and office doors, the barriers are things like:
- Infrequent communication
- Misaligned definitions of “done”
- Slower feedback loops
- Friction in scheduling real-time collaboration
- Unspoken assumptions that don’t translate across cultural lines
The danger isn’t just miscommunication—it’s fragmentation.
Quality suffers when each group optimizes for its own deliverables instead of aligning around a shared vision of what good looks like.
Deming’s insight still applies, but it takes on new urgency:
Breaking down barriers now means building systems of intentional, structured connection across distance, time, and difference.
That might look like:
- Writing clear, async-friendly test plans and release notes
- Bringing QA into product planning as early as possible, no matter where they’re located
- Normalizing documentation not as overhead, but as a bridge between minds
- Creating shared rituals across time zones (e.g., end-of-day handoff notes)
- Building cultural awareness into the way we give and receive feedback
In other words: we have to build relational tissue into remote systems on purpose.
Because if we don’t, the barriers Deming warned about don’t just stay up—they harden into assumptions, rework, and mutual distrust.
And in the end, nobody owns the quality. Everyone’s just shipping their part.
A Few Deming-Inspired Practices I’m Trying
As someone still learning, I’m not here to teach Deming—I’m here to reflect on where his thought is taking me. Here are a few things I’ve started trying (or trying again) with his voice in mind:
- Pause to ask, “What system produced this problem?” Not just, Who made a mistake? But what pressures or gaps made that mistake easy to make or hard to notice?
- Push for clarity, not just coverage. Whether it’s test cases or team charters, I’m learning that well-defined boundaries and goals do more for quality than vague velocity ever will.
- Use AI to reduce toil, not insight. I’m experimenting with AI to handle repetitive work—but keeping the human part (judgment, pattern recognition, nuance) where it belongs.
- Revisit our metrics. Are we measuring what matters? Or what’s easiest to measure?
- Name risks out loud—even if the system seems “done.” Because being a steward of quality means being willing to disrupt the comfort of “almost good enough.”
- Try PDSA on purpose. Build time into the week—not just for building or testing, but for studying what worked and what didn’t, and making small changes accordingly.
I’m early in my journey with Deming. But already, I see how his work offers something deeper than process diagrams or test automation patterns.
It’s a mindset.
It’s a posture of care, clarity, and responsibility—for people, for systems, and for the long-term health of what we’re building together.
And I think that’s something we still need. Maybe now more than ever.
—
Beau Brown
Testing in the real world: messy, human, worth it.
Photo source: https://deming.org/w-edwards-deming-photo-gallery/
Testing Tester 
Leave a comment