DevOps Anti-Patterns & Pitfalls

What is DevOps? killed three myths up front — DevOps as a job title, DevOps as tools, DevOps as "NoOps." Those are the mistakes you make on day one, before you've shipped anything. This page is about the five that show up later, after a team has genuinely adopted CALMS on paper and still finds itself back where it started: a silo with a friendlier name, a fast pipeline running on top of the same slow culture, a "blameless" postmortem that still ends with a name, a stack copied from a company ten times your size, and a DORA dashboard nobody has looked at in months. None of these look like failure from the inside. That's exactly why they last.

Why these five are more dangerous than the three myths

☺ Like you're 10: The three myths are mistakes you make before you've built anything. These five are mistakes you make after you've built something real — which is exactly why they're harder to spot.

The three myths on What is DevOps? are easy to catch because they're visible from the org chart or the budget line: a "DevOps Engineer" req, a Jenkins license, a NoOps slide deck. The five traps below are harder, because each one survives an audit that only checks for the presence of a CALMS practice rather than whether it's actually doing its job. A team can point to a real pipeline, a real postmortem doc with "blameless" in the title, and a real DORA dashboard, and still be running the exact organizational dysfunction DevOps was invented to remove. Every trap below fails the same underlying test, worth carrying through the whole page: would this practice survive someone actually checking what happens next? A silo survives a re-org headline but not a count of tickets filed. A blameless postmortem survives a template but not a look at whether anyone's name shows up in the root-cause field. A DORA dashboard survives a slide in a QBR but not the question "what changed because of last month's number?"

1 · The "DevOps team" silo in disguise

☺ Like you're 10: Naming a team "DevOps" doesn't remove the wall between building and running software — it just moves the wall two feet over and paints the word DevOps on it.

Gizmo's whisper: "Nobody has time to learn Terraform and Kubernetes and on-call all at once. Let's hire a small, sharp 'DevOps team' to own the pipeline and the infrastructure, and everyone else just files a request when they need something." Why it tempts: it sounds like exactly what the Foundations page warned about, so a team that's read the warning feels immune — surely naming the team "Platform" instead of "DevOps," or giving it a broader charter, avoids the trap. It doesn't. Why it hurts: the third team accumulates the same properties as the two it was meant to dissolve. It owns the pipeline, so every other team's release now depends on its backlog. It owns Terraform state, so every infrastructure change is a ticket. Within a few quarters the org has recreated exactly the throw-it-over-the-wall dynamic from the wall of confusion — just with one wall instead of two, and a team whose job title makes the silo feel like the solution rather than the problem.

The mechanism is Conway's Law, covered in full on culture & collaboration: whoever controls the shared infrastructure becomes a mandatory communication path for anyone who needs to touch it, and a mandatory communication path is a queue whether or not anyone intended it to be one. A "DevOps team" that holds all the Terraform apply access, all the pipeline admin rights, and all the production kubectl credentials isn't spreading DevOps practice across the org — it's concentrating it in one place and calling everyone else a customer of it.

The fix: a team that shepherds shared infrastructure should build a paved road, not be the road. That means self-service by default — a Terraform module in a registry that any team can consume without a ticket, a pipeline template every repo inherits automatically, an on-call rotation the team that wrote the service actually carries — rather than a queue of requests only the "DevOps team" is trusted to execute. From DevOps to Platform Engineering covers the point where this tension gets resolved deliberately: a platform team is the same shared-infrastructure team, but its explicit charter is reducing other teams' toil through self-service tooling, not becoming the only team allowed to touch production.

2 · Tool-first thinking: buying a pipeline, keeping the incentives

☺ Like you're 10: Buying a faster car doesn't teach you to drive better — if you were already swerving, you now swerve faster.

Gizmo's whisper: "Procurement approved the enterprise CI/CD license. We're doing DevOps now." Why it tempts: a tool purchase is fast, visible, and doesn't require anyone to change how they work — no uncomfortable conversation about incentives, no reorg, no renegotiating what "done" means. It's the single easiest CALMS box to check, because it's the only one you can complete with a purchase order. Why it hurts: Automation is one letter out of five. Bolt a fast pipeline onto a team that still merges six-week feature branches once a quarter and you haven't fixed the batch-size problem — you've built a very fast conveyor belt for enormous, high-risk changes. The pipeline runs a build against a diff touching four hundred files, something breaks, nobody can isolate which of the forty commits caused it, and the team's response is more manual gates bolted in front of the tool they just bought: an extra approval step, a freeze window, a "let's be careful this time" Slack thread. Six months later the expensive pipeline runs slower than the manual process it replaced, because every stage now waits on a human sign-off the tool was supposed to make unnecessary.

# The tool-first trap, in a real GitHub Actions file: a fast pipeline
# wrapped in enough manual gates to cancel out everything it bought you.
name: deploy
on:
  push:
    branches: [release]        # a branch that only gets a diff once a quarter
jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test    # runs against ~400 changed files at once

  # Four sequential human sign-offs bolted on because nobody trusts a
  # test suite run against a quarter of untested, unreviewed changes.
  approve-qa:
    needs: build-test
    environment: qa-signoff       # environment protection rule = a human
  approve-security:
    needs: approve-qa
    environment: security-signoff
  approve-director:
    needs: approve-security
    environment: director-signoff
  deploy:
    needs: approve-director
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh prod
# The pipeline itself takes six minutes. Getting a change through the
# three environments in front of it takes four business days — because
# the tool changed, but batch size and trust didn't.

The fix: a tool only pays for itself once the batch size shrinks to match it. That means trunk-based development and short-lived branches (see version control & branching), automated test coverage the team actually trusts enough to remove a manual gate, and — the part that's easy to skip — someone with the authority to actually delete an approval step once it's no longer earning its keep. Measuring success: the DORA metrics found this exact pattern: elite performers deploy more often and fail less, because both come from the same underlying practice of small, frequent, reversible changes — buying the pipeline without shrinking the batch gets you neither.

3 · Blameless in name only

☺ Like you're 10: Writing "blameless" at the top of a form doesn't make the form blameless — what makes it blameless is whether a name ever appears in the box marked "root cause."

Gizmo's whisper: "Sure, we'll call it a blameless postmortem — but come on, we all know Priya pushed the migration without a review. Let's just write that down so it doesn't happen again." Why it tempts: naming the person who touched the keyboard last feels like the honest, direct version of events, and skipping straight to "who" is genuinely faster than the systemic question. It also flatters whoever wasn't holding the keyboard. Why it hurts: the moment a postmortem's "root cause" field contains a person's name instead of a system's gap, the practice has silently reverted from Westrum's generative culture back to a pathological or bureaucratic one — see culture & collaboration for the taxonomy, and the Etsy case study for where "blameless postmortem" entered the industry's vocabulary in the first place, and its own warning that the label is "easy to say and genuinely hard to sustain." Once one incident review ends in a name, the lesson every engineer in the room learns isn't about the system — it's that surfacing a mistake gets you singled out, and the next near-miss quietly goes unreported instead.

The fix: rewrite every sentence that names a person into a sentence that names a system. Not "Priya pushed the migration without a review," but "what made it possible to run a schema migration against production without a required review gate catching it first?" That single rewrite is the entire discipline John Allspaw's original "Blameless PostMortems and a Just Culture" post argues for, and it's exactly the drill on Drill — Run a Blameless Postmortem. Two organizational commitments make the rewrite stick rather than reverting after the first bad quarter: incident postmortems are never used as input to a performance review, and that promise is made by someone with the authority to keep it, not just written in a wiki page nobody with headcount decisions has read.

4 · Cargo-culting the hyperscalers

☺ Like you're 10: Copying a giant's homework only works if you're taking the same class — a ten-person startup adopting a hundred-engineer company's org chart is copying an answer to a question it was never asked.

Gizmo's whisper: "Netflix runs Chaos Monkey in production. Google formalized SRE with error budgets and a dedicated org. If we want to be a real engineering culture, we need the same thing — starting this quarter." Why it tempts: it's low-effort strategy — someone else already made the hard design decisions, and adopting their answer feels like skipping years of trial and error for free. It also reads well in a hiring pitch. Why it hurts: the case studies this course covers — Etsy, Flickr, Amazon, Google — are origin stories, not blueprints. Each practice they popularized was built to solve a problem at a specific scale, with specific redundancy already in place and a specific engineering headcount available to run it. A five-engineer team that adopts full-scale chaos engineering before it has basic redundancy is deliberately injecting failure into a system with no capacity to absorb it. A team of two on-call engineers that copies a fifty-person SRE org's formal error-budget policy has built a governance process with nobody left to do the actual engineering work the process is supposed to protect. The tool or practice isn't wrong — it's aimed at a problem you don't have yet, at a cost you can't yet afford.

The fix: size every practice to your org's actual constraints — engineer count, deploy frequency, compliance load, and how much redundancy you can genuinely afford to build before you start deliberately breaking things. Before adopting anything because "that's what [company] does," ask what specific problem it solves, whether you have that problem yet, and whether your current team can operate it — not just switch it on.

5 · Metrics theater: DORA numbers nobody acts on

☺ Like you're 10: A smoke detector that beeps and nobody ever gets up to check isn't safety equipment — it's just a noise the room has learned to ignore.

Gizmo's whisper: "Sleuth's already wired up, the dashboard's live, and I put deployment frequency and change failure rate on the quarterly review deck. We're a metrics-driven org now." Why it tempts: standing up a DORA dashboard is a concrete, finishable project with a visible artifact at the end — a chart, a slide, a badge that says "we measure this." It satisfies the letter of Measurement without anyone having to sit through an uncomfortable conversation about what the numbers actually mean for how the team works. Why it hurts: this is a different failure from the one measuring success: the DORA metrics already warns about. That page covers Goodhart's Law — a team actively gaming a metric upward, like splitting one release into ten trivial deploys to inflate deployment frequency. Metrics theater doesn't touch the numbers at all; the numbers are perfectly honest. The failure is that nothing downstream of the dashboard ever changes. Change failure rate climbs from 12% to 34% over two quarters, the chart updates automatically, it sits on a slide in the QBR, and the next sprint gets planned exactly the way the last one was — because no one ever wrote down what should happen when the number crosses a line, and no one owns making it happen if it does.

The fix: every metric on the dashboard needs an owner and a pre-agreed threshold that triggers a specific action — not a vague "we'll keep an eye on it." Something concrete: if change failure rate exceeds 25% for two consecutive weeks, next sprint's capacity is reserved for stability work before new features, agreed in advance, by someone with the authority to actually reserve that capacity when the trigger fires. A dashboard without an owner and a threshold isn't a management tool — it's decoration that happens to be numeric. Sol the Sloth's whole point on the DORA metrics page is to compute these numbers slowly and correctly; the other half of that discipline is making sure a correct number actually changes what the team does next.

The whole rogues' gallery, at a glance

☺ Like you're 10: One cheat-sheet — the whisper, the tell, and the fix — for all five traps at once.

Notice the shape of every fix on this page: each one drags the practice back from looking like CALMS toward actually being it — a real self-service road instead of a renamed queue, a batch size the pipeline can actually protect, a root-cause field that names a system instead of a person, a practice sized to the team that has to run it, a metric with an owner who does something when it moves. That's the whole lesson: the three myths in Foundations are mistakes of omission, easy to spot because nothing got built. These five are mistakes of substitution — something real got built, and it's just quietly doing a different job than the one it was supposed to do. Keep asking Timmy's question — what happens next? — and most of them don't survive contact with it.