TBM 238: Spinning Plates

...and enabling constraints

I have a full day of errands, and a friend asks me to stop by for fifteen minutes to pick up a piece of furniture they're giving away. Immediately, my brain goes into replanning mode. What if I cut my lunch short a bit? Maybe there's a faster route between all the stores I need to visit. Why go to two stores when there's one that has both products, even if they're a bit more expensive? What if my friend leaves the furniture in the alley, and I pick it up later?

What am I doing?

Humans seem wired to want the highest ROI, the best gas mileage, and to "make every minute count." We are constantly prioritizing, route planning, doing cost-benefit analysis, delegating, and sequencing—sometimes consciously, often unconsciously. The challenge is that this backfires when it comes to product development work. The quest for efficiency and high utilization is the same thing that stifles creativity and innovation and paradoxically slows us down and makes us less efficient.

The example I mentioned above is similar to what goes through people's minds when trying to "get the most out of their team" (not my favorite phrase, by the way).

It starts subtly:

• "What if we ask teams to allocate 10% of their time to debt?"

• "I'm sure we can cut the scope to deliver both. Let's meet to talk about it."

• "We're blocked these days by the Voltron team—might as well spin up some new work."

• "The team is busy now. What if I meet with customers so that this project is ready for them to start working on it once they are done?"

• "Can we schedule a 'quick' meeting to brainstorm new features while we wait for approval on the current project?"

...and can get extreme (I'm exaggerating here, but sadly, this isn't that far off):

If George and Ina each allocate 50% time to Project Thunder, and then Lenny does 10% time combined with moving the two open reqs to Team Apollo and hiring those roles in the next two months, we should—if we sort of combine Project Thunder and Project Inferno—be able to finish Thunder, Inferno, and chip away at Homestead so that when The Hex Pistols are done with the event streaming re-architecture and Project Kafka-esque, assuming Xenia approves the design document, we should be able to hit the deadline for Project Sycamore as promised in the 2023 annual plan.

Sorry, Troy, Monika, and Rob (thread):

Sometimes, you can chalk this up to inexperience. It feels right, so people do it. Crank up the RACI…yeehaw! Sometimes, it is wishful thinking and eternal optimism—we've all been there. Sometimes, experienced leaders are under so much pressure that it temporarily clouds their judgment. "Saying No at the moment is not an option!" Even though they know in their hearts it will not work out, they figure that they "at least tried" and "maybe we'll finish 3 out of 5." Low trust pushes us to accept unwinnable games.

Finally, some people even glorify this thinking as a weird sort of pragmatism meets hustle culture. They see nothing wrong with it, and when people fail—there's a high probability they will fail—they act somehow surprised and blame the people instead of the sheer impossibility of the plan they encouraged. "You need to up your stakeholder management game! And you need to hold people more accountable!" 

When I coach product managers, one of the key things we focus on is building the "spidey sense" for when they are setting up an effort to fail by having too many drivers, too many limiting constraints, and not enough floats or enabling constraints (video). 

I've noticed that the "default" for most people is still too many drivers and too many limiting constraints, so I force them to think in terms of extreme focus and flexibility. "What if you could pick only one driver and one limiting constraint? What's the worst thing that could happen?" I do the same with teams struggling with flow and delivery by proposing radical enabling constraints. "What if we used one-day sprints?" "What if one month a quarter you did nothing but X?" "What if you reduce WIP by 50%?"

You can beat the bias by intentionally "shooting low" and nudging up. Teams are often surprised by how effective these unnaturally focused or deliberately constrained (enabling constraints) efforts are. Anyone who has been through a company emergency when everyone had to focus on X knows this feeling—people look back years later and yearn for that level of productivity and effectiveness.

This is the problem with asking teams to set "stretch goals" when they have trouble even hitting their "normal goals." If we're wired to take on too much, then "stretching" probably isn't the place to start. In companies, this kind of three-dimensional chess and "optimization mindset" becomes the norm, so balls are always dropping. When balls are always dropping, there's a culture of not catching. Instead, leadership rewards teams for throwing new balls into the air and even more impressive attempts at juggling.

So the upshot here is:

• Humans love to optimize

• In certain contexts, it gets us into trouble.

• Lack of experience, optimism, pressure, trust, and worldviews/work views exacerbate the problem.

• Company culture can reinforce the problem.

• While we can never be immune from our biases, there are things we can do to try to reset.

• Experiment with radical enabling constraints. What's the worst thing that could happen? In most cases, even if you overshoot, you'll be OK. Whereas the costs of shooting too high are always fairly catastrophic

• With experience, you can build a spidey sense for these issues.

Good luck!