Anyone can stop a release
Not 'anyone can raise a concern which is then weighed'. Anyone can stop it, and no one has to justify having done so afterwards.
This sounds expensive and is not, because the failure mode it prevents is the one that actually costs money: the person who noticed something at four in the afternoon, was not sure, and said nothing because the release was already scheduled.
A team that can stop a release cheaply stops it rarely. A team that cannot stops it never, which is a different thing entirely.
Correct beats fast, as a process
As a slogan this means nothing everyone agrees with it in the abstract and nobody agrees with it at five o'clock on a Friday. It only means something if it is encoded in what the process actually permits.
Concretely: review is a real gate rather than a formality, and reviewing means running it, not skimming it. The reviewer's job is to find the case the author did not think about, and a review that only comments on style has not been done.
Some weeks this is slower. That is the trade, made deliberately, in a domain where the software is used by people who cannot check its working.
Migrations are the sharp edge
Application code can be rolled back. Data usually cannot, which makes schema changes a different category of risk that deserves different handling.
So migrations are written to be separable from the code that needs them: add the new structure, backfill, switch reads, then remove the old as separate steps that are individually safe rather than one change that is only correct if it completes.
They are also tested against a realistic volume. A migration that takes four seconds against a development database and locks a table for eleven minutes in production has not been tested; it has been observed.
Rollback is a design decision, not a button
Every change gets the question asked before it ships: if this is wrong in an hour, what do we do. If the answer is 'roll forward and hope', the change is not ready.
That question tends to change the design rather than just the plan. Features get built behind a switch. Interfaces get versioned. Destructive operations get staged. None of that is exciting and all of it is the reason the release is boring.
The flaky test is a real bug
A test that fails one time in twenty is worse than no test, because it trains the team to ignore a red build. The moment 'just re-run it' becomes normal, the suite has stopped being a signal.
So flaky tests get fixed or deleted, and fixing them is treated as ordinary work rather than a chore somebody does when they have spare time. Nobody has spare time.
Watch it after it lands
Shipping is the middle of the process. The period immediately after a release is when the useful information arrives, and somebody has to be actually looking rather than nominally on call.
What we watch for is not just errors errors are the easy case. It is the quiet signals: a step that has started taking longer, a path that has stopped being used, a value that is now empty in ten per cent of records. Those are how a real problem announces itself before anyone files a ticket.
If any of the above matches a problem you are dealing with, we are happy to go deeper than a blog post reasonably can.