The Six Thinking Hats By Edward De Bono

How to Run a Hat Session Without Wasting Everyone's Time

I first used The Six Thinking Hats By Edward De Bono in a product roadmap meeting that had been going in circles for forty-five minutes. Two senior engineers were locked in a debate about whether to build a feature internally or buy a third-party solution, and nobody was actually addressing the real question. I suggested we put the argument aside and run through the hats properly. We finished in eighteen minutes. Here's how the method works in practice. You assign a colored hat to represent a specific mode of thinking, and everyone in the room wears that same hat at the same time. You move from one hat to the next in a sequence that makes sense for the decision at hand. The goal isn't to agree immediately. The goal is to make sure you've looked at the problem from enough angles that your conclusion isn't just the loudest person's opinion.

The Six Thinking Hats By Edward De Bono

White hat is pure data. You list what you know, what you don't know, and what information you need. No opinions, no speculation. In my experience, people hate this hat at first because they want to jump to conclusions. That's the point. You force the group to agree on the facts before anyone gets to have an opinion. Red hat is emotion and intuition. People state how they feel about the situation without having to justify it. This sounds like a waste of time until you realize how many meetings I've sat through where someone's actual objection was buried under three layers of logical argument. The red hat surfaces it in thirty seconds. Black hat is caution. You play devil's advocate. What could go wrong? Where are the risks? This is the most important hat for decision quality, and also the one most people skip because they don't want to be the pessimist. When you formalize it as a hat rotation, being negative becomes a group task instead of a personal attack.

Yellow hat is the opposite. You argue for value. What are the benefits? Why would this work? It's easy to dismiss this as corporate cheerleading, but it forces the group to articulate the case for something instead of just reacting to objections. Green hat is creativity. New ideas, alternatives, workarounds. You're not evaluating anything yet. You're generating. This is where most teams go stale because they've already convinced themselves there's only one or two options on the table. Blue hat is process control. It runs the meeting. It sets the agenda, summarizes findings, and decides what the next step is. Usually one person wears the blue hat for the whole session, though you can rotate it if the discussion gets long.

The typical sequence I use starts with blue to frame the question, then white to establish facts, red to surface feelings, black to stress-test, yellow to balance, green to explore alternatives, and blue again to close and assign action items. That's roughly twenty minutes for a five-person team. You can compress it by skipping hats that aren't relevant, but I've seen people skip black and regret it within a week. Here's a specific problem I ran into that most guides don't mention. During a vendor selection process, the team went straight from white to black hat and spent twenty minutes listing every reason the preferred vendor was a bad fit. Then someone mentioned a competitor, and the whole discussion pivoted. We were still in black hat mode, so nobody flagged that we'd abandoned the original question. I had to stop the session, put the blue hat back on, and remind everyone we were evaluating two different vendors under the same framework. The fix was simple: I started writing the decision criteria on a whiteboard before we put on any hats, and we referenced it after every hat switch. It kept us honest. Another thing people get wrong is treating the hats as a strict linear process. They're not. You can jump around. If someone raises a creative idea during the black hat phase, you don't shut it down. You note it and come back to it during green. The structure is there to prevent chaos, not to prevent thinking. I've run sessions where we did yellow immediately after white, skipped red entirely, and came back to green twice. That was fine. The question being answered was whether to restructure the support team, and the hats helped us see it from angles we'd missed.

The method has real limitations. It doesn't work well when there's a power imbalance in the room. If a director is wearing the yellow hat and aggressively arguing for a decision, junior people will quietly adopt the same color even if they're privately in black. You can mitigate this by having everyone write their response to each hat anonymously before sharing, but that slows things down. It also doesn't work for decisions that require deep technical expertise. The hats are a discussion framework, not a substitute for actually knowing what you're talking about. I've seen teams run a full six-hat session on an architecture decision and emerge with a conclusion that was emotionally balanced but technically nonsensical. If you're looking for something to read before you try it, the original book is Six Thinking Hats from 1985. There are free summaries online, but the book has concrete examples that make the mechanics clearer than most articles. I'd recommend skimming it before your first session rather than after, because the first time you run it you'll be figuring out the logistics and won't have much mental bandwidth for theory. For practical purposes, you don't need any special tools. A whiteboard, sticky notes, or a shared document works fine. I've used Google Docs with color-coded sections and it was adequate. The method lives or dies on facilitation, not on the apparatus. Pick a sequence, state the question clearly, enforce the hat boundaries, and write down the output from each phase. That's it.