The problem-solving culture: PDCA and root causes

Problem-solving is one of the most universal skills there is, and one of the most rarely taught, structured, or standardized. Across every profession, each of us improvises our own method, often without realizing it, and the cost shows up as wear and tear: the same problems come back, again and again, because we settled for soothing them instead of eliminating them.

Yet this culture rests on a disarmingly simple process: the PDCA (Plan-Do-Check-Act), inherited from the Lean approach. It’s a tool I was lucky enough to dig into and put into practice alongside Philippe Fenot during the excellent Learning to Scale training, and one I now apply every day, both individually and collectively. Beyond software engineering itself, it’s a thinking framework that applies to any problem: organizational, technical, or personal.

PDCA in four steps

The cycle comes down to four movements that follow one another and replay in a loop until the problem is genuinely solved.

1. Identify a problem, whether organizational or technical. It can be a problem flagged by a customer or a colleague, or simply experienced or observed by someone on the ground. The condition is that it be real and verified, not assumed.

2. Look for the root cause or causes. This means devoting deep and honest reflection to it, with the goal of forming hypotheses about the true origin of the problem, not about its visible manifestations.

3. Apply a countermeasure whose goal is to eradicate the problem as effectively as possible.

4. Observe and verify the results obtained against those expected. If it works, we generalize and spread the knowledge. If not, we start the process over.

The mechanics seem obvious. And that’s precisely where the trap lies: the step that separates a lasting resolution from a perpetual patch-up is rarely the one you’d think.

The crucial step: symptom or root cause?

It’s step 2 that makes all the difference, and it’s also the one we most often skip over. Far too frequently, the reflection stops at the discovery of a symptom. We treat that symptom, we observe immediate relief, we declare ourselves satisfied, and the root problem, meanwhile, naturally keeps doing its damage, ready to resurface in one form or another.

Confusing a symptom with its cause means committing to an endless repair rather than an eradication.

An example of the wrong approach

Let’s take a deliberately trivial case to make the mechanism obvious:

• Problem: I’m having trouble breathing properly, which keeps me from sleeping peacefully.
• Root cause identified: my nose is blocked. (Trap! That’s a symptom, not a cause.)
• Countermeasure: blow my nose.
• Expected result: being able to sleep.
• Actual result: ten packs of tissues later, one nostril works a little better, but overall the nose stays blocked.

The mistake is glaring in this example, but it’s exactly the same one we make every day on far more complex problems. A blocked nose isn’t the cause: it’s the signal of something else: an allergy, a virus, an environment that’s too dry, a reaction to a food. As long as we treat the discharge, we’re only managing the consequence of a mechanism that, for its part, remains intact.

Repair or eradicate

A quote from Philippe Fenot sums all of this up better than I could:

A countermeasure applied to a symptom amounts to a repair. A countermeasure applied to the root cause allows the problem to be eradicated.

The entire value of PDCA hinges on this distinction. Repairing means temporarily getting the system running again while knowing, consciously or not, that the breakdown will return. Eradicating means tracing the thread back to the origin so that the problem, once treated, stops manifesting for good. The first approach consumes energy continuously; the second frees it up for good.

In the previous example, the real countermeasure isn’t to buy more tissues, but to identify why the nose gets blocked, then to act on that cause. The leap seems harmless with a cold; with a recurring production incident, a team burning out, or a customer walking away, it makes all the difference between an organization that learns and one that papers over the cracks.

Why so few organizations do it

If the tool is so simple and so powerful, why do so few people, and even companies, adopt and standardize these processes aimed at continuously identifying problems, solving them, and drawing collective learning from them?

There are no doubt several reasons. Short-term pressure pushes us to put out the fire rather than understand why it started. Treating a symptom provides immediate gratification, whereas tracing the root cause demands time, honesty, and sometimes the courage to admit that the problem comes from oneself or from one’s own way of working. And above all, without a shared framework, everyone solves problems their own way: nothing is capitalized on, nothing is passed on, and the organization keeps relearning the same lessons.

PDCA answers precisely this: it turns problem-solving into a standardized and collective discipline, where every problem solved becomes a learning that can be spread to the rest of the group.

Conclusion

The next problem you run into is an invitation. Rather than reacting in the heat of the moment, try applying a PDCA to it: state the problem, honestly look for its root cause, not its most visible symptom, apply a targeted countermeasure, then verify what you actually get against what you expected.

It’s an extremely powerful tool, all the more so when it becomes a shared reflex. The real problem-solving culture doesn’t begin the day you know how to solve a hard problem, but the day you stop confusing a nose you blow with a nose you actually unblock.