Quality

The Software Quality and Productivity Crisis Executives Won’t Address

Reflections From the Long View – 50 Years in Software Consulting

Over my five decades in software consulting, I’ve witnessed remarkable transformations in our industry—from punch cards to cloud computing, from mainframes to microservices to AI coding. But in the past few years, I’ve observed something deeply troubling: a significant decline in interest in—and concern over—both software quality and productivity.

At first, I dismissed it as the bias of age. Perhaps I was simply romanticising the past. So I did what any good consultant does: I looked for data to either validate or refute my impression.

What I found was worse than I imagined. The decline is not only real and measurable—it’s being actively ignored by the very people with the power to address it. We don’t have a technology crisis. We have a leadership crisis—one that may require us to embrace #NoLeadership and take matters into our own hands.

But here’s something that troubles me even more: I suspect that without a long-term perspective, folks might never have noticed this decline at all. If you’ve only been in the industry for five or ten years, the current state might seem normal. You might assume that 75% project failure rates, $1.52 trillion in technical debt, and 69% of developers losing significant time to inefficiencies is simply “how software development works.” It isn’t. It’s how software development has deteriorated under leadership neglect.

The Crisis in Numbers

Let me establish a baseline. Recent industry surveys reveal:

75% of business and IT executives expect their software projects to fail (Beta Breakers, 2024)
Only 39% of projects actually meet success criteria (Beta Breakers, 2024)
Technical debt in the US reached $1.52 trillion in 2022 (Consortium for Information & Software Quality, 2022)
69% of developers report losing 8+ hours weekly to inefficiencies—20% of their time (Atlassian, 2024)
91% of CTOs identify technical debt as their biggest challenge (STX Next, 2023)

That last statistic is crucial. Hold onto it.

What Executives Know Privately

Internal surveys—the ones shared only amongst technology leadership—paint a clear picture of awareness:

According to the STX Next Global CTO Study, 91% of CTOs cite technical debt as their biggest challenge heading into 2024 (STX Next, 2023). Not second biggest. Not a concern. Their biggest challenge.

A 2024 survey by Morning Consult and Unqork found that 80% of business and technology leaders acknowledge that technical debt causes delays, cancelled projects, and higher costs (Oliver Wyman, 2024).

McKinsey research shows that CIOs estimate technical debt amounts to 20–40% of the value of their entire technology estate, and some 30% of CIOs surveyed believe that more than 20% of their technical budget ostensibly dedicated to new products is diverted to resolving issues related to tech debt (McKinsey & Company, 2023).

Protiviti’s Global Technology Executive Survey found nearly 70% of organisations view technical debt as having a high level of impact on their ability to innovate (Protiviti, 2024).

The message is unambiguous: executives know.

What Executives Do About It

Here’s where the story becomes damning.

Industry research consistently recommends that companies allocate 15–20% of their IT budgets to proactive technical debt management. According to Oliver Wyman’s 2024 analysis, only a small minority of companies actually earmark this recommended amount (Oliver Wyman, 2024).

Instead, most organisations don’t tackle technical debt until it causes an operational meltdown. At that point, they end up allocating 30–40% of their budget to massive emergency transformation programmes—double the recommended preventive investment (Oliver Wyman, 2024). It’s like Y2K again and again.

Let me put this plainly: executives know the problem, know the solution, know the cost of prevention, yet consistently choose to wait for the crisis.

But it gets worse.

The Priority Charade

I examined CIO priority surveys from 2022–2024 across multiple sources. Here’s what consistently makes executives’ top 5 priorities:

Cybersecurity
AI/GenAI adoption
Digital transformation
Cloud migration
Cost optimisation

Here’s what’s conspicuously absent:

Software quality
Developer productivity
Technical debt remediation
Testing (QC) and QA investment

Despite 91% of CTOs citing technical debt as their biggest challenge, it doesn’t make the top five priorities in any major CIO survey from 2022–2024.

Think about that disconnect. The thing keeping CTOs awake at night doesn’t even warrant a place in their stated priorities.

The Public Deception

The gap between private knowledge and public communication is where this crosses from negligence into active deception.

I reviewed annual reports and earnings call transcripts from major technology companies for 2023–2024. Here’s what CEOs told shareholders:

Microsoft’s CEO claimed GitHub Copilot increases developer productivity by ‘up to 55%, whilst helping them stay in the flow and bringing the joy back to coding’ (Microsoft, 2023).

Google boasted that ‘more than a quarter of all new code at Google is generated by AI’ (Clouded Judgement, 2024).

Amazon, Meta, and other tech giants celebrated AI productivity gains and record revenues in their annual reports.

Now here’s what these same executives didn’t mention in their shareholder communications:

The 75% project failure expectation that their own industry acknowledges
The $1.52 trillion in technical debt
The 69% of developers losing 8+ hours weekly to inefficiencies
The fact that only 39% of projects meet success criteria
The 91% of CTOs who cite technical debt as their top concern

I read through annual shareholder letters from JPMorgan Chase, Caterpillar, Chubb, Microsoft, and SoftwareOne. Not one CEO mentioned software quality concerns, technical debt, or developer productivity issues in their 2023–2024 letters to shareholders.

Not. One.

The Productivity Paradox

This creates a particularly egregious contradiction. Microsoft trumpets 55% productivity gains from AI tools in earnings calls (Microsoft, 2023). Meanwhile, independent research shows:

69% of developers lose 8+ hours weekly to inefficiencies (Atlassian, 2024)
Only 20% of professional developers report being happy with their jobs (Stack Overflow, 2024)
Tech worker burnout jumped from 49% to 68% in just three years (Techotlist, 2024)
Developer productivity is neither well-understood nor enabled, according to Atlassian’s research (InfoWorld, 2024)

So which is it? Are developers 55% more productive, or are they losing 20% of their time to inefficiencies and burning out at record rates?

The answer: executives are measuring—and reporting—what makes their stock price rise, not what’s actually happening on the ground.

The Investment That Never Happens

Perhaps the most damning evidence is in the budgets. McKinsey’s research identifies the solution clearly: proactive technical debt management through consistent investment (McKinsey & Company, 2023). Deloitte’s 2024 Tech Trends report notes that leading companies target 15% of IT budgets for technical debt management (Deloitte, 2024).

Yet Oliver Wyman’s analysis found that only a small minority of companies actually allocate this recommended amount. The majority wait for crisis, then spend 30–40%—double the preventive cost (Oliver Wyman, 2024).

It’s the equivalent of knowing your building needs foundation repairs, having engineers tell you it will cost £100,000 now or £250,000 after collapse, and choosing to wait for the collapse.

Except we’re not talking about one building. We’re talking about the entire industry making this choice simultaneously.

The Trend Is Accelerating—And Why It Takes Decades to See It

The executive action gap isn’t static—it’s widening. Between 2020 and 2024:

2020–2021: The pandemic forced rapid digital transformation. Organisations rushed to cloud, creating massive technical debt. Software supply chain failures accelerated by 650% (Consortium for Information & Software Quality, 2022).

2021–2022: Rather than addressing the debt created, executives doubled down on speed. Cybercrime losses from software vulnerabilities rose 64% in 2020–2021, then another 42% in 2021–2022 (Consortium for Information & Software Quality, 2022).

2022–2023: 72% of organisations reported falling behind in digital transformation because of technical debt, with rushed cloud transitions cited as the primary cause (ReadyWorks, 2023).

2023–2024: Instead of addressing mounting technical debt, executives shifted focus to AI. For the first time, AI and Machine Learning vaulted to #2 in executive priorities, having not appeared in the top five the previous year (Evanta, 2024).

At each stage, executives had the data. At each stage, they chose the next shiny object over addressing fundamental problems.

Here’s what troubles me: if you started your career in 2019 or 2020, this accelerating decline is all you’ve ever known. You entered the industry during the pandemic rush, when corners were being cut at unprecedented rates. You’ve never experienced a development environment where quality was genuinely prioritised, where technical debt was proactively managed, where 75% project failure wasn’t expected.

You might think this is normal.

It’s not. In the 1990s and 2000s, whilst projects certainly failed and technical debt existed, there was a prevailing culture that quality mattered. Teams pushed back on unreasonable deadlines. Architects had authority to insist on sound technical decisions. “Technical debt” was something you reluctantly accumulated and felt obligated to address, not something you casually accepted as inevitable.

The shift has been gradual enough that it’s nearly invisible year-to-year. But viewed across decades, it’s stark. We’ve normalised dysfunction.

This is why long-term perspective matters. Trends that seem acceptable in isolation become alarming in context. A developer who’s experienced 15 different organisations over 30 years can see patterns that someone at their first or second company cannot. The boiling frog doesn’t notice the temperature rising. Those of us who remember when the water was cooler do.

The CrowdStrike Crystallisation

On 19 July 2024, a single CrowdStrike update crashed 8.5 million Windows machines globally, grounding flights, disabling emergency services, and causing an estimated $10 billion in damage. The root cause? A missing array bounds check—Computer Science 101 error handling that nobody implemented (Trendy Tech Tribe, 2025).

This wasn’t sophisticated. This was basic software craftsmanship that failed at every level of the deployment pipeline.

Three months later, in October 2024 earnings calls, did executives mention this as a wake-up call about software quality? Did they announce new quality initiatives?

No. They continued celebrating AI productivity gains whilst CTOs privately listed technical debt as their #1 concern.

What struck me most about the CrowdStrike incident wasn’t that it happened—any system can have bugs. What struck me was the industry’s reaction: brief panic, followed by… nothing. No industry-wide soul-searching. No renewed focus on basic software quality. Just a continuation of the same practices that led to it.

Twenty years ago, an incident of this magnitude would have triggered genuine introspection. Now? It’s Tuesday.

That normalisation of failure is what long-term perspective reveals. It’s not that we’ve stopped noticing problems—it’s that we’ve stopped being concerned about them.

What This Reveals About Executive Leadership

After 50 years in this industry, I can state with confidence: we are witnessing a systematic failure of executive integrity.

Executives aren’t ignorant. They have the data. They commission the surveys. They attend the conferences where CTOs present their concerns. They know that:

91% of CTOs cite technical debt as the biggest challenge
75% of projects are expected to fail
69% of developers lose significant time to inefficiencies
Only 39% of projects meet success criteria
The recommended 15–20% investment in technical debt management yields better long-term returns than crisis spending

Yet they choose:

Not to allocate recommended budgets for technical debt management
Not to make quality a strategic priority despite CTOs’ and developers’ concerns
Not to mention these challenges in public communications to shareholders
To celebrate AI productivity gains whilst developers report record inefficiency
To focus on the next hype cycle (AI) rather than address fundamental problems

This isn’t a failure of knowledge. It looks to me like a failure of courage and integrity. A failure of the very concept of leadership.

Why Executives Choose Inaction

The calculus is simple and cynical:

Short-term wins are rewarded. Announcing AI adoption, digital transformation, and cost cutting drives stock prices up. Announcing a 15% budget allocation to technical debt management does not.

The crisis is slow. Technical debt doesn’t cause immediate, visible collapse. It degrades gradually. By the time it causes catastrophic failure, the executive who created it has often moved on. The average tenure of a Fortune 500 CEO is less than 8 years (and median in 2022 was 4.8 years). Why invest in quality improvements that won’t pay dividends until you’re long gone?

Metrics are gamed. Report AI productivity gains whilst ignoring developer efficiency losses. Celebrate revenue growth whilst hiding project failure rates. Show cost optimisation whilst deferring necessary maintenance.

Accountability is absent. No executive has faced consequences for the $1.52 trillion in technical debt. No CEO has been fired for the 75% project failure rate. No board has demanded answers for why only 39% of projects meet success criteria.

Historical memory has faded. Here’s where long-term perspective becomes crucial: many current executives have never worked in an environment where quality was genuinely prioritised. They entered leadership during the “move fast and break things” era. They’ve optimised their entire careers for velocity over sustainability. They literally don’t know what they’re missing. (See also: the Software Crisis – since 1968)

The system rewards those who optimise for optics over outcomes—and increasingly, it’s selecting for leaders who’ve never experienced anything different.

The Cost of This Failure

Whilst executives optimise for quarterly earnings, the real costs accumulate:

Financial: The US alone spends $2.41 trillion annually on poor software quality, with $1.52 trillion in technical debt (Consortium for Information & Software Quality, 2022). By waiting for crisis instead of investing preventively, companies spend double the recommended amount.

Human: 83% of developers experience burnout (Haystack Analytics, 2021). For the first time ever, senior developers report lower job satisfaction than juniors (Stack Overflow, 2024). The industry is haemorrhaging experienced talent—the very people who remember when things were different and might push for change.

Innovation: With 30% of IT budgets consumed by technical debt management and 20% of developer time lost to inefficiencies, there’s little capacity left for actual innovation.

Security: Software supply chain failures increased 650% between 2020 and 2021 (Consortium for Information & Software Quality, 2022). Cybercrime losses continue accelerating. Each shortcut creates new vulnerabilities.

Trust: When executives celebrate productivity gains whilst developers report record inefficiency, when they commission CTO surveys showing 91% cite technical debt as their top concern yet never mention it to shareholders, they erode trust throughout the organisation.

Institutional Knowledge: Perhaps most insidiously, as experienced developers get sick of the eternal indifference and leave, we’re losing the people who remember that it didn’t use to be this way. Each generation of new developers enters an environment slightly worse than the one before, with no reference point for what’s been lost.

The Case for #NoLeadership

Here’s what five decades in this industry has taught me: waiting for executive leadership to fix this crisis is futile. They know what needs to be done. They choose not to do it.

Perhaps it’s time we stop waiting for them.

#NoLeadership isn’t a complaint—it’s a philosophy. It’s the recognition that real change in software quality and productivity won’t come from boardrooms optimising for quarterly earnings. It will come from engineers, developers, and teams who decide to take ownership themselves.

But there’s a challenge here, especially for those without long-term perspective: if you’ve never experienced a development environment where quality was prioritised, how do you know what to fight for? If you entered the industry in the past 5-10 years, you might genuinely believe that constant firefighting, accumulating technical debt, and 75% project failure rates are just “how software works.”

They’re not. And #NoLeadership starts with understanding that the current state isn’t inevitable—it’s a choice we’re collectively making. A choice we can unmake.

Consider what happens when we embrace #NoLeadership:

Teams set their own quality standards. Don’t wait for executives to prioritise quality. Build it into your definition of done. Make technical debt visible on every sprint board. Refuse to call something “done” that you wouldn’t be proud to support.

Engineers allocate their own time. If leadership won’t dedicate 15% of budget to technical debt, developers can dedicate 15% of their sprint capacity. One day per sprint. Non-negotiable. Not asking permission—just doing it.

Quality becomes a team responsibility. Stop escalating quality decisions upward. If your team knows a codebase needs refactoring, refactor it. If tests are missing, write them. If documentation is lacking, create it. Own your craft.

Transparency replaces theatre. Track real metrics: hours lost to technical debt, actual bug rates, time spent on rework, developer satisfaction. Make them visible. Not to shame anyone, but to make the invisible visible.

Peers hold each other accountable. Code reviews become about long-term maintainability, not just immediate functionality. Pull requests that create obvious technical debt get challenged. Not by managers—by peers who know they’ll inherit the mess.

We share stories of how it used to be—and could be again. Those of us with long-term perspective have a responsibility to tell younger developers that the current dysfunction isn’t normal. To share what sustainable software development looks like. To paint a picture of what they’re entitled to demand.

This isn’t anarchism. It’s professionalism. It’s recognising that waiting for executives to prioritise what they’ve demonstrated they won’t prioritise is a losing strategy.

What #NoLeadership Looks Like in Practice

I’ve seen pockets of this emerging organically:

The team that implemented “Tech Debt Tuesdays”—dedicating every Tuesday to addressing technical debt, regardless of what management priorities were set. Their velocity appeared to drop 20%. Their actual productivity—measured in sustainable output and reduced rework—increased significantly.

The engineers who created a “Technical Debt Registry”—documenting every shortcut, every deferred refactoring, every known issue. Made it public within the organisation. No permission asked. Just transparency about what was really happening.

The developer who started tracking “Time to Real Done”—measuring not when a feature shipped, but when it was actually stable, tested, documented, and maintainable. Shared the data widely. Made it impossible to ignore the gap between “shipped” and “done.”

The teams adopting “Two-Track Development”—running parallel tracks for new features and quality improvement. Not asking whether they could dedicate time to quality. Just doing it as part of their professional responsibility.

The teams embracing the Antimatter Principle—attending to folks’ needs as a matter of course.

The senior developers who mentor juniors on what sustainable development looks like—not by lamenting “the old days,” but by teaching practices and standards that newer developers never learned because they entered an industry already in crisis.

These aren’t acts of rebellion. They’re acts of practitioners’ integrity. They’re what happens when craftspeople decide that waiting for permission to do good work is itself unprofessional.

And critically, they’re how we preserve and transmit knowledge of what sustainable software development looks like—creating reference points for those who’ve never experienced it.

The Limits and Risks

Let me be clear: #NoLeadership isn’t a panacea, and it comes with real constraints.

You can’t allocate budget you don’t control. Teams can manage their own time, but they can’t approve capital expenditure for infrastructure improvements or hire additional staff.

You may face consequences. Some organisations will punish teams who prioritise quality over velocity metrics, even when that quality improves long-term outcomes. Career risks are real.

Coordination remains necessary. #NoLeadership works for team-level quality decisions. System-wide architectural changes still require coordination that often needs executive sponsorship.

Not everyone will join you. Some teams will continue optimising for the metrics management rewards. You may end up maintaining higher quality in isolation whilst surrounded by deteriorating systems.

Without historical context, it’s hard to know what’s worth fighting for. If you’ve never seen sustainable development practices in action, how do you know which battles matter? This is where mentorship and knowledge sharing become crucial.

These limitations matter. #NoLeadership can’t replace executive action—it can only compensate for executive inaction within the sphere teams actually control.

But here’s what it can do: it can prevent your team’s work from contributing to the crisis. It can create islands of quality in seas of technical debt. It can demonstrate that another way is possible. And it can preserve your own professional integrity whilst the industry around you optimises for quarterly earnings.

Most importantly, it can create reference points. When a junior developer experiences your team’s practices—where quality matters, where technical debt is managed, where 75% failure isn’t expected—they learn what’s possible. They gain perspective that might take decades to acquire otherwise. They become carriers of institutional knowledge about what sustainable software development looks like.

That’s how cultures change: one team at a time, creating examples that others can point to and say, “That’s what we might be doing.”

A Challenge to the Industry

To executives reading this: the data is unambiguous. You know what needs to be done. The question is whether you’ll do it, or whether your teams will be forced to work around your inaction.

To CTOs and technology leaders: if 91% of you cite technical debt as your biggest challenge, why doesn’t it appear in executive priorities? Stop keeping your concerns private. Make them public. Make them impossible to ignore. Risk it.

To senior developers and engineers with long-term perspective: You have a special responsibility. Share your experience. Mentor those who’ve never known anything but crisis mode. Paint a picture of what sustainable development looks like. Your historical perspective is valuable—use it to help others understand that the current state isn’t inevitable.

To developers and engineers: you don’t need permission to do good work. You need the courage to prioritise it even when incentives push you toward shortcuts. #NoLeadership a.k.a. #Fellowship means taking ownership of quality within your sphere of control.

To those new to the industry: If you’ve entered software development in the past 5-10 years, I invite you to consider something crucial: the environment you’re in—the constant firefighting, the technical debt, the 75% failure rates—this isn’t “just how software development works.” It’s how software development has deteriorated. Seek out the older developers, the ones who’ve been doing this for decades. Ask them how things used to be. Learn what you’re entitled to demand.

To teams: you can start today. Dedicate 15% of your sprint to quality. Make technical debt visible. Track real metrics. Hold each other accountable. Don’t wait for executive prioritisation that isn’t coming.

The Path Forward

After 50 years, I’ve learned this: sustainable software quality requires both executive commitment AND professional autonomy. Ideally, we’d have both.

But if we must choose between waiting for executive action that isn’t coming and taking professional responsibility for the work we control, I choose the latter.

#NoLeadership is about recognising when waiting for executive direction means accepting executive dysfunction. It’s about developer communities deciding that their craft matters more than their executives’ quarterly earnings optimisation.

The data shows executives know what needs to be done. They choose not to do it. Perhaps it’s time we stop waiting for them to change their minds and start changing what we can control.

Every sprint in which you dedicate time to quality is a choice. Every pull request you review for maintainability is a choice. Every piece of technical debt you document is a choice. Every standard you refuse to compromise is a choice. Every story you share about how development used to be—and could be again—is a choice.

Make better choices. Don’t wait for permission.

The industry won’t be fixed by executive leadership that’s demonstrated it won’t lead on quality. It will be fixed by teams who decide that professional integrity matters more than executive approval. By experienced developers who share their perspective with those who’ve never known anything different. By practitioners who refuse to accept that the current dysfunction is inevitable.

That’s #NoLeadership. Not a lament—a commitment to integrity.

And for those of us with long-term perspective, it’s also a responsibility: to notice the trends others can’t see, to remember what’s been lost, and to fight to restore what made this profession worth pursuing in the first place.

Are you practising #NoLeadership in your work? What quality standards have you set for yourself regardless of executive priorities? And if you’ve been in the industry long enough to see the trends—what changes have you noticed? Share your experiences in the comments.

The Continuous Improvement Delusion

September 4, 2025

Article, Crosby, Improvement, Quality

1 Comment

The Continuous Improvement Delusion

Philip Crosby’s Case Against Kaizen Culture

You may not like Phil Crosby’s perspective on continuous improvement. You may have even never heard of him. But this influential quality management expert who revolutionised manufacturing with his “Zero Defects” philosophy had something provocative to say about our modern obsession with Kaizen—the Japanese word for continuous improvement (Imai, 1986).

Whilst the business world embraced the delusion of incremental optimisation, Crosby saw something fundamentally broken in our approach to getting better.

Crosby criticized gradual improvement (like Kaizen) in favor of immediate, complete fixes. His position was that incremental improvement was insufficient.

His critique wasn’t just contrarian—it was mathematically and economically devastating to the entire continuous improvement industrial complex. And decades later, his warnings about optimisation theatre have proven prophetic.

Organisational Learned Helplessness Dressed Up as Diligence

Crosby’s primary objection to continuous improvement was practical: instead of incrementally improving flawed processes, focus on do things right the first time. Why accept that our processes are broken and then spend endless energy making them slightly less broken?

The continuous improvement model starts with a defeatist assumption—that defects are inevitable, that error is natural, and that our job is to gradually reduce the rate of failure. Crosby saw this as organisational learned helplessness dressed up as diligence.

Just as learned helplessness teaches individuals that they have no control over their circumstances, continuous improvement teaches organisations that they have no power to actually solve their problems—only to marginally reduce their severity over time. We’ve built elaborate approaches around the core belief that we’re powerless to fix things properly.

This isn’t common sense; it’s institutionalised resignation with metrics attached.

Crosby saw statistical quality control and e.g. the ISO 9001:2015 standard as contributing to this through acceptable quality levels—a concept that allows a certain number of acceptable defects and reinforces the attitude that mistakes are inevitable.

The Economics of Actually Fixing Things

Whilst continuous improvement focuses on elegant frameworks, cadres of quality workers, and extensive metrics, Crosby cut straight to what matters: money. He understood something that the continuous improvement culture has forgotten: every day you don’t fix a known problem, that problem costs you money. Real money. Calculable money.

His “Price of Nonconformance” wasn’t just theory—his programmes netted manufacturing cost-of-quality reductions from $30 million in 1968 to $530 million in 1976 at ITT Corporation. Something like 20% to 25% of revenues could be saved by simply doing things right the first time instead of continuously improving broken processes.

Caution: Cost of Quality: Financial Sophistication Can Fail Too

The continuous improvement model, by contrast, creates expensive improvement theatre. We measure defect rates, track improvement metrics, run kaizen events, and celebrate marginal gains whilst the actual problems—the ones everyone knows about—continue bleeding money every single day.

Zero Defects vs. The Improvement Treadmill

Crosby’s ZeeDee philosophy stood in stark contrast to the widespread mantra of “kaizen”—the relentless pursuit of small, incremental optimisations. His approach was brutally simple: identify what’s wrong, fix it completely (to meet requirements), and do it right from that point forward.

Not “reduce defects by 5% this quarter.” Not “implement a continuous improvement culture.” Simply: Zero. Defects.

This wasn’t perfectionism—it was pragmatism. Most quality problems aren’t complex engineering challenges requiring months of analysis. They’re obvious failures that everyone knows about but nobody fixes because we’re too busy optimising our approach to optimisation.

The Prevention vs. Detection Fallacy

Crosby distinguished between two fundamentally different approaches to quality:

Detection Approach (Continuous Improvement): Find defects as early as possible and continuously improve the detection and correction process. Build better inspection systems. Implement more sophisticated monitoring. Celebrate reducing defect rates.

Prevention Approach (Zero Defects): Build systems that eliminate problems at their source. Stop the defects from happening in the first place.Phil Crosby advocated celebrating Zero Defects achievements and error-free performance.

Continuous improvement puts all the energy into getting better at handling problems rather than eliminating them. We become incredibly sophisticated at damage control whilst the root causes keep generating new damage.

The Management Commitment Problem

“Quality starts to go to hell when you delegate it. So when I say commitment, I mean CEOs in there working and doing things, not just saying, ‘Yes, I bless this thing, and here’s some money to do it.'”

~ Phil Crosby

Continuous improvement programmes are perfect for delegation. They create committees, frameworks, and ongoing initiatives that make middle management look extremely busy whilst allowing executives to avoid the hard work of actually fixing fundamental problems.

Crosby’s zero defects approach, by contrast, requires executives to identify specific problems, commit resources to fix them completely, and take direct responsibility for results. “It doesn’t work that way. It’s like parenting. You can’t delegate the cuddle and the evening prayer; you have to do that yourself.”

Why We Choose Comfortable Failure

The continuous improvement delusion persists because it’s psychologically comfortable. It allows us to feel good about making progress without the scary commitment of actually solving problems. We can always point to our improvement trajectory, our kaizen events, our metrics.

Crosby’s approach is terrifying because it demands binary outcomes. Either the problem is fixed or it isn’t. Either you meet requirements or you don’t. Either you have zero defects or you’re failing.

This binary approach functions as a perfect litmus test for leadership commitment. There’s no middle ground where executives can sound supportive whilst hedging their bets. As Crosby observed: “All you need is for the CEO to say, ‘Quality is the most important thing we have around here, but don’t forget we still have to make a buck. Don’t get carried away with this thing [the zero defects initiative].’ Say that, and it’s all gone [the entire quality programme is destroyed].”

That single mixed message—quality matters, but not more than short-term profits—destroys any possibility of zero defects. Everyone immediately understands that when push comes to shove, defects are acceptable if fixing them costs money or takes time.

The Modern Vindication

Today’s optimisation theatre—our productivity apps, improvement frameworks, and continuous improvement cultures—perfectly validates Crosby’s critique. We’ve created an entire industry around the performance of getting better whilst actual performance often remains unchanged or gets worse.

We track habits without changing behaviour. We measure metrics without improving outcomes. We run improvement initiatives whilst the fundamental problems everyone knows about continue costing money, frustrating customers, and burning out employees.

A Different Path Forward

Crosby’s alternative isn’t to abandon improvement—it’s to abandon the delusion of gradual improvement and commit to actual solutions:

Identify Real Problems: Not opportunities for optimisation, but actual failures that cost money and frustrate people.

Fix Them Completely: Don’t improve them incrementally. Fix them immediately to zero defects—to the point where they meet requirements consistently.

Do It Right From Then On: Build prevention into the process so the problem doesn’t recur.

Measure Real Costs: Track the price of nonconformance in actual dollars, not abstract improvement metrics.

Demand Executive Commitment: Leadership that personally owns problem resolution, not just improvement initiatives.

The Uncomfortable Truth

Perhaps the most uncomfortable truth about Crosby’s critique is how obviously correct it is. Most of our “improvement opportunities” are actually known problems that we choose not to fix completely because fixing them would require difficult decisions, uncomfortable conversations, and significant resource commitments.

It’s easier to run a continuous improvement initiative than to fire the incompetent manager. It’s easier to optimise the customer service process than to fix the product defect that creates most customer service calls. It’s easier to improve the hiring process than to address why good people keep leaving.

Continuous improvement becomes organisational avoidance behaviour—a sophisticated way of doing everything except the hard work of actually solving problems.

Crosby’s legacy isn’t just about quality management—it’s about choosing the courage of decisive action over the comfort of perpetual improvement. In a world addicted to optimisation theatre, perhaps the most radical act is to simply fix what’s broken and do it right the first time.

Stop Optimising. Start Fixing.

May 24, 2025

Organisational effectiveness, Antimatter principle, Quality, Article, Quintessence, Alien tech, Crosby, Actionable Insights

Leave a comment

Stop Optimising. Start Fixing.

How continuous improvement is a chimera.

We’ve been sold a huge lie about continuous improvement. The business world is obsessed with methodologies, frameworks, and gradual optimisation cycles. Kaizen. Six Sigma. Agile retrospectives. All promising that slow, methodical tweaks will eventually solve our problems.

But what if the problem isn’t that we’re improving too slowly? What if the problem is that we’re not actually fixing anything at all?

The Continuous Improvement Trap

Continuous improvement sounds reasonable. It feels responsible. It makes us feel like we’re being thoughtful and strategic. We hold meetings about improvement opportunities. We create action items. We measure progress with metrics and charts.

Meanwhile, the thing that’s broken stays broken.

Think about your own workplace. How many ‘improvement initiatives’ are currently underway? How many problems have been identified, analysed, and placed into some formal improvement process? And how many of those problems could have been solved in the time it took to create the improvement plan?

The Power of Just Fixing It

There’s something liberating about abandoning the improvement theatre and just fixing problems when you see them. No process. No committee. No quarterly review cycle. Just:

‘This is broken. I’m going to fix it right now.’

This isn’t about being reckless or impulsive. It’s about recognising that many problems don’t need elaborate solutions—they need simple, direct action. The customer complaint process that takes three days when it could take three minutes. The reporting system that requires seventeen manual steps when five would do. The meeting that could be an email (yes, that one).

When Fix-It-Now Actually Works

The fix-it-now approach works best when:

The problem is clear and contained. If you can explain the problem in one sentence and the solution won’t create three new problems, just fix it.

The cost of the fix is lower than the cost of the process. If fixing the problem takes two hours but the ‘proper process’ takes two weeks of meetings, skip the meetings.

You have the authority and capability. Don’t break things you can’t fix or step on toes you can’t afford to step on. But within your sphere of influence, act decisively.

The downside is manageable. Some problems are worth fixing to requirements right now rather than over-engineering them six months from now. Don’t confuse quality (meeting requirements) with gold-plating (exceeding requirements unnecessarily).

The Resistance You’ll Face

People will tell you this approach is dangerous. That you need stakeholder buy-in. That you should follow the established process. That you need to consider all the implications.

Sometimes they’re right. But often, they’re just protecting a system that values process and busywork over results. They’d rather have a perfectly documented failure than an undocumented success.

Phil Crosby Had It Right All Along

Back in the 1980s, quality guru Phil Crosby made a radical statement:

‘Quality is free.’

Not because it doesn’t cost anything to achieve, but because the cost of poor quality—the rework, the waste, the customer defections—always exceeds the cost of doing it right the first time.

Crosby’s insight cuts straight through our modern improvement theatre. He wasn’t interested in elegant frameworks or sophisticated metrics. His message was brutally simple: identify what’s wrong, fix it completely (to meet requirements), and do it right from that point forward. Zero defects! Not ‘acceptable quality levels’ or ‘continuous reduction in defect rates’—zero.

This wasn’t about perfectionism. It was about recognising that most quality problems aren’t complex engineering challenges requiring months of analysis. They’re obvious failures that everyone knows about but nobody fixes because we’re too busy optimising our optimisation processes.

The Cost of Broken Things

Crosby understood something that our continuous improvement culture has forgotten: every day you don’t fix a known problem, that problem costs you money. Real money. Calculable money.

Think about the broken approval process in your organisation. The one that takes two weeks when it only need take two hours. Every time someone waits for that approval, you’re paying for their idle time. Every delayed project compounds the cost. Every frustrated customer represents lost revenue.

Now think about how much you’ve spent analysing that process. The consultant fees. The workshop hours. The project management overhead. The steering committee meetings.

Crosby would have asked a simple question:

‘How much would it cost to just fix the damn thing?’

The Four Absolutes vs. Endless Improvement

Crosby’s quality framework consisted of his famous ‘Four Absolutes’:

quality is conformance to requirements
the system is prevention (not appraisal)
the performance standard is zero defects
The measurement of quality is the price of nonconformance (PONC), NOT indices

Notice what’s missing? Continuous improvement committees. Process optimisation cycles. Stakeholder alignment sessions.

His insight was that most organisations spend their energy on detection—measuring problems, tracking problems, reporting on problems. Some spend money on correction—fixing problems after they’ve caused damage. Almost none focus on prevention—building systems that don’t create problems in the first place.

But here’s where Crosby’s thinking was revolutionary: he realised that the fastest way to prevent future problems is to fix current problems completely and immediately. Not partially. Not ‘phase one of a three-phase improvement initiative.’ Completely. (And as much as current knowledge allows.)

The Fifth Absolute: Purpose Over Process

Years after Crosby’s original work, his associates recognised something crucial was missing. You could follow all four absolutes religiously and still fail. Why? Because you might be doing quality work without a clear purpose.

The Fifth Absolute addresses this gap:

‘The purpose of quality is customer success, not customer satisfaction.’

But let’s be honest about who we’re really talking about when we say ‘customers.’ We’re talking about the Folks That Matter™—the people whose success directly impacts whether your organisation thrives or dies. Sometimes that’s paying customers. Sometimes it’s your team members trying to get work done. Sometimes it’s the regulatory body that can shut you down. Sometimes it’s the board that controls your budget.

The Folks That Matter™ aren’t just anyone who uses your output. They’re the people whose success or failure has real consequences for your organisation. And here’s the crucial insight: when the Folks That Matter™ are struggling because something’s broken, every day you spend in improvement committees instead of fixing it is a day you’re actively damaging the relationships that keep your organisation alive.

This distinction is vital for the fix-it-now philosophy. Customer satisfaction is often temporary—a polite response to adequate service. Success for the Folks That Matter™ means your work actually helps them achieve their goals in ways that matter. It’s the difference between a customer saying ‘thanks’ and them saying ‘this changed everything for us.’

When you’re deciding whether to fix something immediately or put it through an improvement process, ask yourself: will this fix contribute to genuine success for the Folks That Matter™, or are we just trying to avoid complaints? If it’s the former, fix it now. Don’t let process bureaucracy delay real value creation for the people whose success determines yours.

The ‘Do It Right the First Time’ Philosophy

‘Do it right the first time’ sounds like perfectionism, but it’s actually the opposite. It’s pragmatism. It’s recognition that the cost of fixing something properly right now is almost always less than the cost of living with it broken plus eventually fixing it later plus dealing with all the problems the broken thing created in the meantime.

This applies beyond manufacturing. That clunky onboarding process that confuses new hires? Fix it now, completely, once. That reporting system that everyone complains about? Don’t incrementally improve it over eighteen months—replace it with something that actually works.

The Vaccination Approach to Problems

Crosby thought about quality problems like a doctor thinks about disease. You don’t manage disease with continuous small interventions. You prevent it with vaccination, and when it occurs, you treat it aggressively until it’s gone.

Most organisations treat problems like chronic conditions to be managed rather than acute conditions to be cured. They create dashboards to track the problem. They assign someone to ‘own’ the problem. They schedule quarterly reviews of the problem’s status.

Meanwhile, the problem keeps causing damage.

Every. Single. Day.

Implementation Without Ceremony

Crosby believed in measurement, but not measurement for its own sake. His famous ‘cost of quality’ calculations weren’t about creating pretty charts—they were about making the business case for immediate action.

When you can show that a broken process costs £50,000 per month and fixing it costs £10,000 once, the conversation changes. No more debates about resource allocation or competing priorities. No more requests for additional analysis. Just: ‘Fix it now, because we’re literally burning money every day we don’t.’

The Real Quality Movement

The tragedy of the quality movement is that it got co-opted by people who love process more than results. Crosby’s simple, direct approach—identify the problem, calculate the cost, fix it completely—got buried under layers of methodology and certification programmes.

But the core insight remains: quality isn’t about continuous improvement. It’s about fixing what’s broken and then not breaking it again. It’s about prevention, not optimisation. It’s about doing things right the first time instead of doing them wrong continuously but with slightly better metrics each quarter.

Building the Fix-It Imperative

Organisations that embrace the Crosby approach don’t just solve problems faster—they attract people who like solving problems. They create cultures where seeing a problem and not fixing it feels uncomfortable. Where the default response to ‘this is broken’ is ‘let’s fix it now’ rather than ‘let’s form a working group.’

Building a Fix-It Culture

This means hiring people who see problems as puzzles to solve, not reports to file. It means creating environments where people who fix things without permission are celebrated rather than disciplined. It means celebrating the person who eliminated a stupid process as much as the person who optimised a complex one.

The Real Continuous Improvement

Here’s the paradox: when you fix problems immediately, you actually improve continuously. Each quick fix teaches you something about your systems. Each direct action builds your capability to handle bigger problems. Each bypassed bureaucratic process shows you which processes actually add value.

Real continuous improvement isn’t about following a methodology. It’s about building an organisation full of people who see a problem and think, ‘I can fix this right now.’

Phil Crosby knew that quality is free, but only if you’re willing to pay the upfront cost of doing things right. Everything else is just expensive theatre.

So the next time you spot something that’s obviously broken, ask yourself: Does this need a process, or does it just need to be fixed?

Then fix it.

Your future self—and everyone who won’t have to deal with that broken thing anymore—will thank you.

Meaning, Quality, and Joy: A Conversation

April 25, 2025

Article, Conversations, Joy, Marshall Model, Meaning, Purpose, Quality

Leave a comment

Meaning, Quality, and Joy: A Conversation

With Viktor Frankl and Ed Deming

An imagined conversation, moderated by Stephen Fry

Setting: A cozy London club room with leather armchairs, circa 1985. The rain patters softly against tall windows as three men share whisky and ideas.

Stephen Fry: settling into his chair with obvious delight Gentlemen, what an absolute privilege to host this little tête-à-tête. Dr. Deming, your work revolutionising management has traveled far beyond factory floors. And Dr. Frankl, your insights from the darkest human experiences have illuminated countless lives. I’m curious—have you noticed the fascinating parallels in your thinking?

Deming: adjusts glasses Call me Ed, please. And yes, I’ve read Man’s Search for Meaning twice. Remarkable book. Viktor’s experiences make my battles with corporate America seem rather trivial by comparison.

Frankl: with a gentle smile Nothing trivial about transforming how humans work together, Ed. And please, such formality isn’t necessary between us. I’ve followed your impact in Japan with great interest. Different arenas, but we’re both concerned with what makes humans thrive, no?

Stephen: leaning forward enthusiastically That’s precisely it! One of you worked with people making cars and calculators, the other with people piecing back together shattered lives. Yet you’ve both concluded that meaning is… well, rather bloody important!

Deming: chuckling Put that way, it does sound obvious. But good lord, you should see how many companies still don’t get it. They think workers are just pairs of hands. Pay them, push them, measure them to death—then wonder why quality suffers.

Frankl: nodding The same reductionism appears in psychology. Many theories treat humans as merely responding to stimuli or seeking pleasure. But in the camps—

He pauses, takes a sip of whisky

Even there, I saw that meaning was more fundamental than comfort or even survival. Those who had a ‘why’ to live could bear almost any ‘how.’

Stephen: softly Viktor, if I may ask… how did you maintain your own ‘why’ in such circumstances?

Frankl: thoughtfully I had my manuscript—my life’s work—confiscated upon arrival at Auschwitz. So I began reconstructing it mentally. I would give lectures in my mind, imagining I was teaching these ideas someday. This gave purpose to my suffering. And I thought of my wife, not knowing if she was alive…

Deming: visibly moved And this is what I try to explain to executives who think bonuses and threats are the only motivators! Humans need purpose. When a worker can’t take pride in craftsmanship because the system rushes them or provides poor materials—it’s a kind of existential insult.

Stephen: gesturing with his glass It seems you both challenge the mechanistic view of humans. Viktor through therapy, Ed through, well, what would you call your approach?

Deming: with characteristic directness Systems thinking. Most problems in organizations aren’t people problems—they’re system problems. When good people work in bad systems, the systems win every time. And most systems are perfectly designed to rob people of joy in their work.

Frankl: leaning forward That phrase—”joy in work”—it’s quite profound. In therapeutic terms, joy emerges naturally when activity connects to meaning. You can’t command joy any more than you can command love.

Stephen: mischievously Unlike me, who can command attention simply by dropping a well-placed literary reference! all laugh But seriously, both your approaches seem to push against the tide of treating humans as mere cogs or stimulus-response machines.

Deming: emphatically Exactly! My Point 12: “Remove barriers that rob people of pride in workmanship.” When someone truly cares about what they’re making—whether it’s a car door or a customer experience—they’ll solve problems you never even knew existed.

Frankl: In the camps, I observed this too, albeit in grimmer form. Even there, some prisoners would share their bread with others who were weaker. Such actions transcended mere survival instinct. They reflected choice—the final human freedom to choose one’s attitude even when everything else is taken away.

Stephen: thoughtfully You both speak of freedom within constraints. Viktor found freedom of attitude even in a concentration camp. Ed, you speak of freedom within systems—

Deming: interrupting with enthusiasm Yes! But I also insist we can redesign those systems! That’s where Viktor’s personal approach meets my structural one. We can choose to avoid having workers heroically overcome bad management to find meaning. We can choose to build systems that nurture rather than crush the human spirit.

Frankl: nodding vigorously Absolutely correct. My emphasis on individual attitude never meant accepting oppressive systems. Quite the opposite! Understanding human needs for meaning can inform how we design all institutions—workplaces, schools, governments.

Stephen: refilling glasses A toast, then! To redesigning our world around what actually makes us human.

They raise their glasses

Stephen: Ed, tell us—what first showed you that joy in work matters so much?

Deming: reminiscing As a young man, I worked summers on my grandfather’s farm in Wyoming. Hard work, mind you, but satisfying. You planted, you tended, you harvested—you saw the whole cycle and its purpose. Then I entered modern industry and saw how specialisation and management approaches had fractured that natural satisfaction.

Stephen: And then Japan happened! You practically became a national hero there.

Deming: modestly They were ready to listen. After the war, they needed to rebuild everything. No time for ego or tradition—just what works. They understood that quality isn’t inspected in; it’s designed in—including designing how people work together.

Stephen: turning And Viktor, before the unimaginable happened, you were already developing your ideas about meaning?

Frankl: nodding In my practice in Vienna, I noticed what I called “Sunday neurosis”—a kind of emptiness people felt when work stopped and they faced themselves. Even before the war, hunger for meaning was the underlying condition of many of my patients. The camps then became a terrible confirmation of my theory—when everything is stripped away, meaning remains our essential need.

Deming: thoughtfully Sunday neurosis… I’ve seen something similar in retirement. People who defined themselves by work suddenly feel useless. Organisations that push people to retire at 65, as if creativity has an expiration date!

Stephen: animatedly Both of you seem to challenge this artificial separation between work life and “real” life! As if we should expect misery at work but find meaning elsewhere.

Frankl: passionately Exactly! Life does not compartmentalize so neatly. The question of meaning pervades all domains of existence.

Deming: And quality too! laughs Though I suspect Viktor wouldn’t phrase it quite that way.

Frankl: smiling Perhaps not, but we’re talking about the same human reality. Quality of product, quality of experience, quality of life—these are not separate concerns.

Stephen: eyes twinkling I find it delicious that a statistician and a psychiatrist find such common ground. One of you counting defects per thousand, the other plumbing the depths of the human soul—yet arriving at such similar conclusions!

Deming: chuckling Numbers and systems exist to serve humans, not the other way around. When organisations ignore this, they create misery and mediocrity in equal measure.

Frankl: In the end, both our approaches recognise that meaning isn’t a luxury—it’s as essential as air. Whether in therapy or factories, human dignity must be honored.

Stephen: raising his glass again To human dignity then—in work, in suffering, and in joy. And to two remarkable men who’ve helped us understand it better.

The conversation continues into the night, ranging from statistical process control to existential philosophy, punctuated by Stephen’s witty asides and literary references, three brilliant minds finding unexpected harmony in their diverse experiences.

The Relevance of Experience: Insights from Five Decades in Software Development

October 8, 2024

Alien tech, Antimatter principle, Article, Attendants, Business, Caring, Collaboration, Community, Conversations, Dialogue, Fellowship, Learning, Motivation, Product development, Productivity, Quality, Quintessence, Software development

Leave a comment

The Relevance of Experience: Insights from Five Decades in Software Development

The Perennial Question: Why Should You Care?

If you’re a software developer or manager thereof navigating the ever-changing landscape of our industry, you’ve likely encountered countless blogs, each vying for your attention. Perhaps you’ve stumbled upon mine and wondered, “Why should I care about the musings of someone who’s been in the field for over five decades?” It’s a fair question, and one I’m happy to address.

The Unique Lens of Long-Term Experience

In the software development business (even that label is a misnomer) where technologies seem to emerge and evolve at breakneck speed, there’s an invaluable perspective that only time can provide. My five decades in this field have offered me a vantage point that’s both rare and illuminating. It’s not just about having witnessed the changes; it’s about understanding the underlying patterns, the cycles of innovation, and the constants that persist despite superficial transformations.

This long-term experience isn’t merely a chronicle of technological advancements. It’s a deep well of insights into the human aspects of software development – how teams collaborate, how culture is paramount, and how organisations adapt to new challenges. It’s about seeing the forest for the trees, recognising the echoes of past innovations in today’s breakthroughs, and understanding that while the tools and practices may change, the fundamental principles of attending to folks’ needs remain remarkably consistent.

In the following subsections, we’ll explore how this unique lens of long-term experience provides a context that can enrich your understanding of current trends and future directions in our field. Whether you’re a seasoned practitioner or just starting your journey, may I suggest that there’s value in a perspective that can inform your decisions, broaden your outlook, and perhaps even challenge some of your assumptions – both personal and collective – about the nature of progress in software development.

From Paper Tape to Petabytes: A Journey Through Computing Eras

My journey in software development began when paper tape was cutting-edge and has continued through to the era of petabyte storage. This span of experience isn’t just a testament to longevity; it’s a unique vantage point from which to observe the evolution of our field.

The Foundations of Innovation

One of the most valuable insights gained from this long-term perspective is the recognition of perennial, foundational concepts. What seems revolutionary today often has roots in concepts from decades past.

Beyond the Hype: Uncovering Enduring Principles

The Fallacy of “This Time It’s Different”

In an industry that thrives on the “next big thing,” it’s easy to get caught up in the hype of new technologies. However, my experience has shown me that while the tools change, the fundamental challenges of attending to folks’ needs through e.g. software remain remarkably consistent.

Timeless Challenges in a Changing Landscape

Human Psychology and Motivation: At its core, software development has always been a human endeavour. Dependent on relationships, collaborations, and fellowship.
Quality: Phil Crosby, and others, wrote about quality over fifty years ago. Yet from the users’ point of view, software today is as lame as it ever has been.
Value a.k.a. Meeting Folks’ Needs: So many projects and teams witter on about delivering value, yet noone seems to understand what value is. Let alone how to reliably deliver it.
Human-Computer Interaction: The principles of creating intuitive interfaces have evolved but not fundamentally changed since the days of command-line interfaces.
Data Integrity and Security: The scale and methods have changed, but the core concerns remain as critical as ever.

The Value Proposition: Why My Perspective Matters

Contextualising Current Trends

By drawing parallels between historical developments and current trends, I offer readers a broader context for understanding the evolution of our field. This perspective can be invaluable in making informed decisions about which principles and practices to adopt and which skills to develop.

Learning from History to Avoid Repeated Mistakes

The philosopher George Santayana famously wrote,

“Those who cannot remember the past are condemned to repeat it.”

This observation is particularly pertinent in the field of software development, where the rapid pace of change can sometimes obscure valuable lessons from the past.

Many of the challenges facing developers, managers and their organisations today have historical precedents. By sharing insights from past successes and failures, I aim to help the current generation avoid reinventing the wheel, missing out on eternal wisdom, or repeating past mistakes.

An Invitation to Dialogue

In the realm of software development, where innovation is constant and change is the only certainty, the exchange of ideas becomes not just valuable, but essential. This blog isn’t meant to be a one-way street of wisdom flowing from past to present. Rather, it’s an open forum, a meeting place where experience and fresh perspectives can maybe collide, coalesce, and create new insights.

The beauty of our field lies in its collaborative nature. No single perspective, no matter how well-informed or long-standing, can capture the full picture of our continually evolving industry. It’s in the synthesis of diverse viewpoints—from the battle-hardened veteran to the wide-eyed newcomer—that we can find the most profound and applicable wisdom.

So, as we delve into the following points about bridging generational divides and valuing your perspective, remember: this isn’t just about absorbing information. It’s an invitation to engage, to question, to challenge, and to contribute. Your voice, your experiences, and your insights are not just welcome—they’re essential to this ongoing conversation about the past, present, and future of software development.Assuming anyone cares, of course.

Bridging Generational Divides

The rapid pace of change can sometimes create a divide between generations of developers. My blog can serve as a bridge, fostering intergenerational dialogue and mutual understanding.

Your Perspective Matters

I encourage readers to engage with my posts critically. Your experiences in the current technological landscape are just as valid and relevant. By combining your fresh perspective with my historical insights, we can generate more comprehensive and nuanced understandings of our field.

Conclusion: The Synergy of Experience and Innovation

In an industry that often prioritises the new and novel, there’s immense value in also looking into and remembering fundamentals. My blog isn’t about nostalgia or resisting change; it’s about leveraging decades of accumulated wisdom to inform and enhance currently applied principles and practices.

I invite you to approach my posts with curiosity and an open mind. Whether you’re a seasoned attendant or just starting your journey, there’s always new tricks to learn from old dogs – and always new insights to be gained from unknown perspectives on old problems.

Let’s continue this dialogue and together shape the future of the software development business, informed by the lessons of the fundamentals and excited by the possibilities of the future.

Quality in Relationships: Striving for Zero Conflict

October 3, 2024

Actionable Insights, Alien tech, Antimatter principle, Article, Business, Conflict, Crosby, Culture change, Deming, Dialogue, Empathy, Listening, Nonviolence, Organisational behaviour, Organisational effectiveness, Organisational Therapy, Paradigm shifts, Philosophy, Quality, Relationships, Systems thinking, Toxic behaviours

Leave a comment

Quality in Relationships: Striving for Zero Conflict

In a world where conflict seems omnipresent, from workplace disagreements to international disputes, it’s time to challenge our assumptions. What if conflict, like defects in manufacturing or bugs in software, isn’t an inevitable part of human interaction? What if we could create environments where conflicts are as rare as defects in a cutting-edge factory or bugs in well-designed and well-implemented software?

The Zero Conflict Revolution

From Zero Defects to Zero Bugs to Zero Conflicts

In the 1960s, Philip B. Crosby introduced the revolutionary concept of Zero Defects in manufacturing. This paradigm shift transformed industries, proving that with the right processes and mindset, eliminating defects entirely was possible.

Fast forward to the software industry, where a similar revolution has been unfolding.

Today, we stand on the cusp of applying these same principles to human relationships and organisational dynamics.

The Cost of Conflict and Defects: Why Zero Matters

Conflict isn’t just uncomfortable—it’s expensive. A 2008 study estimated that U.S. employees spend 2.8 hours per week dealing with conflict, costing organisations approximately $359 billion in paid hours annually.

Similarly, software bugs and defects carry enormous costs. A 2022 report by Synopsys found that security vulnerabilities alone in software cost companies an average of $2.5 million per breach.

Imagine redirecting the time, energy, and resources spent on conflicts and defects towards innovation, growth, and positive change.

Building a Zero Conflict Environment

1. Root Cause Analysis: The Foundation of Prevention

Just as a skilled doctor treats the disease, not just the symptoms, and a software engineer fixes the underlying causes of bugs in the way the work works, not just bugs’ manifestations, we might choose to address the root causes of conflicts. This involves:

Conducting thorough post-mortems of past conflicts
Identifying recurring patterns and triggers
Implementing systemic changes to prevent similar issues

2. Communication: The Oxygen of Harmony

Clear, open communication is to interpersonal; and intergroups relationships what clarity of needs (Cf. the Needsscape™) and the attending thereto are to software development—essential and revitalizing. To foster this:

Establish multiple channels for feedback and dialogue
Invite and practice active listening at all levels of the organisation
Regularly check for understanding to prevent misinterpretations

3. Alignment: Creating a Unified Vision

Many conflicts stem from misaligned expectations or values, just as software defects often arise from misaligned requirements, unattended to needs, or omission of key groups and individuals from the set of Folks That Matter™ . To create alignment:

Continually surface and refelct on shared assumptions, beliefs, goals and values
Involve all stakeholders in decision-making processes
Create a strong, inclusive organisational culture that everyone can rally behind

From Conflict Resolution to Conflict Prevention

Redefining Skills for a Zero Conflict World

Instead of training people to resolve conflicts, we might choose to focus on preventing them, much like how cutting-edge software development focuses on preventing bugs rather than just fixing them. Key skills include:

Emotional intelligence and empathy
Proactive problem identification
Collaborative problem-solving techniques
Nonviolence

The Shift in Mindset

Achieving and maintaining a Zero Conflict environment requires ongoing and regular effort, similar to the integration of software development into the wider organisation (Cf. Systems thinking):

Implement habitual feedback loops
Encourage open discussions about potential conflict triggers
Foster a culture where everyone feels responsible for maintaining harmony

Measuring Success in the Zero Conflict Paradigm

New Metrics for a New Approach

To invite behaviour change, we might choose to adopt new ways of both defining and measuring success, inspired by both manufacturing and software development metrics:

Track ‘Days Without Conflict’ similar to safety metrics in manufacturing
Measure the reduction in time spent on conflict-related activities, akin to reducing debugging time in software development
Survey employee satisfaction and stress levels as indicators of underlying tension, similar to user satisfaction metrics in software

The Road Ahead: Challenges and Opportunities

While the Zero Conflict approach offers immense potential, it’s not without challenges. Resistance to change, deeply ingrained habits, and the complexity of human emotions all present obstacles. However, the potential benefits—increased productivity, improved well-being, and stronger relationships—make this a journey worth undertaking.

As we stand at this crossroads, the question isn’t whether we can eliminate conflict, but whether we have the courage and vision to make it happen. Just as we’ve revolutionised manufacturing quality and software reliability, we can transform the quality of our relationships. In doing so, we might just create a world where quality in relationships is as achievable as quality in manufacturing and zero defect software.

The Treasure Map to Quality Software: Attendin’ to Yer Crew’s Needs

September 19, 2024

Antimatter principle, Article, Attendants, Community, Crosby, Culture change, Customers, Pirate, Product development, Quality, Software development

Leave a comment

The Treasure Map to Quality Software: Attendin’ to Yer Crew’s Needs

Ahoy, ye scurvy dogs! Gather ’round and lend yer ears to this tale of software and product development on the high seas. Many a buccaneer be gettin’ lost in a maelstrom of metrics, practices, and fancy talk. But arrr, are we missin’ the real booty? Hoist the colors, for we be divin’ deep into the heart of software quality, and it ain’t what ye might expect!

Rethinking Quality: It Be Nothin’ About the Code, Ye Bilge Rats!

For many a moon, we’ve been measurin’ software quality through a spyglass of technical nonsense:

How many bugs per thousand lines o’ code?
What be the cyclomatic complexity score?
How’s our test coverage lookin’?
And other such landlubber gibberish!

But in the grand scheme o’ things, these metrics be as useful as a glass bottom boat in a typhoon. They’re missin’ the most crucial element: the human factor, ye swabs!

The True North of Software Quality

At its core, quality software be about one thing: how well it serves the needs of all the Scallywags That Matter™. This human-centric approach shifts our focus from mere technical excellence to genuine treasure creation.

Who Be These Scallywags?

End-users: The landlubbers who interact with yer software daily.
Business stakeholders: The wealthy merchants investin’ their doubloons into the project.
Developers and maintainers: The wizards in the crow’s nest.
Support staff: Yer frontline buccaneers in the battle for user satisfaction.
Regulatory bodies: The naval officers enforcin’ compliance and safety.
Society at Large: The port towns impacted by how ships do business, and the rum and grog they produce.

The Pirate’s Satisfaction Matrix

Imagine a map where each crew group forms a row, and their needs form the columns. True quality be achieved when we maximize satisfaction across this entire map. Let’s break it down like a shipwreck:

1. End-users: The Ultimate Judges

Needs: Ship-shape UX, reliability, speed, and security
Quality Indicator: User satisfaction scores, retention rates, feature adoption

2. Business Stakeholders: The Vision Keepers

Needs: Return on investment, market dominance, scalability
Quality Indicator: Booty growth, market share, operational efficiency

3. Developers and Maintainers: The Unsung Heroes

Needs: Clean code, comprehensive sea charts (documentation), extensibility
Quality Indicator: Development speed, bug fixin’ time, crew satisfaction

4. Support Staff: The Front-line Warriors

Needs: Clear error messages, robust loggin’, efficient troubleshootin’ tools
Quality Indicator: First-call resolution rates, average handlin’ time, CSAT scores

5. Regulatory Bodies: The Compliance Guardians

Needs: Adherence to the Pirate Code, audit trails, data protection
Quality Indicator: Compliance certifications, audit pass rates

The art of creatin’ quality software lies in findin’ the X that marks the spot to best serve all these competin’ interests.

Measurin’ True Quality: The Needsscape Satisfaction Index (NSI)

We propose a new treasure map: the Needsscape Satisfaction Index (NSI). Here’s how ye navigate it:

Identify key needs for each crew group
Assign weights to each need based on their declared priorities
Regularly measure achievement levels for each need
Calculate a weighted average to get yer NSI

A high NSI indicates products and services that ain’t just technically sound, but truly attend to the needs of all the Scallywags That Matter™.

Conclusion: Quality Be Human, Ye Bilge Rats!

In our quest for software excellence, let’s not lose sight o’ the open sea for the waves. Technical metrics be as useful as a chocolate teapot, true quality be measured in human terms. It’s about creatin’ software that makes life better for every swab it touches – from the end-user to the DevOps engineer. And better means attendin’ to folks’ needs.

The next time ye be assessin’ software quality, look beyond the code. Ask yerself: “How well does this serve the needs of the scallywags that matter?” That’s where the real treasure lies.

Remember, at the end of the day, we ain’t just buildin’ software. We’re creatin’ solutions for human needs. Let’s measure our success accordingly, or walk the plank!

Further Readin’ for Ye Scholarly Lubbers

Fer ye scurvy dogs keen on plunderin’ the depths o’ quality’s philosophy and practice, we be recommendin’ these legendary tomes, as essential as rum on a long voyage:

Pirsig, R. M. (1774). Zen and the art of ship maintenance: An inquiry into values. Tortuga Press.
Crosby, P. B. (1779). Quality is free: The art of making quality certain as the North Star. Blackbeard’s Library.

These complementary perspectives – one philosophical, one practical – provide a rich map for thinkin’ about and implementin’ quality in software and product development, and beyond. Now, drink up me hearties, yo ho!

The Paramount Indicator of Quality Software: Attending to Folks’ Needs

September 19, 2024

Antimatter principle, Article, Attendants, Community, Crosby, Culture change, Customers, Product development, Quality, Software development

Leave a comment

The Paramount Indicator of Quality Software: Attending to Folks’ Needs

In the field of software and product development, we often find ourselves caught up in a whirlwind of metrics, methodologies, and best practices. But amidst this technical maelstrom, are we losing sight of what truly matters? With this post we’re diving deep into the heart of software and product quality, and it’s likely not what you expect.

Rethinking Quality: It’s Nothing About the Code

For decades, we’ve measured software quality through a technical lens:

How many bugs per thousand lines of code?
What’s the cyclomatic complexity score?
How’s our test coverage looking?
Etc.

In the bigger pitcure, these metrics have little relevance. They’re missing a crucial element: the human factor.

The True North of Software Quality

At its core, quality software is about one thing: how well it serves the needs of all the Folks That Matter™. This human-centric approach shifts our focus from mere technical excellence to genuine value creation.

Who Are These Folks?

End-users: The folks who interact with your software daily.
Business stakeholders: Those investing time and resources into the project.
Developers and maintainers: The wizards behind the curtain.
Support staff: Your frontline troops in the battle for user satisfaction.
Regulatory bodies: The guardians of compliance and safety.
Society at Large: The communities of people impacted by how organisations do business, and the products and services they produce.

Satisfaction Matrix

Imagine a matrix where each stakeholder group forms a row, and their needs form the columns. True quality is achieved when we maximise satisfaction across this entire matrix. Let’s break it down:

1. End-users: The Ultimate Judges

Needs: Intuitive UX, reliability, performance, security
Quality Indicator: User satisfaction scores, retention rates, feature adoption

2. Business Stakeholders: The Vision Keepers

Needs: ROI, market competitiveness, scalability
Quality Indicator: Revenue growth, market share, operational efficiency

3. Developers and Maintainers: The Unsung Heroes

Needs: Clean code, comprehensive documentation, extensibility
Quality Indicator: Development velocity, bug resolution time, employee satisfaction

4. Support Staff: The Front-line Warriors

Needs: Clear error messages, robust logging, efficient troubleshooting tools
Quality Indicator: First-call resolution rates, average handling time, CSAT scores

5. Regulatory Bodies: The Compliance Guardians

Needs: Adherence to standards, audit trails, data protection
Quality Indicator: Compliance certifications, audit pass rates

The art of creating quality software lies in finding the sweet spot that best serves all these competing interests.

Measuring True Quality: The Needsscape Satisfaction Index (NSI)

We propose a new metric: the Needsscape Satisfaction Index (SSI). Here’s how it works:

Identify key needs for each stakeholder group
Assign weights to each need based on their declared priorities
Regularly measure achievement levels for each need
Calculate a weighted average to get your NSI

A high NSI indicates products and services that are not just technically sound, but truly attend to the needs of all the Folks That Matter™.

Conclusion: Quality is Human

In our quest for software excellence, let’s not lose sight of the forest for the trees. Technical metrics have little relevance, true quality is measured in human terms. It’s about creating software that makes life better for everyone it touches – from the end-user to the DevOps engineer. And better means attending to folks needs.

The next time you’re assessing software quality, look beyond the code. Ask yourself: “How well does this serve the needs of the folks that matter?” That’s where true quality lies.

Remember, at the end of the day, we’re not just building software. We’re creating solutions for human needs. Let’s measure our success accordingly.

Beyond Code Reviews: Embracing Dialogue for Better Products and Teamwork

July 30, 2024

Antimatter principle, Article, Dialogue, Product development, Quality, Software development, Teambuilding

Leave a comment

Beyond Code Reviews: Embracing Dialogue for Better Products and Teamwork

The Shortcomings of Code Reviews

For years, software development teams have relied on code reviews as a primary means of improving teamwork and product quality. Whilst these reviews can catch bugs and help maintain coding standards, they often fall short in addressing the most crucial aspects of software development: helping teams grow, and thereby creating products that truly meet the needs of all the Folks That Matter™.

A Paradigm Shift: Focusing on Folks’ Needs

Is it time we shifted our focus from the nitty-gritty of code to the broader picture of product value, a.k.a. product-market fit? By concentrating on dialogue around how well the product meets the needs of all the Folks That Matter™, we can foster a more holistic approach to software-intensive product development that yields better results for everyone involved, including i.e. management and financial stakeholders.

The Power of Inclusive Dialogue

Bringing All Voices to the Table

Instead of limiting discussions to technical team members, we might choose to include a diverse range of perspectives. This means engaging with:

End-users
Product managers
Customer support teams
Sales and marketing professionals
Business stakeholder

By broadening the conversation, we gain invaluable insights into how our product is perceived and used in the real world, and the value that is does – or does not – deliver.

Asking the Right Questions

Rather than debating code style or implementation details, we might choose to ask:

Does this feature address a real need of our users?
How does this change impact different user groups?
Are we addressing the most pressing needs of the Folks That Matter™?
Does this align with our long-term product vision (the needs of the organisation)?

Benefits of This Approach

Improved Product-Market Fit

By focusing on the needs of the Folks That Matter™, we’re more likely to create products that truly resonate with our target audience, leading to higher adoption rates and customer satisfaction.

Enhanced Team Collaboration

This approach encourages cross-functional teamwork, breaking down silos and fostering a shared sense of purpose among all team members.

Faster Time-to-Market

By prioritising value over perfection, we can deliver features that matter more quickly, allowing for rapid iteration based on real-world feedback.

Implementing the Shift

Regular Check-ins with the Folks That Matter™

Schedule frequent meetings with diverse groups of Folks That Matter™ to gather feedback, spark ideas, and discuss product direction.

Value-Driven Development Practices

Incorporate techniques like user story mapping and impact mapping to keep the focus on attending to folks’ needs.

Continuous Feedback Loops

Implement mechanisms – such as the Needsscape – for ongoing feedback from all the Folks That Matter™, ensuring that the product evolves in line with changing needs, and its evolution is both transparent and tracked.

Conclusion

Code reviews have had theire day – and been found sorely wanting. Let’s shift the primary focus of our efforts to attending to the needs of all the Folks That Matter™ – including improved teamwork and product quality (needs of the organisation, we might assume). By shifting our attention to meaningful dialogue about folks’ needs we can create better software, happier teams, and generally more satisfied Folks That Matter™. It’s time to look beyond the code and see the bigger picture of what truly matters in software-intesive product development.

Version 3 of 3

From Cicero to Modern Business: The Enduring Concept of ‘Qualitas’

July 22, 2024

Article, Deming, Quality

Leave a comment

From Cicero to Modern Business: The Enduring Concept of ‘Qualitas’

We often encounter terms like ‘quality assurance’ and ‘quality control’. But have you ever wondered about the origins of this focus on quality? Let’s take a fascinating journey from ancient Rome to today’s boardrooms, exploring how the concept of ‘qualitas’ has shaped our understanding of product excellence.

The Roman Roots of Quality

The term ‘quality’ finds its origins in the Latin word ‘qualitas’, a concept extensively explored by the renowned Roman orator and philosopher, Cicero. In his writings, Cicero used ‘qualitas’ to describe the inherent nature or essential character of something. Little did he know that his philosophical musings would lay the groundwork for modern quality principles.

Cicero’s Influences: A Melting Pot of Ideas

Cicero didn’t develop his ideas in isolation. His understanding of ‘qualitas’ was shaped by a rich tapestry of influences:

Greek philosophy, particularly the works of Aristotle (Poiotes) and Plato
Stoic teachings
Roman legal and rhetorical traditions

This blend of perspectives allowed Cicero to create a nuanced understanding of quality that transcended simple descriptions.

From Philosophy to Products: The Evolution of ‘Qualitas’

As centuries passed, the concept of ‘qualitas’ evolved. During the Industrial Revolution, it began to be applied more concretely to manufactured goods. The idea that products could possess inherent qualities that made them superior or inferior gained traction.

Quality in the Modern Business Landscape

Today, ‘qualitas’ lives on in our obsession with product quality. From ISO standards to Six Sigma methodologies, the business world has developed sophisticated systems to ensure that products meet or exceed expectations.

Why Cicero’s ‘Qualitas’ Still Matters

Understanding the philosophical roots of quality can provide several benefits for modern businesses:

Holistic Perspective: It encourages us to look beyond mere specifications and consider the overall essence of a product, and the system that produces it (including product design).
Customer-Centric Approach: Just as Cicero considered the nature of things, we must consider the nature of customer needs and expectations.
A journey: The philosophical underpinnings of ‘qualitas’ remind us that quality is not a fixed state, but a constant pursuit of excellence.

Conclusion: Embracing ‘Qualitas’ in Your Business

As we’ve seen, the concept of quality has a rich history dating back to ancient Rome, and even earlier. By embracing this heritage and understanding the deeper meanings of ‘qualitas’, businesses can choose to elevate their approach to product quality.

Remember, the next time you’re in a quality assurance meeting, you’re not just following modern best practices – you’re participating in a tradition of thought that spans millennia. Now that’s something Cicero would surely find intriguing!

Rethinking Determinism and Testing in Software Development: A Path to Zero Defects

July 2, 2024

Article, Crosby, Culture change, Quality, Testing

Leave a comment

Rethinking Determinism and Testing in Software Development: A Path to Zero Defects

In the realm of software engineering, we often discuss concepts like determinism, preconditions, postconditions, and class invariants. While these are important, it’s time we challenge some fundamental assumptions about software development and testing. This post explores these concepts and then proposes a radical shift in our approach.

Traditional Concepts: A Brief Overview

Determinism: In a deterministic system, the same input consistently produces the same output.
Preconditions: Conditions that must be true before a method is executed.
Postconditions: Conditions that must be true after a method has executed.
Class invariants: Conditions that must hold true for every instance of a class at all times (except during method execution).

These concepts intersect to form a framework for designing, implementing, and reasoning about software systems and their quality. They promote predictable behaviour, enhance reliability, and facilitate verification and assurance of software correctness.

Challenging the Status Quo

However, it’s time we question some deeply ingrained beliefs in our industry:

Testing Does Not Ensure Quality

Contrary to popular belief, testing does not ensure quality. It merely identifies the presence of defects, not their absence. Quality must be built into the product from the start, not tested in afterwards.

Testing is Waste

All testing is, in fact, waste (‘muda’ in lean manufacturing terms). It doesn’t directly add value to the end product from the customer’s perspective. In an ideal development process, testing would be unnecessary.

Defects are Not Inevitable

We’ve long operated under the assumption that defects are an inevitable part of software development. This belief has led us to accept testing as a necessary evil. But what if we challenged this assumption?

A New Paradigm: Zero Defects through Progressive Refinement

As Phil Crosby Crosby advocates, we can eliminate the need for testing through a progressive refinement of our approach to development. Here’s how:

Perfect Requirements: Start with a flawless understanding and documentation of requirements. This eliminates misunderstandings that lead to defects.
Rigorous Design:Develop: comprehensive design specifications that leave no room for ambiguity or misinterpretation.
Correct-by-Construction: Employ programming languages and techniques that make it impossible to introduce certain classes of bugs (a.k.a. Poka yoke).
Pair or Ensemble Programming and Code Reviews: Use these practices not to find defects, but to ensure that every line of code written is correct from the start.
Continuous Verification: Instead of testing after the fact, continuously verify that the software meets its specifications throughout the development process.
Cultural Shift: Foster a culture where the expectation is appropriate, not some vague “good enough”. Every team can choose to believe that defects are preventable and unacceptable.

The Role of Determinism in Zero-Defect Software

In this new paradigm, concepts like determinism, preconditions, postconditions, and class invariants take on a new role. Rather than being tools for testing, they become part of the specification and verification process:

Determinism ensures predictable behaviour, making verification easier.
Preconditions and Postconditions become part of the formal specification, used to prove correctness rather than guide testing.
Class Invariants help ensure that objects maintain consistent states throughout their lifecycle.

Conclusion: Towards a Testing-Free Future

By adopting this mindset and progressively refining our development practices, we can move towards a future where testing is unnecessary because defects simply don’t occur. This isn’t just an idealistic vision – it’s a necessary evolution of our field.

Remember, every test we write is an admission that we expect our software to fail. By aiming for zero defects and eliminating the need for testing, we’re not just reducing waste – we’re fundamentally changing what it means to develop software.

The path to this future won’t be easy, but as Phil Crosby reminds us, it’s a journey worth undertaking (Cf. “Quality is Free”. After all, in a world of zero-defect software, the intersection of determinism, preconditions, postconditions, and class invariants isn’t about testing – it’s about guaranteed correctness.

In this new world, we don’t test quality in; we build it in from the start. We don’t hunt for bugs; we prevent them from ever existing. This is the future of software development – a future without tests, because tests have become obsolete in the face of our ability to create quality, defect free software.

The Misunderstood World of Quality Assurance

April 11, 2024

Actionable Insights, Antimatter principle, Article, Business, Culture change, Organisational effectiveness, Product development, Quality, Quantification, Quintessence, Software development

Leave a comment

The Misunderstood World of Quality Assurance

What is Quality Assurance?

Quality Assurance (QA) is a term that gets tossed around quite frequently in the business world, particularly in the realms of product development and software development. However, despite its widespread usage, QA remains one of the most misunderstood and misused terms out there. Many conflate it with quality control, when in reality, QA is a separate and far more comprehensive approach that we might choose to see permeate every aspect of a business’s operations.

Separating QA from Quality Control

A fundamental misconception is viewing QA and quality control as one and the same. This could not be further from the truth. Quality control refers to the specific processes and techniques used to identify defects or non-conformances in products or services. It is a reactive measure, taken after a product or service has been created.

Quality Assurance, on the other hand, is a proactive and all-encompassing mindset, focused on implementing principles, processes, and activities designed to achieve the goal of “ZeeDee” – Zero Defects. When effective QA practices are in place, the need for extensive quality control measures – a.k.a. inspections, testing – becomes largely unnecessary.

The Holistic QA Approach

In the context of product development, we might choose to see QA integrated into every phase, from conceptualisation to final delivery and beyond. This involves establishing clear quality objectives, defining measurable criteria, implementing robust preventive measures, and continuously monitoring and improving based on feedback and data.

Similarly, in software development, we may choose to regard QA as crucial throughout the entire lifecycle, ensuring functionality, reliability, and an optimal user experience – not through testing, but through activities like risk management, all geared towards the Zero Defects goal.

Prevention over Correction

The true power of Quality Assurance lies in its ability to prevent issues before they arise, rather than correcting them after the fact. By implementing comprehensive QA strategies with e.g. ZeeDee as the guiding star, organisations can significantly reduce or eliminate the need for resource-intensive quality control processes (inspections and the like), resulting in increased efficiency, cost savings, and a superior end product or service.

An Organisational Culture

Ultimately, Quality Assurance is not merely a set of tools and techniques; it is a mindset and a culture that must be embraced by every member of an organisation. From top management to front-line employees, everyone must understand the importance of quality and take ownership of their role in ensuring that products and services consistently meet the needs of all the Folks That Matter™, with Zero Defects as the guiding principle.

Conclusion

In a world where businesses strive for excellence and customer satisfaction is paramount, Quality Assurance as defined here is not a luxury; it is a necessity. By recognising the true scope and significance of QA, its distinction from quality control, and its pursuit of ZeeDee (Zero Defects), organisations can unlock the full potential of their products and services, foster a culture of quality, and ultimately, achieve sustainable success in an increasingly competitive marketplace.

Improving Human-to-Human Communication Through AI and Chatbots

February 13, 2024

Actionable Insights, AI, AInklings, Article, Automation, Chatbots, Improvement, Innovation, Interactive books, Quality, Writing

2 Comments

Improving Human-to-Human Communication Through AI and Chatbots

For God’s sake, there is truly no longer any excuse for typos, misspellings, and grammatical errors in your posts, articles, and other writings.

Artificial intelligence (AI) and chatbots are transforming how we communicate. When integrated thoughtfully, this technology can optimise and enhance written communication between people. In this post, I’ll discuss some ways AI and chatbots can improve messaging, email, documentation, and other word-based interaction between humans.

Automated Proofreading and Editing

AI-powered writing tools already help by providing grammar and spelling checks. But newer capabilities can now also flag unclear phrasing, verbose language, overused words, and overly complex sentences. This aids writers in simplifying and refining their messaging before sending to a recipient. Readability statistics further help authors match their tone for the intended audience.

Summarisation and Translation Features

For long-form writing like reports or manuals, AI can generate a concise summary highlighting key facts, main takeaways, or action items. This allows collaborators or stakeholders to quickly grasp the essence before diving into the details. Meanwhile, instant translation functionality enables clear communication across language barriers.

Interactive Books

AI is also enhancing books through interactive elements powered by chatbots. Platforms like Ainklings.com allow authors to insert quizzes, discussion questions, exercises and other engaging features directly into the book text (or via sidecars). Readers can further highlight passages and interact with supplementary content related to the main narrative, enriching the reading experience.

Content Recommendations and Insights

Smart suggestions can enable more meaningful interactions through personalised recommendations. By analysing past correspondence as context, AI can prompt authors to include certain missing information, helpful examples, or reminders based on what the recipient would find useful. Language pattern analysis can also reveal insights for improving future discussions.

Automated Meeting Summaries and Notes

While AI currently struggles to match the creativity of human writing, it excels at capturing the salient points from meetings and presentations. Automated summaries of video sessions or collaborative spaces can save meeting participants time while ensuring everyone understands the key decisions or action items.

With thoughtful application, AI and chatbot tools can enhance understanding and engagement between people through better writing assistance, translation, summarisation, and recommendations. As these capabilities continue advancing, keeping the human audience at the center will be key to success.

Workshy Culture: A Top-Down Issue

November 28, 2023

Article, Needs, Organisational effectiveness, Quality, Toxic behaviours

Leave a comment

Workshy Culture: A Top-Down Issue

What Is Workshyness?

Workshyness is not just laziness; it’s a pattern where employees consistently do only what’s necessary to avoid dismissal. Only when we begin to understand this behaviourcan we start to address it effectively. Unlike “quiet quitting”, where employees fulfil their job requirements but don’t go beyond, workshyness involves not even meeting basic job expectations.

Example: The Workshy Employment Advisors

In an employment support office, where the staff’s mandate is to assist the unemployed in their job search, a covert workshy culture is evident through the actions of an advisor named Emily. Emily’s role involves providing personalised career advice, assisting with job applications, and conducting mock interviews. However, her engagement with these tasks is superficial.

Emily’s Covert Workshyness

Emily pretends to review CVs and cover letters, giving the impression of thoroughness while actually offering only superficial and hand-wavy feedback. Her client meetings are conducted with a professional demeanor, but her guidance is often generic, lacking in depth, and fails to address the specific needs and challenges of each individual. She fulfills her duties on the surface, but her involvement falls well short of genuinely empowering her clients in their job hunt.

Subtle Influence on Team and Management’s Lack of Insight

Other staff members, noticing Emily’s approach of maintaining appearances without delivering substantive support, begin to adopt a similar method. They keep up a façade of engagement but shy away from providing the in-depth assistance that clients truly need. This shift is not overt, making it more challenging to detect and address.

Helen, the office manager, perceives the team as functioning well, failing to recognize the lack of depth in their engagement. Without delving into the quality of service being provided, she inadvertently allows this minimalist work culture to continue.

Impact on Service Quality

This covert form of workshyness significantly undermines the quality of service. Clients receive assistance that appears adequate on the surface but lacks the tailored, proactive support essential for effective job seeking. The office, maintaining an exterior of efficiency, falls short of its fundamental mission to empower the unemployed with substantial support. This subtle workshy culture, marked by a lack of genuine engagement from both advisors and management, subtly but significantly diminishes the organisation’s impact and its ability to make a meaningful difference in the lives of its clients.

How Do Managers Contribute?

Management plays a significant role in fostering a workshy culture. Many managers themselves display workshy tendencies, and thus inadvertently set a standard for their employees to follow. This trickle-down effect can create an entire organisational culture that normalises minimal effort. Moreover, as at least part of the managers’ role is to call out workshyness and work on tackling it, when they themselves are workshy their reports have free rein to persist in their avoidance of work.

What Happens When Leaders Are Workshy?

Leadership workshyness is particularly problematic. It’s not always apparent, as their positions often mask their lack of engagement. However, their minimal input and disengagement can severely impact organisational culture and performance. It creates a cycle where workshyness is both a cause and a symptom of a deeper organisational issue.

Why Address Workshyness?

Ignoring workshyness leads to a decline in overall organisational health. It affects productivity, team dynamics, and employee morale. Addressing it isn’t just about improving numbers; it’s about sustaining a healthy, thriving organisational culture.

Strategies for Change

Organisations can choose to actively combat workshyness. This involves rethinking leadership roles, ensuring managers are actively engaged and setting the right example. Companies can also choose to create environments where effort and engagement are expected and valued at all levels. It’s not enough to simply identify workshyness; organisations must actively work to build cultures where it cannot thrive.

In conclusion, workshyness is a systemic issue that often stems from the top. By acknowledging and addressing the role of management in perpetuating this culture, organisations can take significant steps towards fostering a more engaged and productive workforce.

Cracking the Quality Code: Deming and Crosby

September 1, 2023

Article, Crosby, Deming, Quality, Quintessence

Leave a comment

Cracking the Quality Code: Deming and Crosby

W. Edwards Deming is a name synonymous with quality management and process improvement, particularly in Japan where he helped revive post-war industries. Deming’s approach centres around Statistical Process Control (SPC) and the “Plan-Do-Study-Act” (PDSA) cycle, which emphasises iterative improvement.

His core philosophy manifests through “The 14 Points of Management,” guidelines designed to steer management’s decisions and actions towards achieving quality. Here are a few key points to consider:

Create Constancy of Purpose: Long-Term Over Short-Term Deming believed in focusing on long-term goals instead of short-term profits.
Adopt the New Philosophy: Innovation Over Status Quo Deming urged the adoption of new approaches to improve quality and productivity.
Cease Dependence on Inspection: Build Quality In, Don’t Inspect It In For Deming, quality should be built into the process, rather than inspected into the finished product.
Stop Awarding Business Based on Price: Value Over Cost Deming advised prioritising value and quality when choosing suppliers, rather than just looking at price.
Improve the System: Continual Improvement Over Quick Fixes Deming emphasised the need for continual improvement in products, services, and processes.
Use Training for Skills: Education Over On-the-Job Training For Deming, well-planned training programs were preferable to quick, on-the-job training.
Implement Leadership: Leadership Over Mere Supervision Deming believed in guiding workers to better performance through leadership, rather than simply supervising them.
Drive Out Fear: Openness Over Secrecy Deming recommended creating a work environment where employees feel secure, leading to better quality work.
Break Down Barriers: Teamwork Over Individual Performance According to Deming, departments within an organisation must work together as a team for better quality.
Eliminate Slogans: Reality Over Rhetoric Deming criticised empty slogans that demand performance without providing methods. “By what method?”
Eradicate Numerical Quotas: Quality Over Quantity Deming advised against numerical production quotas that sacrificed quality for volume.
Remove Barriers to Pride of Workmanship: Satisfaction Over Speed Deming believed in allowing employees to take pride in their work, rather than rushing them through tasks.
Institute Education and Retraining: Learning Over Layoffs Deming advocated for continual learning and personal development of staff.
Take Action: System-Wide Changes Over Piecemeal Adjustments Deming called for a comprehensive approach to organisational change, rather than making small, disconnected changes a.k.a. “tinkering”.

Deciphering Philip B. Crosby’s Four Absolutes of Quality

Philip B. Crosby, another heavyweight in the quality management arena, had a simpler but equally impactful approach. He believed in the concept of “Quality is Free,” which suggests that investing in quality from the get-go actually reduces costs in the long run. Crosby laid out the “Four Absolutes of Quality” as follows:

Quality Means Conformance, Not Goodness: Quality isn’t about being excellent; it’s about meeting specifications or requirements.
Quality Comes from Prevention, Not Detection: The emphasis here is on stopping mistakes before they happen rather than fixing them afterward.
Quality Performance Standard is Zero Defects, Not ‘That’s Close Enough’: Crosby propagated the idea that anything less than perfect is unacceptable.
Quality is Measured by the Price of Nonconformance, Not Indices: Crosby quantified quality as the cost involved when failing to meet the standard.

The Face-off: Deming vs. Crosby

Here’s some key distinctions between Deming’s and Crosby’s perspectives on quality:

Philosophy vs Pragmatism

Deming: Believed in a philosophical shift across the entire organisation, emphasising continual improvement as part of its DNA.
Crosby: Took a more pragmatic approach with clear, measurable standards, focusing on specific, achievable outcomes.

Definition of Quality

Deming: Didn’t provide a single definition for quality but suggested that it is a continuous quest for improvement.
Crosby: Defined quality strictly as conformance to requirements or specifications (not the written kind we think of today, but the actual needs of the customer).

Approach to Errors and Defects

Deming: Advocated for a constant, iterative process to reduce defects but didn’t explicitly demand a zero-defects approach.
Crosby: Pushed for a zero-defects standard, indicating that anything less was not acceptable.

Preventive vs Reactive Measures

Deming: While he supported preventive actions, his model allows for reactive measures as well, with the PDSA cycle helping to correct course.
Crosby: Strictly focused on prevention over detection, emphasising that errors should be eradicated before they occur.

Scope of Application

Deming: Offered a broad framework, the “14 Points of Management,” that touched on multiple aspects of an organisation.
Crosby: Provided a narrower focus through his “Four Absolutes of Quality,” zeroing in on specific key principles.

Cost Implications

Deming: Didn’t directly quantify the cost of poor quality, although he suggested that focusing on quality would naturally result in cost savings.
Crosby: Directly correlated the cost of poor quality with the price of nonconformance (PoNC), providing a numerical way to gauge it.

Flexibility vs Rigidity

Deming: More flexible, as his PDSA cycle allows organisations to adapt and evolve over time.
Crosby: More rigid due to his zero-defects policy and strict conformance to requirements.

These distinctions boil down to different focal points in the journey towards quality: Deming offers a holistic, philosophical path, while Crosby provides a more tangible, practical, metric-driven route. Both have their merits, and the choice between them often depends on an organisation’s prevailing assumptions and beliefs.

Fertile Mindsets

Now let’s directly compare the foundational beliefs and assumptions needed to implement Deming’s versus Crosby’s approaches to quality.

Philosophy of Continuous Improvement vs Zero-Defect Mentality

Deming: Assumes that improvement is a never-ending journey, fueled by the belief in the value of continuous, iterative processes.
Crosby: Operates on the belief that the goal is to reach a zero-defect standard, where each and every error is considered a failure.

Systems Thinking vs Focused Accountability

Deming: Necessitates a belief in systems thinking, where every part of the organisation is interconnected and contributes to quality.
Crosby: Focuses more on specific, measurable areas and assumes that quality can be attained by holding individuals or departments accountable for their specific roles.

Employee Involvement vs Strict Adherence

Deming: Assumes that employees are part of the solution and not the problem, advocating for an organisation-wide culture of quality.
Crosby: While not discounting the participation of employees, Crosby invited adherence to pre-defined standards, with less emphasis on employee involvement beyond meeting these standards.

Long-Term Vision vs Short-Term Metrics

Deming: Assumes that the organisation is committed to long-term goals and is willing to invest in long-term improvements without immediate ROI.
Crosby: Emphasised the achieving of short-term gains as building blocks toward overall quality. Achieving and maintaining a zero-defect status can be seen as a series of short-term objectives that eventually lead to long-term quality improvements.

Flexibility vs Rigidity in Execution

Deming: Beliefs must be flexible enough to adapt and change as new information and data become available through the PDSA cycle.
Crosby: Assumes a rigid, unyielding stance towards goals and metrics, with no room for deviation from the set standards.

Educational Investment vs Proactive Prevention

Deming: The organisation must believe in continuous learning and personal deveopment as fundamental aspects of quality improvement.
Crosby: Emphasises proactive prevention of errors, believing that the best way to maintain quality is to prevent mistakes in the first place.

Quantifying Quality

Deming: Quality is a more abstract concept, assumed to benefit the organisation in the long run, though not directly quantified.
Crosby: Operates on the assumption that quality can be precisely measured through the ‘price of nonconformance,’ making it a more tangible asset or liability.

By understanding these foundational differences, organisations can better assess which approach to quality management aligns with their existing culture, beliefs, and goals.

Final Musings

Both Deming and Crosby offer frameworks that have stood the test of time and continue to be referenced in the world of quality management. Picking one over the other isn’t a straightforward choice; it’s more about aligning their strategies with your organisation’s unique assumptions and beliefs. After all, quality isn’t a one-size-fits-all garment but a tailored fit that evolves with the organisation and its memeplex.

Embracing the Joy of Work: Unpacking Deming’s Business Management Insights

July 12, 2023

Alien tech, Article, Business, Culture change, Deming, Improvement, Leadership, Psychology, Quality

Leave a comment

Embracing the Joy of Work: Unpacking Deming’s Business Management Insights

In our quest for success, we often navigate an array of management myths. But how can we move beyond mere avoidance of these pitfalls? The answer lies within the profound wisdom encapsulated in the Deming management philosophy.

Dr. W. Edwards Deming was a pioneer who advocated for creating work environments centered around continuous improvement, quality, and productivity. His philosophy isn’t just about avoiding mistakes—it’s a guiding light that leads to better, more fulfilling workspaces.

Let’s delve into Deming’s key principles:

Appreciation for a System

To lead effectively, we must see our organisations as interconnected systems, not standalone silos. Grasping how efforts and teams interrelate to achieve our common goals is pivotal.

Understanding Variation

Deciphering between normal variation within a process (common cause) and external, unusual changes (special cause) helps us make informed, data-driven decisions.

Theory of Knowledge

Leaders might choose to foster an environment of intellectual curiosity, where assumptions are challenged and failures become stepping stones to improvement. Knowledge isn’t simply accumulated—it evolves over time.

Psychology

Recognising human nature and its role in work is crucial. A supportive environment, where employees feel valued and secure, nurtures creativity, productivity, and joy at work.

Summary

These principles are intertwined—understanding one demands comprehension of all. Applied well, they offer a roadmap away from management myths towards a reality where work is a source of personal fulfillment and growth.

Remember, as Deming put it, “People are entitled to joy in work”. Let’s champion this ethos and create workplaces where our teams don’t just survive but flourish.

Effective Software Development

April 21, 2023

Alien tech, Article, Business, Capability development, Culture change, Improvement, Innovation, Lamentation, Management, Productivity, Quality, Quintessence

Leave a comment

Effective Software Development

Everyone in the software industry (managers excepted) knows the following is true, yet nobody wants to talk about it:

Effective software development is entirely incompatible with typical (hierarchical, command-and-control) management.

After 50 years in the industry, I’d go so far as to say:

Effective software development is entirely incompatible with ANY known form of management.

Corollary

Place managers in charge of software development and it can NEVER be ANYTHING but ineffective (high costs, low quality, poor due date performance, lack of innovation, etc.).

NB Applies more broadly, beyond the domain of software development, too.

Reasons

The reasons for this incompatibility can be explained as follows:

1. Creativity and innovation: Software development is a highly creative and innovative process that often requires developers to think out of the box, experiment, and come up with novel solutions. A hierarchical management structure stifles creativity and inhibits the free flow of ideas, emphasising, as it does, strict adherence to rules and policies.

2. Responsiveness and flexibility: In the rapidly changing world of technology, software development teams need to be responsive and adaptable in order to respond quickly to changes in requirements, market conditions, approaches, and user feedback. A command-and-control management style, which relies on rigid plans and mandated approaches, tools, makes it difficult to impossible for teams to pivot and adapt as needed.

3. Collaboration and communication: Effective software development relies on close collaboration and communication among team members with diverse skills and expertise. Hierarchical management structures create barriers to communication, with information flowing primarily up and down the chain of command, rather than freely among team members.

4. Autonomy and motivation: Software developers tend to be highly skilled, motivated individuals who thrive on autonomy and the ability to make decisions about their work. Command-and-control management undermines their motivation by imposing external control and limiting their decision-making authority.

The broader point being made in the corollary statement is that traditional hierarchical management is never the best fit for software development, and that organisations might choose to consider alternative organisational styles and structures that are more conducive to the unique demands of software development.

This idea can indeed apply beyond the domain of software development, as many industries are increasingly recognising the need for more responsive, collaborative, and flexible management approaches to drive innovation and adapt to rapidly changing environments.

Who Was Peter Scholtes and What Did He Say About The System?

March 3, 2023

Article, Culture change, Deming, Organisational effectiveness, Quality, Systems thinking

Leave a comment

Who Was Peter Scholtes and What Did He Say About The System?

Peter Scholtes was a respected author, consultant, and expert on quality management and leadership. He was born on August 29, 1939, in Madison, Wisconsin, and passed away on February 7, 2009. He is best known for his work on quality improvement and management, particularly in the context of the Total Quality Management (TQM) movement.

One of Scholtes’ key contributions to the field of quality management was his emphasis on the importance of understanding and improving the system (the way the work works). He argued that problems are often the result of flawed systems, and that in order to truly improve quality, cost, etc., organisations must focus on improving their systems rather than blaming individuals.

Scholtes also emphasised the importance of involving all employees in the quality improvement process, not just those in leadership positions. He believed that by empowering employees to identify and solve problems within the system, organisations could achieve significant and sustainable improvements.

In his book “The Leader’s Handbook: A Guide to Inspiring Your People and Managing the Daily Workflow,” Scholtes famously stated, “95% of the performance of an organisation is attributable to the system (processes, technology, equipment, materials, and environment) and 5% is attributable to the people. The role of management is to change the system rather than badgering individuals to do better.”

Note: This is often attributed to Bill Deming as “Deming’s 95:5”.

Overall, Scholtes was a significant figure in the field of quality management, and his emphasis on understanding and improving the system continues to be influential today.

Discover the Shocking Truth About QA vs QC: One Is a Complete Waste of Time and Money!

January 22, 2023

Article, Quality

Leave a comment

Discover the Shocking Truth About QA vs QC: One Is a Complete Waste of Time and Money!

Quality control (QC) and quality assurance (QA) are often used interchangeably, but they are in fact two distinct concepts. QC is the process of inspecting and testing a product or service to gain knowledge about conformance of outputs to established standards and specifications. This process is typically carried out at the end of the production process, and it is focused on reporting the status of the production process and its outputs.

QA, on the other hand, is a more comprehensive approach that focuses on preventing defects from occurring in the first place. This process begins at the start of the production process and is ongoing throughout the entire development and production process. Quality assurance is focused on ensuring that the processes and systems in place are capable of producing a product or service that meets the established standards and specifications.

The distinction between QC and QA is important, as they both play a critical role in ensuring the quality of a product or service. However, in the software field, the term “QA” is often misused to refer to testing or quality control. This is a misuse of the term, as QA is a much broader and more comprehensive approach that encompasses the entire development process, from design and development to testing and deployment.

The misuse of the term “QA” in the software field is a common problem, as many companies and organisations do not understand the difference between QC and QA. This can lead to confusion and a lack of focus on the key elements of quality assurance, such as process improvement and continuous monitoring. This can ultimately result in a product or service that does not meet the established standards and specifications, leading to customer dissatisfaction and potential loss of business.

To avoid this problem, it is essential for companies and organisations in the software field to clearly understand the distinction between QC and QA.

In conclusion, Quality Control and Quality Assurance are two distinct concepts . Quality Control is focused on reporting on the status of the production process and its outputs, while Quality Assurance is focused on preventing nonconforming outputs (‘defects’) from occurring in the first place. In the software field, the term “QA” is often misused to refer to testing or quality control, which can lead to confusion and a lack of focus on the key elements of quality assurance.

It is crucial for companies and organisations in the software field to clearly understand the distinction between QC and QA and to ensure that their processes and systems are capable of producing a high-quality product or service.

A Conducive System

May 31, 2022

Article, Capability development, Culture change, Ethics, Improvement, Management, Organisational effectiveness, Productivity, Quality, Quintessence, Systems thinking

Leave a comment

A Conducive System

[Tl;Dr: What are the system conditions that encourage ethical – and productive, effective – behaviours (Cf William Kingdon Clifford) in software delivery organisations?]

In yesterday’s blog post “The System Is Unethical” I related my experiences of how businesses – and the folks that run them and work in them – remain ignorant of just how ineffective they are at software delivery. And the consequences of that ignorance on e.g. costs, quality, customer satisfaction, etc

To recap: an unethical system perpetuates behaviours such as:

Failing to dig into the effectiveness of the organisation’s software delivery capabilities.
Indifference to the waste involved (wasted time, money, opportunities, human potential,…).
Ignorance of just how much more effective things could be, with e.g. a change in perspective.
Bravado and denial when questioned about such matters.

The Flip Side

Instead of the behaviours listed above, we might seek a system that encourages behaviours that include:

Continual attention to the effectiveness of the organisation’s software delivery capabilities.
Concern over the waste involved, and actions to reduce such waste.
Investigation into just how much more effective things could be.
Clarity and informed responses when questions about such matters.

Conducive System Conditions

So what might a system conducive to such behaviours look like?

That’s what my book “Quintessence” illustrates in detail. But in case you’re a busy person trapped in a non-conducive system, I’ve previously written about some of the key aspects of a conducive system, here:

Quintessence For Busy People

BTW I’m always happy to respond to your questions.

– Bob

The Software Quality and Productivity Crisis Executives Won’t Address

The Crisis in Numbers

What Executives Know Privately

What Executives Do About It

The Priority Charade

The Public Deception

The Productivity Paradox

The Investment That Never Happens

The Trend Is Accelerating—And Why It Takes Decades to See It

The CrowdStrike Crystallisation

What This Reveals About Executive Leadership

Why Executives Choose Inaction

The Cost of This Failure

The Case for #NoLeadership

What #NoLeadership Looks Like in Practice

The Limits and Risks

A Challenge to the Industry

The Path Forward

Further Reading

Share the joy :)

The Continuous Improvement Delusion

Philip Crosby’s Case Against Kaizen Culture

Organisational Learned Helplessness Dressed Up as Diligence

The Economics of Actually Fixing Things

Zero Defects vs. The Improvement Treadmill

The Prevention vs. Detection Fallacy

The Management Commitment Problem

Why We Choose Comfortable Failure

The Modern Vindication

A Different Path Forward

The Uncomfortable Truth

Further Reading

Share the joy :)

Stop Optimising. Start Fixing.

How continuous improvement is a chimera.

The Continuous Improvement Trap

The Power of Just Fixing It

When Fix-It-Now Actually Works

The Resistance You’ll Face

Phil Crosby Had It Right All Along

The Cost of Broken Things

The Four Absolutes vs. Endless Improvement

The Fifth Absolute: Purpose Over Process

The ‘Do It Right the First Time’ Philosophy

The Vaccination Approach to Problems

Implementation Without Ceremony

The Real Quality Movement

Building the Fix-It Imperative

Building a Fix-It Culture

The Real Continuous Improvement

Further Reading

Share the joy :)

Meaning, Quality, and Joy: A Conversation

Share the joy :)

The Relevance of Experience: Insights from Five Decades in Software Development

The Perennial Question: Why Should You Care?

The Unique Lens of Long-Term Experience

From Paper Tape to Petabytes: A Journey Through Computing Eras

The Foundations of Innovation

Beyond the Hype: Uncovering Enduring Principles

The Fallacy of “This Time It’s Different”

Timeless Challenges in a Changing Landscape

The Value Proposition: Why My Perspective Matters

Contextualising Current Trends

Learning from History to Avoid Repeated Mistakes

An Invitation to Dialogue

Bridging Generational Divides

Your Perspective Matters

Conclusion: The Synergy of Experience and Innovation

Share the joy :)

Quality in Relationships: Striving for Zero Conflict

The Zero Conflict Revolution

From Zero Defects to Zero Bugs to Zero Conflicts

The Cost of Conflict and Defects: Why Zero Matters

Building a Zero Conflict Environment

1. Root Cause Analysis: The Foundation of Prevention

2. Communication: The Oxygen of Harmony

3. Alignment: Creating a Unified Vision

From Conflict Resolution to Conflict Prevention

Redefining Skills for a Zero Conflict World