Start with a puzzle. Read it once, then stop and try to answer it before you read on.
April 18, 1775. Paul Revere rides from Boston to Lexington on his horse to warn Samuel Adams and John Hancock that British troops were marching to arrest them. He arrives in Lexington, spends one night in the town, then rides back to Boston the following day. He arrives on Monday and leaves on Monday.
How do you account for this?
If you are stuck, you are in good company. In our workshops, about one person in a hundred gets it. Monday is the horse.
The other ninety-nine drill down into the assumption that Monday refers to time. Nobody stated that assumption. Nobody defended it. It simply arrived with the word, and once the mind fixes on Monday as a day of the week, the problem becomes impossible. Arrive on Monday, stay one night, leave the next day, and still leave on Monday? The facts contradict each other, so people conclude the puzzle is broken. The moment someone challenges the assumption by asking does Monday have to be time? the solution is obvious.
The puzzle is trivial. The mechanism behind it is not. This is exactly what happens with breakthrough thinking on real programs. Teams get locked into their assumptions, follow the normal line of thought, and cannot see the exit even when it sits one question away.
The normal line of thought
Every team approaches a problem along a path shaped by its assumptions and constraints. We call this the normal line of thought. It runs from the problem, as the team has framed it, toward the solutions that framing permits. It is efficient, it is defensible, and most of the time it works. When the problem genuinely requires a breakthrough, the same line runs straight off a cliff, and the team follows it there. Speed on the wrong path is not progress.
The figure is the key concept. Learn to do this deliberately and you can attack almost any problem. The escape move has two parts: set the constraints aside for a moment, and challenge the assumptions that frame the problem. Not to prove them wrong, but to ask whether they are the only way. Edward de Bono built lateral thinking on this move [1], and our challenge process is a practical extension of his work that we have applied with engineering teams for over three decades [2].
The more you know, the harder the escape
Here is the uncomfortable part: education and experience make this worse, not better. The more expertise people carry, the deeper the grooves of their normal line of thought, and the harder it becomes to leave it. This is why some teams never find technical solutions. They cannot escape their own line of thought, and the most experienced people on the team are often the most trapped. It is also why so many technical breakthroughs come from people who are not burdened by the baggage.
The research record backs this up. Psychologists call it the Einstellung effect: once a known solution pattern activates, it blocks the search for better ones. Luchins demonstrated it in 1942 with simple water-jar puzzles, where subjects kept applying a practiced formula long after a far simpler answer became available [3]. Bilalic, McLeod, and Gobet showed the same mechanism in expert chess players: after finding one good move, the players reported searching for a better one, but eye tracking showed their gaze never left the features tied to the first idea [4]. The first thought directs attention toward evidence that supports it, and the searcher does not notice. Dane reached a parallel conclusion in the management literature, describing cognitive entrenchment as the stability of an expert’s mental schemas, which grows with expertise and trades away flexibility [5]. Duncker documented the same trap with objects rather than ideas, naming it functional fixedness: once we know what something is for, we struggle to see what else it could be [6]. Monday is a day of the week, until it is a horse.
Why teams stay trapped
The expertise trap explains why individuals fixate. Teams add two mechanisms of their own, and together the three explain why current thinking is so hard to escape. The first is the frame of reference. A team does not hold its assumptions as a list it can inspect; it works inside them. The shared frame decides what counts as a sensible question, which options deserve analysis, and which ideas are too odd to say out loud. Kuhn described the same structure in science and called it a paradigm: a shared model that defines which problems are legitimate and which solutions are conceivable, and that absorbs contradicting evidence by explaining it away [7]. Every program carries local paradigms of its own: this architecture, our process, the way we qualify, the roadmap. An idea outside the frame is not evaluated and rejected. It never comes up. From inside the frame there is nothing to look at, which is why a team can search hard and honestly and still find only variations of the current answer.
The second mechanism is that the frame defends itself. Once a belief is in place, people seek and interpret evidence in ways that favor it. Nickerson’s review of the confirmation-bias literature shows how consistently this operates, usually with no intent to deceive anyone [8]. The chess study above showed the mechanism at the level of attention: the eyes go where the current idea points them. In a team the effect compounds. Each member’s confirming observations become the group’s shared evidence, disconfirming data gets filed as noise or an edge case, and reviews confirm the plan because the reviewers built the plan. The frame writes its own supporting record.
The third mechanism is social, and it is the one that locks the door. The first person to question current thinking pays a price. They are “negative.” They are “not a team player.” They are “not on board.” The label converts a technical question into a character flaw, and everyone watching learns the real lesson: keep your doubts private. Janis documented where this leads. Groupthink runs on the illusion of unanimity, direct pressure on dissenters, and self-appointed guards of the consensus, and authoritarian leaders accelerate all three [9]. Once dissent goes quiet, the group hears only agreement, mistakes the silence for evidence, and confirms its own assumptions to itself at every level and in every review. That is confirmation bias at organization scale, and it feeds on itself: the fewer challenges leadership hears, the more certain leadership becomes, and the more expensive the next challenge gets.
This is why escapes rarely happen by exhortation. Telling a team to think outside the box does nothing when the box is invisible and stepping outside it gets punished. The way out is structural: make questioning a scheduled, facilitated process in which assumptions are collected anonymously, so the challenge attaches to the idea and never to a person. That is psychological safety in practice, and Edmondson’s research shows teams learn fastest where it exists [10]. The next sections describe the structure.
Surface the assumptions first
You cannot challenge an assumption you have not named. The first working step is to get the team’s current thinking out of people’s heads and onto a list, in crisp, challengeable language. We prompt with four questions, and we push for both the explicit assumptions, the ones people say out loud, and the implicit ones, the beliefs so ingrained that nobody thinks to state them. The implicit list is where the leverage hides. Monday meaning time was implicit.
Then run the challenge
With the assumptions listed, the challenge process is straightforward. Group similar assumptions and select the ones with leverage. For each, ask why: why do we think this, what are the reasons, and are the reasons still valid? Some survive, and that is a good outcome; the belief is now a decision instead of a habit. Some resolve on the spot: can we do it now, or cut it now? The rest open the interesting question, how could this be done differently, which generates ideas, and ideas become actions with owners and dates. A companion paper walks through the full method step by step [11].
Repeat it until it becomes how the team thinks
One challenge session produces ideas. Repetition produces a different team. Run the process on a regular cadence, every couple of months, and schedule the next session the day you finish the last one. Each cycle unfreezes the thinking a little more, and eventually the thought process gets baked into people’s heads and they run it all the time, without a workshop. Practitioners who have worked this way for years challenge assumptions reflexively. It is simply how they think.
Repetition also dismantles the labeling problem. A team that challenges regularly learns to challenge the idea, not the person, and members become comfortable questioning long-held beliefs without fear. That comfort is the psychological safety described above [10], and it is built rather than declared. Each session in which a challenged assumption produces a better plan, and nobody gets tagged for raising it, makes the next question cheaper. Over time the “not a team player” reflex dies out, because questioning stops being one person’s character trait and becomes how the team works.
Where it has worked
This is not a parlor trick scaled up. We have used the challenge process on hard technical and schedule problems for decades. One semiconductor system-on-chip team needed six months out of its development schedule and could not see a path; the challenge surfaced five alternatives worth between two and twenty weeks each, and the option the team selected netted a five-month acceleration [2]. A Boston software team, four months late and locked into its current path, used the process to free its thinking and find the schedule it could not find by pushing harder. Three teams facing genuine technical walls produced three breakthroughs with the same method; the case studies are on lateralworks.com [12].
The pattern across all of them is the riddle’s pattern. None of these teams lacked intelligence or expertise. Each was fixated on its own Monday. The escape took a structured process, a safe environment, and one honest question: does this have to be true?
Going further. The companion paper “Challenge the assumptions” covers the workshop mechanics, the assumption workbook, and a full anonymized register from a live engagement. For the source thinking, read de Bono’s Lateral Thinking, the origin of this approach. We have simplified it for implementation, but it is worth hearing from the master.
References
[1] de Bono, E. Lateral Thinking: Creativity Step by Step. Harper & Row, 1970.
[2] lateralworks. “Breakthroughs by Challenging Assumptions.” lateralworks.com, January 2019.
[3] Luchins, A. S. “Mechanization in problem solving: The effect of Einstellung.” Psychological Monographs, 54(6), i–95, 1942.
[4] Bilalic, M., McLeod, P., and Gobet, F. “Why good thoughts block better ones: The mechanism of the pernicious Einstellung (set) effect.” Cognition, 108(3), 652–661, 2008.
[5] Dane, E. “Reconsidering the trade-off between expertise and flexibility: A cognitive entrenchment perspective.” Academy of Management Review, 35(4), 579–603, 2010.
[6] Duncker, K. “On problem-solving.” Psychological Monographs, 58(5, whole no. 270), 1945.
[7] Kuhn, T. S. The Structure of Scientific Revolutions. University of Chicago Press, 1962.
[8] Nickerson, R. S. “Confirmation bias: A ubiquitous phenomenon in many guises.” Review of General Psychology, 2(2), 175–220, 1998.
[9] Janis, I. L. Victims of Groupthink. Houghton Mifflin, 1972.
[10] Edmondson, A. C. “Psychological safety and learning behavior in work teams.” Administrative Science Quarterly, 44(2), 350–383, 1999.
[11] lateralworks. “Challenge the assumptions: A simple introduction to the challenge process.” lateralworks.com, 2026.
[12] lateralworks. “Three teams, three breakthroughs.” Case studies, lateralworks.com.