Hospital boards ask better questions than their IT functions usually answer. Having sat through a number of these sessions for clinical groups — spine units among them — we collected the seven DevOps questions that recur in every governance meeting and answered each one the way the evidence supports, not the way a vendor would. Definitions follow the Ops Atlas DevOps entry where terminology matters.
What is DevOps, in language a board understands?
It is an operating model for software delivery in which the builders of a system and its operators work to common goals with common tools and open feedback, so improvements reach staff and patients quickly, safely and repeatedly. It is not something you buy, not a job title, nor a department. The analytical framing researchers use is the “three ways”: let work move forward in small pieces, shorten the feedback loop from live systems back to builders, and make learning continuous rather than episodic. CALMS adds the standing checklist — culture, automation, lean, measurement, sharing — that tells you whether the model is actually in place.
Is DevOps the same thing as SRE?
Close cousins, different remits. SRE, which grew out of Google’s operations practice, concentrates on reliability: error budgets, toil reduction, and the SLOs that define how much unreliability a service may carry. DevOps is the wider delivery model — it concerns the whole path from idea to production, of which reliability is one concern. In practice the disciplines reinforce each other, and many hospital groups run SRE practices inside delivery teams rather than as a separate caste. Treat the boundary as one of emphasis; the argument about which is “bigger” produces heat and no outcomes.
Which DevOps delivery metrics deserve board attention?
Five, and only five, belong on the first page. Lead time for changes: the wait between an agreed idea and its arrival in front of users. Deployment frequency: the cadence of releases. Time to restore: the stretch between a failure and normal service returning. Change failure rate: what share of changes cause problems. And rework rate, added by DORA in 2024, which measures how often supposedly finished work must be redone — the earliest sign that velocity is being borrowed from quality. Note the refinement: since 2023, recovery is measured against change-caused failures only, so an unrelated power cut cannot flatter the score. Boards should see these as a profile rather than demand excellence on every line simultaneously; the research shows strong teams trade deliberately between them. One governance caution belongs in the same minute of the meeting: none of the five belongs in an individual performance review. The figures describe a delivery system, and the moment they decide bonuses they stop describing it honestly — teams hide failures, split changes to inflate frequency, and the board ends up reading fiction at premium prices.
Do we need to re-platform onto Kubernetes first?
No, and treating it as a prerequisite is one of the costlier errors in the field. The delivery research finds no requirement for microservices or Kubernetes; high performance tracks working habits, not infrastructure diagrams. Small batches, trunk-based development, automated tests and reversible deployments produce the outcomes. Re-platform when a specific, named reason exists — a scaling limit, a support deadline — and after the delivery habits are sound. A group that rewrites its patient portal before fixing its release process simply runs the new portal through the same broken queue.
Can a hospital be both compliant and fast?
Yes, and the combination is well documented in regulated industries. The mechanism is automation of the controls themselves: least-privilege access rights, short-lived OIDC credentials replacing standing secrets, expand-and-contract schema migrations so reversibility is preserved, and quarterly audit sampling that reviews roughly ten randomly selected changes for evidence. Break-glass merge routes stay open for genuine emergencies but fire alerts the moment they are used. These controls are exercised on every change rather than inspected once a year, which is precisely why auditors increasingly prefer them. Heavyweight change-approval meetings, by contrast, correlate with worse delivery in the research — they slow everything and catch less. Culture decides how much of this works: Westrum’s generative organisations, where bad news travels fast and without punishment, adopt automated controls easily, while bureaucratic cultures turn the same controls into theatre.
What actually happens when a release fails?
In a mature group, the runbook runs itself. Each release goes out tagged with an identifier and a declared owner. If the change is reversible — no irreversible migration has run — it is rolled back; otherwise the feature is toggled off or fixed forward. A blameless review is published within five working days. The value of rehearsal shows up starkly in the recorded cases: one deployment, d06, sent payment errors up by four percent, and the unpractised rollback consumed 190 minutes; drilled in advance, the same manoeuvre finished in about twenty. Two hours of downtime in a booking system is not an engineering statistic; it is a front-desk story.
How should DevOps adoption be sequenced?
Start with one value stream and an enabling coach. The adoption comparison is unusually decisive: coached pilots scored 4.25 out of 5, while a central toolchain-first programme managed 2.40 and an organisation-wide mandate 2.50. A workable first quarter follows the 90-day roadmap: see and stabilise the chosen stream, automate its path — one build, one rehearsed rollback, feedback inside about ten minutes — then govern and spread what worked to a second team. Expect the J-curve: quick gains, then a dip as automation raises testing requirements, then a higher plateau. Agree the acceptable dip duration in writing before starting; groups that did stayed the course.
What should we stop doing immediately?
Four practices, all documented anti-patterns, all common in clinical IT:
- The permanent “DevOps team”, which quietly rebuilds the wall the model exists to remove.
- Metrics-as-targets leaderboards, which teach people to flatter the numbers instead of improve them.
- Adding approvals after every incident, which grows batch size and thereby manufactures the next incident.
- Big-bang programmes announced by memo and long-lived branches that park changes in limbo for weeks.
Maturity is climbed, not declared — the recognised ladder runs siloed, then automated islands, then integrated, then continuous delivery, with a learning system at the top — and each rung is earned by evidence rather than by announcement. Retiring the four habits above, notably, costs nothing at all, and most groups see the measurement improve within a month of doing so. For readers who want the adjacent disciplines mapped, our guides to DevOps, Kubernetes and SRE for enterprises and to the XOps family of IT operations disciplines place this model in its wider context.
Where should a board look first?
At the queue, not the tools. Ask for the value stream map of one recent patient-facing change and count the days it sat still. Ask who owned the last deployment and whether the rollback was rehearsed. Ask for rework rate by name. The answers will locate your organisation on the maturity ladder within an hour — and unlike a strategy deck, none of those answers can be produced without the truth. Groups that start there, pilot with a coach, and let evidence recruit the second team tend to find the remaining questions answer themselves within a quarter or two. Boards do not need to understand pipelines; they need to insist on the measures, the rehearsal, and the blameless review — the three artefacts that make every other answer honest.