The Empty Hands Fear
Having nothing to present is worse than presenting the wrong thing. Right?
Commonly affects: Teams used to being judged on deliverables, participants who’ve been criticized for “having no results,” first-timers afraid of looking unprepared.
The Anti-Pattern
The clock is ticking and the team has nothing on the whiteboard yet. Panic sets in. Instead of continuing to explore the problem, map user journeys, or discuss trade-offs, the team shifts into “we need something to show” mode. Someone starts drawing boxes. Someone else picks technologies. The messy, valuable process of understanding the problem gets abandoned in favor of producing a presentable artifact.
The unspoken fear: standing in front of the room with an empty slide is worse than standing in front of the room with the wrong answer.
Why It Feels Right
In most professional settings, “I explored the problem deeply but didn’t reach a conclusion” is not a well-received outcome. People are trained to deliver results. A kata with a presentation at the end amplifies this pressure. The team sees other groups filling whiteboards and assumes they’re falling behind. Producing something feels like progress, even if the foundation is shaky.
The Catastrophe
The team produces a surface-level architecture built on assumptions they never validated. The user journeys were never mapped, so the design doesn’t reflect how people actually use the system. The trade-offs were never discussed, so the first reviewer question exposes a gap nobody considered.
Worse, the team skipped the part of the kata where the real learning happens. Understanding the problem, debating approaches, and wrestling with trade-offs is the exercise. The deliverable is just evidence that the process took place. By rushing to fill the whiteboard, the team traded learning for the appearance of productivity.
The Rescue
Trust the process and redefine what “results” means:
- A half-explored problem is more valuable than a fully drawn bad diagram. Presenting “we identified these three tensions and here’s how we’d approach them” is a strong outcome, even without a complete architecture.
- Map user journeys first. Trace 2-3 key user paths through the system before drawing any boxes. This is a result in itself and it shapes everything that follows.
- Name what you don’t know. “We ran out of time, but the open question is whether this should be sync or async” shows more architectural maturity than a diagram that silently picked one.
- Present your thinking, not just your output. Reviewers value “we considered X and Y, chose Y because of Z” far more than a neat diagram with no rationale.
- Facilitators can help here. If the kata’s expected deliverables are clear upfront (see The Vague Briefing), teams feel less pressure to guess what “enough” looks like.