The System You Can't SeeBy Hannah Baker Dear Reader, Here's a question I get more than any other: "How do I handle the person who talks too much?" Or the flip side: "How do I get quiet people to speak up?" And every time, I want to say: you're asking the wrong question. Not because those moments aren't real or frustrating. They are. But because treating them as people problems is like looking at algae blooming in a pond and asking, "how do I fix the algae?" You don't. The algae isn't the problem. It's the signal. It's telling you the system is out of balance, too much phosphorus, not enough oxygen, water temperature rising. The algae is just making the imbalance visible. Same with workshops. When someone dominates the conversation or the room goes silent, that's not a person problem. It's a signal that something in the system isn't working. What Most People Do (And Why It Doesn't Work)When a workshop goes wrong, most of us go looking for a technique. A phrase to quiet the loud person. An icebreaker to warm up the quiet ones. A facilitation trick we can deploy in the moment. And look, those can help. Marginally. Sometimes. But they're treating symptoms. Because the real question isn't "what do I say when someone dominates?" It's: why did the system create conditions where domination was possible in the first place? Did you give people time to think alone before asking them to speak? Did you structure the session so ideas could be written down first, leveling the playing field between fast talkers and slow processors? Did the activity you chose actually match what the group needed to accomplish? Did you accidentally signal, by who you called on first, or how you responded, that certain voices matter more? These aren't facilitation moves you make in the room. They're design decisions you make before you walk in. And most people skip them entirely. The Two Sides of the SystemI've been thinking about workshop design as a system with two sides. DIAGNOSE — what you investigate before you design anything IEP (Individual Execution Plan) — what you build in response Most people live entirely on the IEP side. They focus on activities, formats, and facilitation techniques. Which makes sense, that's the visible part. That's what happens in the room. But if you skip the diagnostic work, you're building on a shaky foundation. You're picking activities without understanding what the group actually needs. You're hoping the format works without diagnosing whether people are ready for it. You're facilitating in real time without clarity on what the session is actually trying to accomplish. And then, when things go wrong, you blame the participant. What Diagnosis Actually Looks LikeThe diagnostic side has three elements, and they're sequential, each one informs the next. Context — where this workshop sits in the larger arc of work. Is this the right moment in the process? Does the person convening it have the authority to act on the outcome? Are there prerequisites missing that would make this workshop premature? Context is a viability check. Before you even think about goals or activities, you're asking: does this workshop have the right conditions to exist at all? Sometimes the answer is no. And that's valuable to know before you waste everyone's time. Audience — who's in the room and what they're bringing. Not just names and titles. What do they already know? What tools can they use? What are they expecting from this session, and what concerns might they bring? Audience isn't demographics. It's readiness. And if you don't diagnose readiness, you'll design activities people can't actually do, or worse, activities that feel patronizing or irrelevant. Goal — what this workshop can and should actually accomplish. Not what the person requesting the workshop wants. What the process and the team actually need at this moment. A real goal passes three tests: Is it achievable in a workshop? Can you get there in the time you have? Does it follow from the context and serve the audience? Goal is where context and audience converge into one answerable question: given where we are in the process and who's in the room, what should this workshop actually do? And sometimes, honestly, often, the answer is: not what you thought. What You Build In ResponseOnce you've diagnosed, you move to execution. This is the IEP side: Activities, Format, Facilitation. But here's where it gets interesting. Unlike diagnosis, where context, audience, and goal are distinct sequential steps, the execution elements don't separate cleanly. They're more like three lenses on the same thing. Activities are what you ask people to do. A brainstorm to generate ideas. A 2x2 matrix to prioritize them. A stakeholder map to understand relationships. Each activity serves a specific step (learn something, do something, decide something). Format is how you run those activities. Do people think alone first, then share? Write anonymously, then discuss? Work in pairs, then come back to the full group? Facilitation is how you hold the session live. Staying neutral. Paraphrasing what you hear. Knowing when to intervene and when to let tension sit. In planning, you think through them separately. But in the room, they collapse into one thing happening simultaneously. And here's the key: all three are shaped by your diagnosis. If your audience analysis told you half the room is new to the topic, you choose activities that don't assume shared knowledge. If your context check revealed this is a high-stakes decision with unclear authority, you design formats that make input visible and attributable, not anonymous. If your goal is to surface concerns rather than push toward consensus, your facilitation needs to hold space for disagreement, not smooth it over. The diagnosis tells you what to build. The execution is how you build it. Skip the diagnosis, and you're just borrowing someone else's format and hoping it fits. Why This Matters NowHere's the thing about systems thinking. Once you see the system, you stop blaming the algae. You stop looking for the one trick that will fix the difficult participant, because you realize the participant isn't difficult, the conditions are unclear. And that's actually liberating. Because it means you have leverage. You can design differently. You can diagnose what's missing and build for it. You're not at the mercy of whoever shows up in the room. You're designing the conditions that shape how they show up. That's what Facilitating Workshops is about. Not collecting more techniques. Not learning a menu of icebreakers. But building the diagnostic skill to look at a workshop, before it happens, and understand what it actually needs. To see the system. To design for it. And to stop mistaking signals for problems. I built an interactive version of this. Same scenario, a kickoff where the decisions are already made. Toggle between undiagnosed and diagnosed. Click any element to see exactly what changed and why.
Until next time! |
The Fountain Institute is an independent online school that teaches advanced UX & product skills.
I Bought a Mac Mini to Try OpenClaw, the Most Hyped AI Tool of 2026 by Jeff Humble Dear Reader, You've probably heard of OpenClaw 🦞 by now. 145,000 GitHub stars. Headlines everywhere. "The AI that actually does things." This tool is the O.G. dream of AI...automation, not slop. This was the missing piece to my automation system. I had to try it. So I bought an entry-level, 2024 M4 Mac Mini for €590 (on sale in Germany, but they're reportedly selling out in the U.S.) and spent two days trying...
Why Decisions Feel So Hard Right Nows By Hannah Baker Dear Reader, Over the last few months, I’ve been talking with design and product leaders across very different organizations, large companies, smaller teams, fast-moving environments, and slower ones. And I keep hearing the same thing. Their teams are being asked to make decisions faster than ever, and yet, deciding feels heavier than it used to. Not slower, exactly. Just harder. At first, people often explain this in familiar ways: too...
When Speed Stops Being the Bottleneck by Jeff Humble Dear Reader, Quick question: What happens when the thing that used to take 12 weeks now takes 4 days? I've been watching this play out across the industry, and it's wild. Lots of companies aren't sharing their new speeds, but a few are: Code and Theory (an agency that works with Microsoft and Amazon) is building dashboards in 40 minutes that used to take a week. They report cutting time-to-prototype by 75%. Coinbase reports a 2-5x increase...