zlacker

But if those two things (velocity and reliability) are at opposing ends of an engineering spectrum, then different teams will make different decisions about how best to trade one off for the other, and then the org as a whole is unfocused.

>>cecilp+(OP)
The problem is the thinking that there is some fixed bucket of speed and a fixed bucket of robustness ingredients and a fixed bucket of product output. That the only way to get any reliability is to displace some speed, or that if you want to move ahead at all you have to throw reliability out entirely.

When in fact these things, and 100 other goals and considerations like being green or hiring fairly or paying interns better etc... merely influence each other a little and don't preclude each other except at absurd hyperbolic extremes.

The different goals DO influence each other. But the output product can in fact have a whole bunch of both speed and reliability, probably at the expense of yet another dimension like cost, but actually the same applies there too, you can possibly have all 3, at least to some degree, if the leadership is insightful enough to figure out a way like employing underutilized people or geography, or gamification or crowdsourcing or alternative incentives, whatever.

Pay more or sacrifice in one dimension to get more in another is merely the obvious and easy way, not the only way dictated by some zero sum law of conservation.