Problem Solving Is Continuous, Short-Range Work

Organizations spend enormous energy solving problems. Someone spots a gap, flags an issue, and a chain of activity begins: meetings, proposals, and new processes. But identifying a problem is itself fraught with assumptions that rarely get examined.

Go and See for Yourself Before Declaring a Problem

The first trap in organizational problem solving is skipping validation that you’re solving a real problem. People often make an observation, interpret it, and declare a problem exists without ever checking whether their observation matches reality. Other times, people start with a belief about how things should be, and every deviation between what they expect and what they see in their organization becomes a problem to solve.

It’s okay to start with a hunch or an idea, but it’s a mistake to think you can diagnose problems without first doing some fact-finding. One nice quality of many Lean and Toyota Production System practices is that they emphasize going where problems happen and seeing the facts for yourself. Before you define a problem, it’s essential to “go and see.”

The best practice is to go and see the location or process where the problem exists in order to solve that problem more quickly and efficiently. To grasp problems, confirm the facts and analyse root causes.

— Genchi Genbutsu – Toyota Production System guide(opens in a new tab)open_in_new

In a distributed, digital world, we don’t always have a factory floor to go to see the objective truth. We can use data and reporting systems, but they often only indicate the presence of a problem. Dashboards can’t tell us what’s really happening or why. To find out what’s happening, we have to listen to the real experiences of people doing the work and collect their stories.

Problem solving in complex systems doesn’t start with designing a new process and rolling it out broadly. It starts with visiting the gemba, talking to people, collecting stories, and building a series of hunches.

Work-As-Imagined Versus Work-As-Done

A lot of waste in organizations happens when people far from the work think they’ve identified a problem with how the work is done and turn those observations into new processes for teams to follow. They compare what they see against a model of how they think the work should happen.

When someone far from the work prescribes a solution to close the gap between what they want to see and what’s actually happening, they aren’t fixing a problem; they’re constraining the system’s adaptability by imposing new processes and taking power and control away from the teams doing the work.

Teams Are Different and Have Different Needs

Another pattern in corporate problem solving is overgeneralization. Someone finds an issue in one team, assumes it represents how all teams operate, and concludes the only solution is a system-level intervention. The same fix gets prescribed to every team regardless of whether the problem exists there or the solution fits.

This treats teams as homogeneous and problems as global. In a complex environment, that is a recipe for unintended consequences. Different groups have different goals, contexts, and constraints. A solution that works for one team may create issues for another.

The Linear Problem-Solving Trap

Organizations often reward the process of problem-solving and implementing solutions without examining whether the problem was real or the solution was appropriate.

This creates perverse incentives. People learn that being seen as a problem solver is rewarded, whether or not what they did actually helped. They get good at spotting things that look like problems and prescribing solutions that look like action. The solutions can have unforeseen negative impacts on the people and teams they are meant to help, but by the time those effects surface, the problem solver has already been rewarded and moved on.

People doing the work eventually become skeptical of new change initiatives, as they become the victims of change, forced to follow a new process rather than being trusted to improve how they work.

The deeper issue is that this approach treats problem solving as a linear sequence: identify the problem, design the solution, implement, move on. But improving a mess doesn’t work that way.

Managers Manage Messes

Messes are messes because they include multiple interacting problems, not because there are many individual, isolated problems. That means we cannot approach a mess as a task of solving the “right” problem with the “right” solution. Data, reports, and observations can give us clues that a problem exists, but because messes are systems of interacting problems, we can never fully understand or define them.

Managers do not solve problems; they manage messes… The sum of the optimal solutions to each component problem taken separately is not an optimal solution to the mess. — Russell Ackoff

Instead, we have to approach it the way you approach any complex system: form hypotheses, take small steps, monitor for side effects, use the power of networks, and treat every intervention as a way to learn more about the mess itself. This isn’t a one-pass activity. It requires ongoing sensing, monitoring, nudging, and reevaluating. The kind of effort that actually improves a mess is the harder, ongoing work of staying connected to the system, noticing what changes, and adjusting course based on what you learn.

Problem Solving Is the Continual Bettering of a Mess

Because complex environments include different groups with different goals interacting in different ways, you can’t trust that any individual situated outside that system will be able to diagnose and solve its problems accurately. The solution begins by working with the people doing the work. Treat the people in the system as partners in diagnosing the situation and designing responses, not as recipients of a mandate.

The people doing the work know the issues. They have an intuitive understanding of how things work and tacit knowledge which they express daily through adjustments and adaptations. Management’s role shouldn’t be to prescribe long-range fixes from a distance; it’s to do the ongoing short-range work of engaging with people and exploring the problem space. That means visiting the gemba, spending time listening, collecting anecdotes, and letting the picture of what’s going on start to emerge from the ground up.

Stop prescribing solutions before you have validated the problem exists. And when you do find a problem, solve it with the people doing the work, not for them. Approach messes like any complex system: run small experiments, watch for side effects, and accept that no single “right” problem has a single “right” solution.