TBM 378: How To Effectively Pitch Constraints

Time to crack open the crazy Miro board!

Mapping Company Operating Systems (FREE, 90 Minutes)
Sep 18, 2025 08:00 AM Pacific Time | 4PM London
In this session I will describe various techniques for mapping your company operating system. We will explore different "frames", visualization approaches, and core concepts. I'll leave a full thirty minutes for questions.

---

And now on to our regular programming…

One of my biggest personal career challenges has been advocating for the smart use of constraints. I strongly believe in concepts such as work-in-progress limits, planning-in-progress limits, force-ranked prioritization, getting extremely crisp on ICPs, zero-bug policies, andon cords, having a single roadmap (not two, one for engineering and one for product), "start together", maximum initiative sizes, etc.

For whatever reason, I'm wired to advocate for enabling constraints. Maybe you are too! Or you aren't, and get annoyed by people like me. In which case, this post might also be interesting.

In this post, I try to move beyond the logic of constraints and get into the messy reasons why people resist the idea of constraints and what you can do about it.

Some Examples

Let's get started with some examples. As you read these examples, consider why teams were met with constraint resistance.

WIP Limit Debate

I tend to advocate for WIP limits. Managers (and leaders) challenge me by asking, "What if we could do more stuff while blocked?" or "How about when people want to multitask?"

To them, the constraint seems forced and arbitrary. To me, it looks like a catalyst.

To them: just another rule, or something good people shouldn't have to think about. To me, it is a valuable, designed constraint we can use for continuous improvement.

To them, it is better to estimate, size, and try to fit it all in. To me: that's even more arbitrary! People are resourceful. If they do finish something, they'll figure out what to pick up next.

Discovery WIP Limit Debate

I met a team recently with a cool constraint/forcing function. At any given time, the team limits itself to doing discovery on 2x the number of work items that typically kick off in a month. The 2x factor is based on the fact that they tend to discard ~50% of the things they research/assess. So if the group starts five things a month on average, they can only be doing discovery on ten opportunities.

The big challenge they initially faced with this scheme was that the organization was obsessed with long planning horizons and annual planning. All the incentives in the organization pointed to big discovery blocks to dream up work based on some kind of idealized, historically impossible flow of work. You had teams that started the year with a rosy picture of tackling 20 initiatives, and ended the year having finished 5, imagining that somehow they'd magically defeat the laws of physics and "sign up" for 20 again (involving a lot of discovery). Meanwhile, from a flow perspective, it was only really necessary to carry N things in the discovery column of their kanban board.

It took a lot of influence and persistence to shift the org to its new approach.

Prioritization Choice Debate

Or take the example of your average PM looking for leaders to make some hard decisions on prioritization (to create a constraint, essentially). When you enter these discussions, you try everything in your power NOT to go down the road of estimates, who works on what, etc. That never ends well—it ends up back where you started, wasting everyone's time.

Yet, from the leader's perspective, it feels completely natural to say, "Why not both?" We're wired to try to make it all work. "What if _______, and what if _________, if maybe we ________ and _________, then we don't need to decide between X and Y!"

So why does this happen?

These responses have as much to do with personality, experience, and decision-making styles as anything to do with logic or whether the constraint actually works. People vary in their comfort with abstract rules, their need for concrete details, their tolerance for ambiguity, and their willingness to accept external limitations.

Loss Aversion & Optimism

Leaders often resist constraints because of loss aversion. Saying "no" to a project feels like closing a door, and humans are wired to avoid that sense of loss. People will even waste resources just to keep options open, even if it makes the overall outcome worse. A broad heuristic, such as a WIP limit, directly challenges this instinct by forcing choices and making trade-offs explicit.

Leaders also routinely underestimate how long things will take and overestimate their team's capacity to do more with less. Optimism bias creates the belief that "this time will be different" or "our team is exceptional enough to defy normal limits." Constraints that point out realistic limits can feel unnecessarily pessimistic or restrictive. Combined with natural conflict avoidance, constraints often get dismissed as "too arbitrary."

Advocates of constraints aren't necessarily wiser; they've simply experienced enough of the upside to override the usual human biases. What once looked like a loss of options now feels like a gain in flow and clarity.

Comfort with Concreteness/Abstractions

Some people thrive on specifics; they want the details of exactly what initiatives or tasks are on the table. That's how they feel comfortable making decisions. A constraint like a strict work-in-progress limit might feel like just another rule to either follow rigidly or circumvent with detailed exceptions ("What if we do extra work when blocked?"). They'll resist a simple heuristic constraint unless you provide evidence and specifics.

On the other hand, some folks are more comfortable with ambiguity or with abstract thinking. They can operate on principles, on high-level concepts, and they don't necessarily need to anchor their decisions in the nitty-gritty details. A conceptual decision-maker or an analytical big-picture thinker may see the value in a constraint as an elegant principle or heuristic, and be willing to tolerate the ambiguity it introduces (trusting that it will pan out in the long run).

Experience

Experience cuts both ways when it comes to constraints.

On the one hand, seasoned people often see the value of a well-designed constraint because they've lived through the chaos that emerges without them. They recognize how a simple forcing function can free up attention, reduce waste, and sharpen focus.

On the other hand, that very experience can also make them skeptical. Having developed strong personal discipline, routines, and coping mechanisms, they may view external constraints as unnecessary training wheels or bureaucratic overhead that interferes with their judgment.

What feels like elegant design to one person can feel like condescension or red tape to another.

This duality means that experience doesn't map cleanly onto constraint acceptance or rejection. The same leader may embrace constraints in one context where they clearly unlock flow, and resist them in another where they feel imposed or artificial. A veteran may lean on them as enablers or dismiss them as shackles, depending on whether they think the constraint enhances or undermines their own hard-earned autonomy.

So what?

Hopefully, I've demonstrated that you can't just make a logical argument for using certain constraints. What makes sense and seems logical for you might be the exact opposite for someone else. In fact, it might be threatening!

To pitch a constraint, you have to move way beyond explaining why this book said this or that book said that. It doesn't matter if you have decades of queueing theory behind your case! It doesn't matter if you have math on your side!

Many managers resist constraints not because they fail to understand the logic, but because following an imposed rule threatens their sense of autonomy and competence. Resistance goes up based on the importance of the freedom being curtailed and the arbitrariness of the restriction. By their very design, many constraints ARE "arbitrary".

For a concrete-minded audience, provide concrete case studies and observable proof that the constraint works (speak their language of specifics).

For someone comfortable with abstraction, consider framing the constraint as a principle or heuristic to experiment with. They'll often accept the idea without needing every detail spelled out.

For an autonomy-driven audience, involve them in setting the constraint or emphasize how it empowers rather than restricts. Set an expiration date.

For highly experienced veterans, acknowledge their expertise and position the experiment as a mentoring opportunity: "You already know what good flow looks like — let's try this so others can see it too."

For the maximizing leader who insists on going over all the details and always asks, "Why not both?":

• Frame constraint as maximizing. Don't call it a constraint; call it the "optimal path" to get more done faster.

• Make it their idea

• Acknowledge their intent. They want to maximize value and not leave opportunities on the table. That is a valuable tendency!

• Try to make it empirical, not arbitrary. Frame constraints as efficiency experiments with measurable outcomes (e.g., "let's compare delivery time with and without a WIP limit").

• Show how "doing both" actually slows everything down (e.g., more items in play = longer cycle times, less throughput).

• Channel their thoroughness. Suggest a time-boxed sweep through all items, then agree to carry forward only the top N.