The Hands-Off Facilitator
You’re the business stakeholder. Facilitating is someone else’s job. Oh wait, that’s also you.
Commonly affects: Facilitators who take the stakeholder role too literally, facilitators who read “let teams struggle” as “never intervene.”
The Anti-Pattern
A team is visibly stuck. They’ve been adding boxes to a diagram for ten minutes without any clear direction, piling on detail because they don’t know what else to do. Or they’re going in circles, revisiting the same discussion for the third time. You notice, but you stay in character as the business stakeholder. When they ask you a question, you answer it in-role. What you never do is take off the business hat and say “let me help you with a technique to move forward.”
You have a toolbox of facilitation techniques that could unblock the team in five minutes, but you never open it.
Why It Feels Right
You don’t want to be The Over-Corrector. You’ve heard that good facilitators let teams struggle, and struggle is where the learning happens. Stepping in to run a mini-session feels like taking over. Besides, the team should know how to structure their own thinking. If they can’t figure out how to break down the problem, that’s a useful lesson too.
There’s also a simpler reason: switching between “business stakeholder answering questions” and “facilitator guiding a process” feels awkward. It’s easier to stay in one role.
The Catastrophe
The team burns through half the time box producing noise instead of signal. They add components, draw arrows, and label technologies, but none of it is grounded in actual requirements or user needs. The diagram grows in detail and shrinks in meaning. By the time they realize they’re lost, there’s not enough time left to restart with a clear approach.
Meanwhile, the facilitator has all the tools to help: a quick user journey to anchor the design in real flows, a lightweight event-storming pass to surface the key domain events, a simple “what are the top 3 architectural characteristics?” prompt to focus the discussion. None of these give away the answer. All of them give the team a way to move forward. But none of them get offered.
The Rescue
Recognize that facilitation and the stakeholder role are two different hats, and know when to switch:
- Watch for spinning. If a team has been adding detail without making decisions for more than 5-10 minutes, they’re likely stuck. Detail without direction is a signal, not progress.
- Offer process, not answers. You’re not telling them what to design. You’re offering a way to think. “Would it help to walk through a quick user journey for the main scenario?” is facilitation, not correction.
- Keep a short menu of techniques ready. You don’t need many: a user journey walkthrough, a brief event-storming pass, a “list your top architectural characteristics” exercise, or simply asking “what’s the one decision you’re avoiding?” Pick the one that fits and offer it.
- Make the hat switch explicit. Say “I’m stepping out of the business role for a moment” so the team knows you’re facilitating, not hinting at the solution. Then switch back.
- Calibrate to the team. Some teams just need a nudge (“have you considered starting from the user’s perspective?”). Others need you to stand at the whiteboard and run a 5-minute structured exercise. Read the room.