TBM 290: The Failure Threshold

(And why planning harder and trying to brute-force the problem will not work)

Product Nerds! Help appreciated 🙏. I’m trying to help solve a product puzzle for my friend Daniel (the founder of DoubleLoop). I’m also an investor. Oddly, in the last month, Dan and team have been getting a lot of traction for a completely new use-case involving sales/CS teams wanting to link their product’s value prop to customer strategies and goals. Very unexpected.

So here’s the puzzle: why now?

DoubleLoop is a three-year old product. Existing customers are primarily product teams. Is this the economy? Is something going on B2B SaaS? With GTM teams? An unmet need or gap in current GTM tooling?

If you have a moment, check out this 3m video to understand the use-case. And then if you have a moment, share your hot-take here.

I really appreciate it. On to this week’s post…

---

There’s a point beyond which no individual, no team, and no company can solve the dependency and constraint puzzle using brute-force methods.

Something has to give.

As constraints and dependencies grow, many problems transition from being solvable by “just trying and planning harder” to becoming so complex that approaches useful for static optimization no longer work.

Imagine a company where 10% of the work involves multiple teams, touches different codebases, requires careful coordination, and requires frequent meetings that span organizational boundaries and challenge local incentives. This situation might still be feasible. It'll be painful and may involve some heroics, but there's a path forward.

Since we can never perfectly align our strategy with our org chart and architecture—in fact, overfitting our org design is an anti-pattern—it's reasonable that some percentage of efforts will fall into this category.

But imagine that this percentage is more like 25%.

Very quickly, the constraint satisfaction problem becomes an order of magnitude more complex. If someone tries to solve the problem with more accurate estimates, more careful timing of handoffs, more pristine operational plans, more multi-tasking, more carefully orchestrated meetings, and more "brute force" planning and supervision, they will likely fail.

This isn't a skill thing. It's a math thing. Failure is imminent. Something has to give. You can plan a meal for a couple of people by considering all the details. You'll never plan the "optimal" meal for fifty people unless you hold some things constant.

My ongoing joke here is to ask teams to predict the chance of success here:

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.

Yet it is precisely in these situations where leaders expect middle managers and upper managers to do more trade-off acrobatics (more "brute force") and somehow get everything done instead of deploying approaches more fitting for dynamic optimization problems (such as heuristic-based approaches).

What might a heuristic approach look like in product development?

• Reducing work-in-progress limits is a classic heuristic approach. Instead of trying to assemble the perfect Tetris board with no empty slots/squares, we agree to undertake only so many of these large, thorny efforts simultaneously.

• Force ranking priorities is another valid approach. If you can work on a higher-ranked item, do so. If you can't, get out of the way and rinse/repeat for each priority area in order.

• Weighted-shortest-job-first is a reasonable method for maximizing the throughput of value by prioritizing work with the highest opportunity costs that we believe can be completed quickly. (An aside, teams often fret way more about the estimate for work completion than they do about opportunity costs, which is a big mistake).

With these approaches, is there a chance that teams will miss an opportunity to find an optimal solution? Yes. But the probability of that happening is far outweighed by the likelihood that 1) bad things will NOT happen, and 2) good things may emerge.

The trouble, I believe, is that it can be incredibly hard for managers to make the case for, on the surface, doing less. Heuristic solutions feel almost like cheating. We hold out hope in the very small chance that we can thread the needle and somehow find an optimal solution. "It can't be as easy as limiting work in progress?!" says the manager, "All of my fellow managers are putting together rigorous plans with deadlines, deliverables, and assignments!"

Discussions about WIP limits and prioritization often devolve into debates over the actual WIP limit and precise estimates! Instead of seeing the forest through the trees, we obsess about finding the optimal answer.

Humans love to hold out hope, even when failure is guaranteed.

Some questions to consider:

1. Is your organization above or below the "failure threshold," at which point you start having an unsolvable (by brute force) problem on your hands?

2. Are managers in your organization incentivized to appear rigorous at the expense of actual outcomes? What is the net impact of those incentives?

3. How does that work if you routinely ask managers to "play Tetris"? Does it help? Is it paying off?

4. Do managers know and appreciate the various heuristic approaches?

5. How might you introduce heuristic approaches safely in your organization? Who needs to buy in?

6. How might you shift your design or architecture to eliminate some areas of friction permanently?

7. Similarly, how might you simplify your business model or strategy to reduce the need to do so much at once?