Define the Box
We love telling people to think outside the box.
Thinking outside the box implies that there is a box. A box that represents limits. A constraint to overcome. But we rarely define the box itself. And what we get in return is scattered thinking.
If you’ve ever run an open brainstorm, you’ve seen this play out. A hundred ideas pointing in a hundred directions. Some brilliant, most disconnected from anything the business needs. Evaluating them becomes political instead of purposeful.
Defining the box may feel limiting, but it helps channel creativity.
In my last post, I asked how we can build operational autonomy that survives a leadership change.
The concept of enabling constraints clicked for me.
As John Cutler puts it, enabling constraints are the fewest consistent rules that allow you to operate effectively. Zero structure is chaos. Maximum governance is bureaucracy. The minimum creates clarity and loosely defines the box. I’ve been building these for years without labeling them, and I’ve finally found a way to describe the pattern.
The Six Thinking Hats workshop I ran last summer is an example. Each hat constrains the mode of thinking — “right now, we’re all thinking about risks.” The constraint kept the loudest voice from dominating. It channeled the room.
Pre-mortems do the same thing. “Imagine this has already failed — why?” That single constraint inverts the default from launch optimism to structured skepticism. Once the vocabulary exists, people use it without needing permission. The language becomes the constraint.
Exoskeleton vs. Endoskeleton
Dave Snowden, who built the Cynefin complexity framework, draws a distinction that sharpened this for me.
A governing constraint is like an exoskeleton. Think of an insect’s shell — rigid, containing. The structure defines the shape. Things may change within it, but the structure itself doesn’t flex. It protects by enclosing.
An enabling constraint is like an endoskeleton. A spine. It creates coherence — we can stand upright, we can move — but it doesn’t contain. There’s enormous variation possible around it.
The question isn’t more rules or fewer rules. It’s whether the rules we have shape the behavior we want.
Constraints That Already Exist
We already work in a constraint system. Not all of them work in favor of our goals.
PI planning is a constraint system. Definition of ready before epics enter the PI. Say/do ratios at the end. Close your completed features for leadership reporting. It’s structural. It survives leadership changes. It applies to every team.
But it’s an exoskeleton.
What does it produce? People gaming the say/do ratio, committing to less so the numbers look good. Checking boxes on the definition of ready because the system won’t let you proceed without it, not because the thinking is ready. Closing features for optics, not because the outcome was achieved.
The official game runs. And dozens of unofficial games run underneath it: keep my manager happy, don’t miss the PI objective, protect my headcount. Nobody designed the actual game intentionally. It got designed by accretion.
What Enabling Constraints Look Like
In 2023, Shopify deleted 12,000 recurring meetings from every calendar across the company. New rules: no meetings with three or more people unless justified. No meetings on Wednesdays. The default flipped, from “let’s schedule a meeting” to “do we need to meet?” They didn’t tell people to be more productive. They removed the lazy option. Time in meetings dropped 33%, and estimated project completion went up 25%.
When Steve Jobs returned to Apple in 1997, the company had 350+ products. Jobs drew a 2x2 grid on a whiteboard (Consumer/Pro on one axis, Desktop/Portable on the other) and said Apple would make exactly four products. Everything else was cut. The rule: “If it doesn’t fit in the grid, it doesn’t exist.” Engineering resources concentrated instead of scattered. Every product team knew their mandate. There was no ambiguity about what Apple was building.
Neither of these prescribed what to do. They changed the conditions under which decisions get made.
Here’s one I’d design. Same PI demo ceremony we already run, same cadence, same audience. But instead of asking “what did you ship?” ask “what did you learn?”
That single question, asked consistently by leadership, would reshape more behavior than any training program. The constraint changes what teams optimize for.
Not All Constraints Are Created Equal
A constraint can be well-intentioned and still produce the opposite of what’s desired.
A leader recently proposed a threshold: the team shouldn’t work on anything that doesn’t deliver at least $5 million in impact. That’s simple and easy to apply. I can see the value as it forces focus on high-impact work and eliminates small-ball thinking.
But it has a blind spot. Ten improvements worth $500K each that together compound to $5M would each get killed individually. The constraint optimizes for big visible bets and kills the small ones that add up. Without systems thinking alongside it, the constraint produces the opposite of what’s intended.
The question isn’t whether to have constraints. We already have them. The question is whether they’re the kind that enable the outcomes we want.
From Local to System
I’ve been building enabling constraints for years without knowing what they were. The workshops, the pre-mortems, the thinking frameworks, all worked in the room. But because I couldn’t name the pattern, I couldn’t design them to survive beyond the session.
The system-level constraints, PI planning, and say/do ratios persist because the organization enforces them. They survive leadership changes. They apply to everyone. When constraints are designed intentionally at the org level, cross-functional teams can move in the same direction without needing someone to hold it together.
Enabling constraints also apply to how we are adopting AI right now. Everyone is moving fast, speed is the only metric, and we are solving the wrong problems faster. That’s another post.
Whether AI or not, we need to build the right box. One that channels creativity and innovation without chaos. A spine, not a shell.
The constraints already exist. We can’t redesign the ones we can’t see. The question is whether we designed them, or they designed us.