Name the problem before you solve it

Most of the time I've wasted in my life went into solving the wrong problem, very well.

I'd feel bad, grab the first explanation that came to mind, and get to work on it. New routine, new plan, new tool. Weeks later the feeling was still there, because the thing I'd fixed was never the thing that was wrong.

That's why the first step in name it, tame it is naming. Not fixing. Naming.

When I say "I'm stressed about work", that's not really a problem yet. It's a cloud. Inside it there might be a manager I can't read, a skill I'm afraid is going out of date, too little sleep, or a quiet sense that I don't matter there any more. Each of those needs something different.

The philosopher John Dewey saw this a century ago. "A problem well put is half-solved," he wrote in Logic: The Theory of Inquiry (1938). Put it badly and you can work as hard as you like. You'll still be digging in the wrong place.

The Scaled Agile Framework, SAFe, runs a regular event for large groups of teams called Inspect and Adapt. Part of it is a problem-solving workshop. And the very first step isn't brainstorming solutions. It's agreeing on the problem to solve. Only then do people dig for the root cause, often by asking "why?" again and again, a habit that came out of Toyota's factories.

SAFe opens its page on that event with a line from Taiichi Ohno, who shaped the Toyota way of working: "If you assume that things are all right the way they are, you can't do kaizen. So change something!" Kaizen means steady improvement. But notice the order. First you admit, in plain words, that something isn't all right.

Scrum has its own version of this. Before work goes into a sprint, the team refines it. The Scrum Guide calls refinement "the act of breaking down and further defining Product Backlog items into smaller more precise items." Many teams also keep a checklist, often called a Definition of Ready, so nobody starts on a piece of work that is still a cloud.

I've borrowed that idea for myself. A problem is ready to work on when I can say it in one plain sentence, and someone else would understand it.

When I'm stuck, I write the problem down three times.

• First, the cloud. Exactly as it feels. "Everything at work is going wrong."
• Then, the facts. What actually happened, in a line or two. "My project was moved to another team on Tuesday. Nobody told me why."
• Then, the real question. "I don't know if my place on the team is safe, and I haven't asked."

The third line is almost always smaller than the first, and almost always something I can act on. In this case, by asking. That's the moment a cloud becomes a problem with edges.

It's the same order as the Name it sheet: what happened, name it, then tame it. The sheet just fits it onto one page.

Asking "why?" five times works well on machines. On people, including me, it can turn into an interrogation. So I soften it: "what's underneath this?" I ask it once or twice, not five times, and I stop as soon as I reach something I can do something about.

Sometimes the answer underneath is a feeling, not a task. Fear of being left behind. Shame about money. That counts too. A feeling with a name is a feeling I can work with. As I wrote in Laces Tied, the question that matters most is often not "how do I get out?" but "who am I going to be in here?"

Once the problem is named, the solving often gets easier than I expected. Sometimes it's one conversation. Sometimes it's a list of the things I still have, the way I described in The Eight Forms of Capital, Revisited. And sometimes the honest answer is that the problem isn't mine to solve, and naming it is what lets me put it down.

If you want the words I use for all this, they're in the glossary. The next piece, After you name it, is about choosing the first step once the problem has a name.

I'm not a doctor, and this isn't therapy. It's a way of seeing that helps me. If you are struggling, please talk to someone you trust or a professional.

Don't solve the cloud. Name the problem inside it. Then it's half-solved.