Reader situation
You’ve proposed an approach in a Circle or a meeting: a process, a recommendation, a way of handling a common problem. Someone replies, “That didn’t work for us.” It’s tempting to dismiss the exception or to abandon the idea altogether. Neither response uses what the exception can teach, and both can discourage others from sharing their experience.
Central idea
An exception can reveal where an approach needs qualification. Invite a counterexample, examine why it differs and refine the conditions under which the original idea is useful.
Practical steps
- State the idea. Describe your approach clearly, including what it’s meant to achieve. “Weekly written updates reduce the need for status meetings” is clearer than “written updates are better.” A clear statement makes it easier for others to identify where it might not hold. Include the context you’ve tested it in: “This has worked in my team of eight people working on two projects.”
- Invite an exception. Ask directly for situations where the approach might fail: “When would this be unlikely to work?” or “Has anyone tried something similar that didn’t work?” Asking for counterexamples signals that you’re interested in improving the idea, not defending it, and it makes it easier for others to share. If no one offers a counterexample, that’s useful information, but it isn’t proof. You might ask a peer privately, since some people are reluctant to contradict an idea in public.
- Compare contexts. When someone offers a counterexample, explore how their situation differed from yours. Ask about team size, type of work, culture, leadership, timing, resources and how the approach was implemented. Often the difference explains why the outcomes differed, and it’s rarely that one person simply did it wrong. Ask with curiosity rather than looking for a flaw in their attempt. “What was different about your team’s situation?” invites a fuller answer than “Did you do it properly?”
- Refine the claim. Use what you’ve learned to make the idea more precise. Add the conditions under which it works and those under which it doesn’t: “Weekly written updates reduce the need for status meetings in small teams that already write regularly. They’re less effective where work changes daily or where team members rarely read updates.” A refined claim is more useful to others, because they can judge whether it fits their situation.
- Identify remaining limits. Note what you still don’t know. Perhaps you haven’t seen the approach tested in large organizations or over long periods. Being honest about remaining limits helps others use the idea appropriately and invites further examples. Over time, a well-examined idea becomes more valuable to a community than a confident claim that hasn’t been tested.
Worked example
Fictional example
The people and details are invented to illustrate an approach. It reports no outcomes.
In a Circle for engineering managers, Ruth shares an approach: replacing daily stand-up meetings with a written update in a shared channel. She says it saved her team about two hours a week.
She asks, “When would this be unlikely to work?” Daniel replies that his team tried it and abandoned it after a month, because problems that used to be raised in stand-ups went unnoticed.
Ruth asks how his team differed. Daniel explains that his team works on systems with frequent urgent incidents, and that several members were new and less confident raising problems in writing. Ruth’s team is experienced and works on longer-term projects.
Ruth refines her claim: “Written updates can replace stand-ups for experienced teams on longer-term work. Teams handling frequent urgent issues, or with many new members, may need a short live check-in as well.” She notes a remaining limit: she hasn’t seen it tested in teams larger than ten. Two other members reply with their own experience, one from a team of 25, and the refined version becomes one of the most useful threads in the Circle that month.
Companion tool: Counterexample discussion card
Use these prompts when sharing or discussing an approach.
Stating the idea
- “The approach is , and it’s meant to achieve .”
- “I’ve seen it work in ________ (context).”
Inviting an exception
- “When would this be unlikely to work?”
- “Has anyone tried something similar that didn’t work?”
Comparing contexts
- “What was different about your situation?”
- “How was it implemented in your case?”
Refining
- “So it seems to work when , and less well when .”
Remaining limits
- “What I still don’t know is ________.”
Boundaries
- A single counterexample doesn’t necessarily disprove an idea. It shows where to look more closely.
- Thank people who share counterexamples. It takes some courage to contradict an idea in public.
- Don’t share details of another organization’s failure without permission.
Member action
Ask a peer when your proposed approach would be unlikely to work. Listen to the answer before explaining why the approach should still work.
Discussion prompt
What’s an approach you use that works well in your context but might fail in another?
