Common Anti-Patterns: How Organizations Get This Wrong

By this point you've seen a pattern repeat across almost every module: an organization adopts the vocabulary of DevOps or DevSecOps — new job titles, new tools, new ceremonies — while leaving the actual structural problem (the wall, the misaligned incentives, the blame culture) fully intact underneath. This module collects the most common versions of that failure into one place, so you can recognize them quickly, whether you're evaluating your own organization or someone else's.

1. The "DevOps Team" as a new silo

This is the single most common anti-pattern, and it directly contradicts Module 1's core definition. A company decides to "do DevOps," so it creates a team called "DevOps" — usually staffed with people who used to be on the Ops team, now responsible for CI/CD pipelines and cloud infrastructure. Developers still write code and throw it over a wall; the wall just has a new sign on it. Conway's Law (Module 6) guarantees the resulting system will still have exactly the same brittle, over-formalized boundary it always had, because nothing about who talks to whom, or who's accountable for what, actually changed. A real DevOps transformation distributes operational responsibility outward to the teams that build software (Module 5's ownership), rather than concentrating it into one more specialized department.

2. Automation without culture change

Module 3 warned about this directly: a team can build excellent CI/CD pipelines, one-click deploys, and full test automation, while Dev and Ops (or Dev and Security) still don't trust each other, still don't share context, and still treat incidents as someone else's fault. The automation doesn't fix the culture — it just executes the same siloed handoff faster and with less visibility into why it's happening, because a broken process wrapped in a pipeline is still a broken process, just one that's harder to see inside of. The tell for this anti-pattern: impressive tooling, but incident reviews that still end in blame, and releases that are still dreaded rather than routine.

3. Security bolted on at the end

Module 9 covered this directly: a mandatory, slow, late-stage security review that developers try to route around by batching more work into fewer, larger releases — recreating the exact batch-size, feedback-delay problem from Module 4, just for security specifically instead of general quality. The giveaway is a security process that developers see as an obstacle to negotiate around rather than a genuine part of building the system — which almost always means the feedback loop is too slow, too late, or too disconnected from the people actually writing the code.

4. Blameless in name only

An organization adopts the language of blameless postmortems (Module 7) — the meeting is even called a "blameless postmortem" on the calendar invite — but the actual conversation still centers on "who did this," performance reviews still quietly reference incidents by name, and engineers still learn, through experience, that admitting a mistake has consequences. The label doesn't create psychological safety; only the actual, repeated, consistent experience of admitting a mistake and having it treated as useful information — not evidence against you — does that. This is one of the slowest anti-patterns to detect from the outside, because the paperwork looks identical to a genuinely blameless process; the difference only shows up in what people are willing to say out loud in the room.

5. Gaming the metric instead of improving the outcome

Covered concretely in Module 10: a metric like Deployment Frequency gets mandated as a target in isolation, and teams find the path of least resistance to hit the number — trivial no-op deploys, or splitting one logical change into many small ones — without any real improvement in how fast value reaches users. This is Module 2's local-optimization trap wearing a data-driven disguise: the dashboard says the team is improving, and technically, by its own narrow measure, it is — while the actual thing the metric was supposed to represent stays flat or gets worse.

6. Heroics mistaken for good process

An organization has one engineer who reliably saves the day during every major incident — deep institutional knowledge, calm under pressure, always the first one paged even when they're not officially on-call. This often gets celebrated, but it's a warning sign, not a success story: it means the organization's actual reliability depends on one irreplaceable person rather than on shared knowledge, good documentation, and distributed ownership (Module 5). It's a Sharing failure from Module 3's CALMS framework, disguised as a talent story — and it means that engineer's vacation, illness, or resignation is a latent incident waiting to happen.

The common diagnostic question

Every anti-pattern above can be checked with roughly the same question, which is worth keeping as a general-purpose tool long after you finish this course: if you removed the new tool, team name, or meeting format, would the underlying problem this course describes — the wall, the misaligned incentives, the slow feedback loop, the blame — still be sitting there underneath, just less visible? If yes, you're looking at an anti-pattern: the surface changed, but the structure didn't.