Skip to content

Why DevOps Became Necessary

Historically, many organizations separated software work into two broad groups: Development and Operations.

DevelopmentOperations
Building featuresServers
Fixing bugsUptime
Writing codeDeployment
Moving quicklyNetworking
Shipping changesBackups
Security
System stability
An isometric diagram showing the split between Development (Change) on the left and Operations (Stability) on the right, separated by a structural wall representing their conflicting incentives.

Fig 1: The Dev vs. Ops Split (Change vs. Stability)

Both groups were doing legitimate work. The problem was that they often had conflicting incentives.

The Incentive Conflict

Developers were rewarded for change. Operations teams were rewarded for stability.

That created tension fast. Every new change a developer introduced was a potential threat to the stability the operations team was evaluated on.

A classic anti-pattern looked like this:

  1. Developers build the application.
  2. Developers say, “It works on my machine.”
  3. The code gets handed off to operations.
  4. Operations now has to somehow make it run in an unfamiliar environment.

That handoff often included missing information, vague instructions, or tribal knowledge like:

  • “Oh, you need Node 18, not Node 20.”
  • “It only works if that config file is present.”
  • “You need to run this command first.”
  • “The app writes files into a folder we forgot to create.”
  • “The environment variable names are slightly different in production.”
Chaos Relay

That is not a strong delivery model. That is a chaos relay race.

DevOps developed as a response to that friction.

The goal was not to erase all roles or make everyone identical. The goal was to create:

  • tighter collaboration
  • shared ownership
  • automation where possible
  • faster feedback
  • more reliable delivery
  • more predictable operations

In other words: stop treating deployment and operations as an awkward after-party after the “real” development work is done.


Atlassian: A Brief History of DevOps

So, we’re not just throwing code over walls anymore. But if DevOps isn’t just a role, what does the actual workflow look like?