Most delivery pain is misdiagnosed. A team buys a pipeline platform and expects lead time to collapse; it barely moves. Another stacks two approval layers on top of every deploy after a bad outage, and failures climb instead of falling. The tool was never the disease. What is missing is a diagnosis. DevOps supplies one: a repeatable method for tracing a symptom back to its cause and prescribing a fix that fits it. What follows is that method, run against the four complaints engineering leaders raise most often, with an eye on the monitoring and AIOps stack this site usually writes about.

The Intake: What DevOps Is Supposed to Deliver

Definitions first, because a wrong definition produces a wrong prescription. DevOps pulls building and running a product into one loop: shared goals, shared tooling, shared feedback, so changes land with users fast, safe and time after time. It is no product, no job title, and no department you can staff. When someone declares that “our DevOps isn’t working”, the real question is which of those three shares has broken.

To locate the break, use the instruments from the DORA research programme. The original quartet tracked the wait from commit to production (lead time), how often changes shipped, how fast service returned, and how often changes broke things; in 2024 a fifth joined them — rework rate, which counts how often finished work returns for redoing. In 2023, recovery got a narrower reading: only failures the change itself caused now count. Five numbers, one baseline, and every case below becomes easier to read.

Case One: Work Sits for Weeks After Merge

Symptom: code merges on Monday and ships the following sprint. The reflexive fix is a faster build server. The actual culprits are usually batch size and wait states — branches that live for weeks, manual sign-offs waiting on whoever is on leave, test environments queued behind three other teams.

Prescription: move to trunk-based development with short-lived branches, build each artifact once and promote that same artifact through every environment, and run a value stream mapping session to expose the queues nobody owns. Point the first improvement at feedback speed: a commit should return a test verdict in roughly ten minutes. Small batches travel faster than hero merges. They always have.

Case Two: The Same Incident Keeps Coming Back

Symptom: the change failure rate stays high and restoration drags on for hours. The reflexive fix is more approvals, yet DORA’s data links heavyweight change advisory boards with worse performance, not better. Gates catch the changes that would have passed anyway and slow everything else.

Prescription: rehearse recovery until it is boring. One documented team saw deployment d06 coincide with a 4% spike in payment errors; the rollback had never been practised, so service took 190 minutes to restore. After drills, comparable recoveries ran about 20 minutes. Four moves make up the routine: name the deployment and the person accountable for it; reverse it while no irreversible migration is in play; where reversal is off the table, switch the feature off or carry the fix forward; and convene a blameless review inside five working days. Culture is part of the cure — a punitive response teaches people to hide small failures until they become large ones.

Case Three: Finished Work Returns for Rework

Symptom: the rework rate runs hot. Code is declared done, then done again. Root causes cluster around late testing, vague acceptance criteria and split ownership between the team that wrote the feature and the team that found out what it should have done.

Prescription: pull verification forward. Acceptance criteria become automated checks that run inside the pipeline. Canary releases expose each change to a sliver of traffic first, so a flaw greets a hundred users rather than a million. Feature flags let you silence a misbehaving path without a redeploy. CALMS — Culture, Automation, Lean, Measurement, Sharing — offers useful shorthand here, because chronic rework is almost always a Sharing failure: the person who knew the requirement never saw the build.

Case Four: Alerts Nobody Trusts

Symptom: pages at 3 a.m., most of them ignored. Root causes: alerts tuned to machine thresholds instead of user-visible symptoms, and metrics repurposed as targets — leaderboard culture guarantees gamed numbers within two quarters.

Prescription: alert on what a user would feel, route it to the team that owns the service, and audit alert noise every quarter. This is where AIOps earns its keep — anomaly detection and event correlation can compress hours of log-reading into minutes. Treat it as a sensor and an actuator, not a doctor, and give the automation guardrails: least-privilege access plus credentials that OpenID Connect mints fresh for each job, so your clever remediation bot cannot become the next incident.

Referrals: Conditions That Mimic Delivery Problems

Two misdiagnoses deserve their own note. The first is the claim that a regulated industry cannot work this way — that compliance forbids fast, safe change. The evidence runs the other way: the controls auditors ask for map neatly onto automation. Least-privilege access, credentials that expire in minutes because OpenID Connect issues them per job, migrations written to expand and then contract, and spot-checks each quarter covering ten or so changes chosen at random give an auditor a cleaner trail than any meeting queue ever did. Regulated teams ship continuously all over the world; the paperwork was the excuse, not the reason.

The second is the belief that the practice demands a particular architecture — that microservices and Kubernetes are entry requirements. They are not. Teams running modest monoliths on unglamorous virtual machines reach top-quartile delivery when flow and feedback are healthy, and teams running fashionable distributed systems miss every target when those are not. Architecture follows the organisation, as Conway observed back in 1968; it does not rescue one. Prescribe structure for the problem at hand, never as a cure for delivery.

• Metrics improve while users report the same problems — you are measuring the wrong layer.
• Only one team can explain the pipeline — knowledge is hoarded, and Sharing is broken.
• Every proposed fix arrives as a purchase order — tool-first thinking has replaced diagnosis.

The DevOps Discharge Summary

Run the cases in order: measure, locate the constraint, change one thing, remeasure. Expect the J-curve: early wins, a trough while automation lifts the testing bar, then the climb — and agree upfront how long the trough may last, because an unbudgeted dip is how transformations get cancelled. Skip the big-bang programme; a coached pilot on one value stream reliably beats an organisation-wide mandate, and the adoption research bears it out. For the frameworks and the history — from Conway’s paper of 1968 through the AI-era findings of 2025 — xOps School’s DevOps reference page stands as the fullest free treatment this writer has found.

If you are building the skills side, the DevOps engineer roadmap lists what to learn first, while this enterprise guide to modernising an IT team covers the organisational half. And once anomaly detection enters the picture, this overview of AI in IT operations is a fair on-ramp. Diagnosis first, prescription second, tools last — and only where they serve both.