https://cutlefish.substack.com/p/tbm-290-the-dependency-threshold
There’s a point beyond which no individual, no team, and no company can solve the dependency and constraint puzzle using brute-force methods.
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.
Now imagine that this percentage is more like 25%. Very quickly, the constraint satisfaction problem becomes an order of magnitude more complex.
What might a heuristic approach look like in product development?
- Reducing work-in-progress limits
- Force ranking priorities
- Weighted-shortest-job-first
There (is) 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. 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.