This is fixed by putting a dollar number on outages, and a seperate dollar number on process. Ie. "if each release has an extra day of tests and checks, then it will delay our hockey stick growth curve by 10%. Thats worth $X".
Turns out, it's usually better to be fast and break things, over trying to be reliable.
> Turns out, it's usually better to be fast and break things
In terms of # of correct guesses, sure. In terms of damage from guessing incorrectly over time, usually not.
The trick is to separate processes - A CSS update probably isn't very risky, and an auth or login update probably is. Don't bundle them into "website updates".
Run ahead with the layout changes and spend some time on failure-planning for the auth change.
Precisely this. The "move fast and break things" mantra came from a context where there were no users for the product yet and the people most inconvenienced by breakage are your own. It's a mantra saying "Don't worry about screwing up the UI team with a DB migration if it takes only five minutes to reverse the migration or ten minutes to tweak the UI; you can hash it out together and get back to work on the real problem." It's a reminder that exposing yourself to a little more pain now gets you to viable product faster, and the faster a startup gets to viable product, the likelier it is to take off before it hits the end of its runway.
It is not to be applied to destructive changes to systems users care about, and none of the companies named in the 2017 book by that title use that engineering tactic on their flagship products because real people care now.
Turns out, it's usually better to be fast and break things, over trying to be reliable.