In a well-functioning company, I don't need to make that decision myself, of course: I have management who has evaluated the cost of having the bug and the benefit of having the feature, or who's experienced and smart enough to determine whether doing the short-term thing now or investing in the longer-term thing will be likely to have better payoff. Because this process is there, if I trust my management, I don't have to spend-time second-guessing them (or worse, doing the research myself), and then I get to move quickly. But again, moving quickly isn't the point. It's a tool on the way to delivering value.

Exactly right. Frequently, in industry, I see people confuse the "slow" and "competent" bits. They think that just because a given change needs to get a bunch of sign-offs that the overall effect of the system requiring the sign-offs is a net benefit to the organization.

It's not. It's paralysis, and you won't notice how ungainly and slow you've become until a different org a tenth of your size manages to clone your entire feature set in a hundredth of the time it took you to develop it, all because your developers have to deal with bullshit all day long and your competitor's can just act.

A lot of people will claim that you need gatekeeping and approvals and such to maintain a rigorous standard of quality. You have to be brave enough to disregard their advice. You have to be able to take the gut-wrenching step of saying, "No. We're not doing that. I don't care if this change caused a SEV, we're not adding process. Moving fast is important!".

It's very easy to believe the nostrum of "no pain, no gain". But sometimes you have to realize that pain is just pain.

The moment that some minor disaster hits, which it inevitably will, whoever is in charge will find themselves no longer in charge.

I think this is one of the fatal flaws of a big company. Everyone is terrified of risk. I'm not sure it's possible to counteract this tendency unless the company was built from the ground up not to punish risky behavior (e.g. Facebook, supposedly).

Enabling people willing to act is important though and I fully support the do nothing aspect of failure, or better yet support and stabilize but not reward.

I think that's the key thing here. Rather than saying "whether you succeed or fail, you're still gonna get your $250 bonus", you're saying "if you try and succeed, you get $500- if you try and fail, you get $100, if you don't try at all, you get nothing."

I admit to inheriting a fairly smart-risk-accepting technical culture, but also worked to extend and cement that by holding regular blame-free post-mortems on production problems and reporting them weekly to our business operations meeting. Making failure and the analysis/correction thereof a regular part of company operations makes it normal, accepted, and less scary. We would also pretty regularly respond to asteroid-type production problems with "no preventative action intended; cost of prevention exceeds expected losses". (We held a view that there is [conceptual process] green tape and red tape; make sure if you're fixing problems with process that it's actually green tape and if fixing a problem required adding red tape to the system, we were very skeptical and tended to avoid adding that process/step/gate/check.)

Couple that mindset and transparency with a metrics-supported track record of making things better overall and management will support. I'm not sure our CEO ever saw any of that sausage-making, except for the very largest or most damaging problems and even then, it was mostly a courtesy message to him. He cared about the overall pace and metrics, not how many outages or bugs we had along the way.