A team lead brings you a problem. A release keeps slipping, morale is fraying, and two senior engineers have stopped speaking in meetings. You've seen this pattern before, and within minutes you know exactly what you would do.

That fast, confident diagnosis is where most attempts to help go wrong. Helping someone solve a problem is a different challenge from solving it yourself. The system you're working on isn't just the problem. It includes the person who owns it, the context only they can see, and their capacity to act on whatever emerges. A brilliant solution that the owner doesn't understand, believe in, or feel ownership of tends to fail at the point of implementation, which is where it matters most.

This article treats helping as a design problem in its own right. We'll look at when to help rather than solve, how to facilitate without steering, and how carefully built questions can do the heavy lifting of discovery. The aim is a repeatable approach for anyone whose job increasingly involves making other people better problem-solvers.

Solving transfers an answer. Helping builds the other person's capacity to reach one. Both are legitimate, but they are different interventions with different outcomes. The trouble is that experienced professionals default to solving almost automatically, because it feels efficient and it confirms their expertise.

The organisational psychologist Edgar Schein observed that every helping relationship starts out unbalanced. The person asking for help is temporarily one-down, and the helper is one-up. Jumping straight to answers reinforces that imbalance. It can make people defensive, or quietly dependent. There's also an information asymmetry working against you. The problem owner holds context you lack: the politics, the history, the constraints nobody wrote down. Your quick solution is built on an incomplete specification.

A simple diagnostic helps you choose. Solve directly when the situation is urgent, when the problem is purely technical with a known answer, or when you'll own the outcome yourself. Help them solve when they will be the one implementing, when the problem is likely to recur, when the context is dense and local, or when their development is part of the goal. Most workplace problems brought to managers and consultants fall into the second category.

Consider the engineering analogy. Patching a bug in a colleague's codebase fixes today's failure. Pairing with them to find it changes how that codebase evolves. Solving also carries a hidden cost: the problem returns in a slightly different form, and it comes back to you. Over time you become a bottleneck, and the people around you become less capable of handling the very situations you keep rescuing them from.

Takeaway

Before offering an answer, ask who will live with the solution. If it's them, your job is to strengthen their thinking, not replace it.

The core principle of facilitation is a separation of concerns. You manage the process; the owner manages the content. You hold the structure of the conversation. They hold the substance of the problem. Most failed attempts at facilitation collapse because the helper quietly takes over both.

The first technique is to make the stages explicit. Design thinking describes problem-solving as alternating between divergent thinking, which generates options, and convergent thinking, which narrows them. Name the mode you're in out loud: "Let's spend ten minutes just listing possible causes before we judge any of them." People who feel stuck are often mixing modes, critiquing ideas in the same breath they generate them. Edward de Bono's Six Thinking Hats rests on the same insight: separating modes of thinking makes each one more productive.

The second technique is to externalise the problem. Get it onto a whiteboard, sticky notes, or a rough causal map. Once the problem lives on a wall, you and the owner examine it side by side rather than face to face. This small shift reduces defensiveness and makes gaps visible. The third technique is to reflect back. Summarise what you've heard in their language, then check: "Is that accurate?" Corrections at this stage are valuable data about how they actually see the problem.

Finally, manage your own ideas rather than suppressing them. Keep a private parking lot. Note your hypotheses and hold them until the owner has exhausted their own thinking. When you do offer something, frame it as one option among several and label it as a hypothesis to test: "One possibility worth checking is…" The idea enters the system without displacing their ownership of the outcome.

Takeaway

Hold the process, release the content. The moment you start steering toward your preferred answer, you've stopped facilitating and started persuading.

Questions are the facilitator's primary tool, but not every question helps. "Have you thought about restructuring the team?" is advice wearing a disguise. The person hears your answer and starts evaluating it, rather than thinking for themselves. A genuine question is one whose answer you don't already know.

Effective questioning tends to follow a sequence that mirrors root cause analysis. Start by clarifying: "What exactly is happening? When did you first notice it?" Then expand the frame: "What else might be contributing? Who would describe this situation differently?" These questions widen the problem space before anyone narrows it, which counters the common tendency to lock onto the first plausible explanation.

Next, probe causes and assumptions. "What would have to be true for this to keep happening?" invites systems thinking without demanding it. A gently paced version of the Five Whys can surface deeper drivers, provided it feels like curiosity rather than interrogation. "What are you assuming here that might not hold?" often unlocks the most progress. Finally, move toward action: "What's the smallest step you could take this week to test your thinking?" Small, owner-defined experiments convert insight into momentum.

Craft matters as much as content. Ask open questions, and ask one at a time. Stacked questions let people answer the easiest one. Then tolerate the silence that follows. Silence is often where the actual thinking happens, and filling it too quickly hands the problem back to you. Michael Bungay Stanier popularised one of the most useful prompts of all: "And what else?" The first answer is rarely the best one, and a simple invitation to keep going often reveals what matters most.

Takeaway

A good question doesn't point toward an answer; it widens the space where the person can find one. If you already know the answer you want, it isn't really a question.

When someone brings you a problem, a simple sequence keeps you useful without taking over.

First, decide your role: solve it, or help them solve it. Second, agree on the process, including where they are stuck and which mode of thinking they need. Third, externalise the problem so you're examining it together. Fourth, lead with questions, parking your own ideas until theirs are exhausted. Fifth, close on a concrete next step that they define and own.

The measure of good help isn't whether the problem gets solved in the room. It's whether the person walks out better equipped, both for this problem and for the next one you won't be there to see.