Most people meet "DevOps" as a job title before they meet it as an idea, which is backwards, and it's why the idea gets so mangled in practice. Somewhere along the way, "DevOps" became shorthand for "the person who manages our Jenkins box" or "the team that owns the YAML." Neither of those things is DevOps. They're often what's left over after DevOps, as a set of practices, never actually got adopted — a team got renamed instead of a workflow getting changed.
DevOps is a set of practices for closing the gap between building software and running it in production. That's the whole definition. Everything else — the tools, the pipelines, the team structures — is an implementation detail in service of that gap closing.
The gap DevOps is actually about
Before the term existed, most organizations had a structural split: developers wrote code and threw it over a wall, operations caught it and ran it. Each side optimized locally. Developers were measured on features shipped. Operations was measured on uptime. Those two incentives are in direct tension — the fastest way to protect uptime is to change nothing, and the fastest way to ship features is to change things constantly.
Note
The wall wasn't a process failure. It was a rational response to how each team's success was measured. You don't fix a wall built out of incentives by asking people to communicate more. You fix it by changing what "success" means for both sides.
That tension shows up as a predictable set of symptoms: releases that take weeks to coordinate, a production environment nobody who wrote the code fully understands, and an operations team that treats every deploy as a threat because, statistically, deploys are how most outages start.
What actually changes
The practices that fall under "DevOps" all attack that same gap from different angles:
- Shared ownership of the full lifecycle. The team that writes the code carries some responsibility for how it behaves in production — usually via on-call rotation, not just a Slack ping to ops.
- Automation over handoff. Every manual step between "code is done" and "code is running" is a place where the wall can reappear. CI/CD pipelines exist to remove the human queue, not just to look modern.
- Fast feedback loops. A developer who finds out about a production issue three weeks later, through a ticket, cannot learn from it. A developer who gets a page ten minutes after a bad deploy can.
- Infrastructure treated like software. Version-controlled, reviewed, tested — not configured by hand and remembered by one person who's on vacation this week.
None of these require a specific tool. You can practice all four with shell scripts and cron. You can also buy every tool in the CNCF landscape and still have a wall — teams do this constantly, mistaking tool adoption for practice adoption.
Why "hire a DevOps engineer" misses the point
If DevOps is a set of practices distributed across a team, hiring one person to "do DevOps" reconstructs exactly the silo it was meant to dissolve. That person becomes the new wall — the one who understands the pipeline, owns the YAML, and gets paged when anything infrastructure-shaped breaks. Everyone else goes back to writing code and throwing it over, just to a person instead of a department.
A useful test
If only one person on your team can explain how a change gets from a commit to production traffic, you don't have DevOps practices — you have a bus factor of one wearing a DevOps title.
This is also where platform engineering enters the picture, and it's worth being precise about the relationship rather than treating the two as synonyms. DevOps describes how a team should work — shared ownership, automation, fast feedback. Platform engineering is an organizational response to the fact that not every team can independently build the tooling that makes those practices practical at scale. A platform team builds the paved road; DevOps is the driving discipline everyone still needs on that road. Day 18 of this series digs into where that distinction actually matters day to day.
What good looks like in practice
| Symptom of the wall | DevOps practice that addresses it |
|---|---|
| "It worked in staging" | Environment parity, infrastructure as code |
| Deploys require a change-approval meeting | Automated pipelines with built-in checks replace manual gatekeeping |
| Nobody knows who owns this service | Team-level ownership, tied to on-call |
| Outages are discovered by customers | Observability and alerting owned by the team that ships the code |
The common thread across all four: the team that makes a decision also feels its consequences, quickly. That feedback loop — not the tooling — is the actual mechanism. Everything else is plumbing to make that loop fast enough to matter.
Tomorrow: the three ways of DevOps — flow, feedback, and continuous learning — and why most teams only ever adopt the first one.
