The concept of an “iron triangle” is an old one. In project management, it’s the trade-offs between cost, schedule, and scope. “Pick any two” is a common rule of thumb — that is, you can optimize for two but not three.

One variation on the triangle is cost, schedule, and quality (scope is replaced by quality). The sign below (via Flickr) is a well-known version:

When DevOps arrived, however, it seemed like the iron triangle had run its course. DevOps-aligned organizations were delivering software better, cheaper, and faster — all at once! Sometimes, breakthroughs happen.

But as DevOps has matured and evolved into product-centric organization transformation, a new iron triangle seems to be emerging. It starts, innocently, with agile and DevOps values:

  • Teams should be autonomous.
  • Teams should be “two pizza” in size (6–10 or so).
  • Teams should be persistent; they should not be routinely broken up and reformed (in comparison with some project management models).

These three values will have many of you nodding your heads. We’ve all heard them.

But they are contradictory. Pick any two:

If your team is small and long-lived, it will have significant external dependencies. You’ll be dealing with coordination and queueing issues to access external services essential to delivering an outcome. This is exactly the problem various customers of mine are now struggling with in their operating models. Automation is the preferred response, but numerous in-depth customer engagements have convinced me that there is always a residual set of human-based dependencies that can cause problems.

If you want to prioritize “small and autonomous,” you will be rotating people on and off the team. Sure, you can onboard necessary expertise, but if you want to keep your team at an optimal size, you have to rotate someone else off. This has a downside in terms of the team culture, trust levels (i.e., psychological safety), and for overall team effectiveness that comes with deep understanding of colleagues’ knowledge, skills, and attitudes. (I’m reminded of Will Larson in An Elegant Puzzle — “High-performing teams are sacred, and I’m quite hesitant to disassemble them.”)

Finally, if your team is to be long-lived and fully autonomous, it will be larger than two pizzas can feed. You’ll probably wind up with sub-teams and coordination problems and perhaps an overall product manager with too much on their plate. I’m hearing multiple cases of this as large IT organizations experiment with outcome orientation.

There are many responses: automation (as mentioned) and T-shaped professionals, for example. But in complex and highly scaled environments, these are limited. Automation helps, but it is not a silver bullet. Sometimes, the dependencies are on expertise (e.g., security consultation) that cannot be easily automated. And sometimes the problems are harder than a T-shaped professional’s searching on Stack Overflow can answer.

So my view is that there is no “solution” to this. It’s the design trade-off for product-centric organizations. I’m very interested in how you’re navigating these! Please reach out or schedule an inquiry if this is something you’re actively working on.