Good aesthetic outcomes come from the repetition of small, standardised movements, not from one dramatic operation. The same is true of the software that runs a hospital group. The teams whose systems never make the news are not luckier; they practise a short list of DevOps habits until the habits are boring. Boring, in delivery work, is the compliment.
What follows is that list, written for the people who run the booking systems, photography archives, consent forms and follow-up portals behind a modern clinical group. Each item is specific enough to check for, and each one has a failure mode you will recognise if your organisation lacks it.
Habit one: merge small, merge often
High-performing teams keep branches short-lived and merge into a shared trunk many times a day. A change that touches one screen reaches review while the context is still fresh. Contrast this with the branch that lives for six weeks and returns as a merge conflict no one can safely resolve. Long-lived branches are the single most reliable predictor of a painful integration, which is why they appear on every list of anti-patterns you will find.
Habit two: rollbacks are rehearsed, not improvised
Each deployment goes out with an identifier and a named owner, and the team knows in advance whether a reversal is safe. If the change includes an irreversible database migration, the fallback is to turn the feature off or fix forward; otherwise, roll back. The difference between practised and unpractised is not subtle. One documented case — deployment d06, which sent payment errors up four percent — saw an unrehearsed rollback take 190 minutes. The same manoeuvre, rehearsed, took about twenty. Consider how a cosmetic group would feel about a two-hour booking outage on the busiest Saturday of the season, with the reception desk fielding calls the whole time.
Habit three: feedback arrives in roughly ten minutes
From commit to test result, the loop should be measured in minutes. Beyond that threshold, developers context-switch, batch their changes, and stop trusting the pipeline. Fast loops are why DORA’s lead-time measure responds so strongly to build hygiene. If your suite takes forty minutes, split it: the fast core runs on every commit, the slow end-to-end set runs on a schedule. Rule of thumb: when the suite complains about running in parallel, that complaint is the next bottleneck on the list.
Habit four: features ship dark behind flags
A feature flag lets code reach production weeks before the feature is visible. Decoupling deploy from release removes the scariest part of launch night. It also gives clinical and commercial stakeholders a dial rather than a cliff — a handful of clinics first, then the region, then everyone. Recovery advice follows from this too: when something misbehaves, toggling a flag is often faster and safer than any redeployment.
Recovery itself deserves staging, much like aftercare. Our explainer on what to expect during each healing stage makes the same point in a clinical register: milestones decided in advance beat improvisation under pressure.
Habit five: databases change in expand-and-contract steps
Schema changes are split into an expand phase, which adds capacity without breaking the old code, and a later contract phase, which removes it once nothing depends on the old shape. This is what makes rollbacks safe and deployments boring. The alternative — one sweeping migration that cannot be undone — is how a routine Tuesday upgrade becomes an incident with stakeholders in the room.
Habit six: credentials expire by design
Pipelines get least-privilege access, and long-lived secrets are replaced with short-lived tokens issued through OIDC. An attacker who steals a credential that expires in an hour has stolen very little. For a hospital group, this is the quiet half of compliance: controls that hold on an ordinary Wednesday. Our companion piece on building secure delivery pipelines with DevSecOps and DevOps extends this into the wider security picture.
Habit seven: reviews are blameless and prompt
After an incident, the team publishes what happened, when the owner was declared, and what the recovery path was — without hunting for a culprit. The review lands within five working days, while memory is reliable. Blame produces concealment; concealment produces repeat incidents. Generative cultures, in Westrum’s terms, surface bad news early, and that is the entire trick.
Habit eight: honest DevOps measures
Five numbers do most of the work: how long a change takes end to end, deployment cadence, recovery pace, what share of releases misfire, and rework — which DORA added in 2024 to catch silent redoing of work. Since a 2023 refinement, recovery counts only failures a change caused itself. That is the dashboard. Leaderboards that rank individuals on these figures are a documented anti-pattern — measurement framed as a target invites the number to be gamed. For a careful tour of the framework and its vocabulary, the Ops Atlas DevOps guide is the reference we hand to new team members.
Habit nine: culture is engineered, not assumed
CALMS remains the most compact checklist in the field: culture, automation, lean, measurement, sharing. Notice that only one of the five letters is about tools. Teams that score well on delivery surveys talk to each other across old boundaries, delete steps that add no value, and treat sharing as part of the work rather than an interruption to it.
How the nine habits hold each other up
These are not nine independent initiatives; they are one system seen from nine angles. Short-lived merges make ten-minute feedback possible. Fast feedback makes small batches rational. Small batches make rollbacks and expand-and-contract migrations survivable. Flags make recovery instant, which makes blameless reviews honest, which keeps the five measures truthful — and truthful measures are what let governance move inside the pipeline, where auditors can sample ten or so random changes per quarter instead of obstructing every release. Remove one habit and the others strain; add them together and delivery stops being the part of the hospital that everyone apologises for. That is the quiet argument for treating DevOps as a set of daily behaviours rather than a project with an end date, and it is why the habits survive leadership changes while programmes do not.
Adopting DevOps habits without a big bang
Two closing cautions. First, avoid the permanent “DevOps team” — the phrase names a way of working, not a department, and the evidence is unkind to groups that hoard it. Second, agree up front how long a performance dip is acceptable when automation raises the testing bar; teams that set that expectation in advance ride out the J-curve, and teams that do not abandon ship in the trough.
- Pick one service — clinic bookings, for instance — and check it against all nine habits this week.
- Rehearse one rollback and time it; the number will start the conversation.
- Measure the commit-to-feedback interval once and write it on the wall.
- Put a quarterly reminder in the calendar to re-score all nine; habits drift when nobody looks.
Standardised checklists, rehearsed recovery and honest measures are how clinical groups keep patients safe, and our guidelines for safe chemical peel and laser treatment care follow the same logic. Software delivery is simply the same discipline applied to code — and, done properly, it stays out of the way of the people doing the real work. Start with whichever habit your last incident made painfully relevant, and let the rest follow.