Real DevOps happens between commits, not pipelines
Your CI/CD runs faster than your feedback. That’s not DevOps — that’s DevOops.
Most engineers still picture DevOps as a conveyor belt more than a (software development life)cycle. The ground-level reality of DevOps in most organizations is that code goes in, product comes out, and every new automation step makes the process run smoother and faster.
That’s the story most of us were sold and still work toward to this day.
“DevOps is efficiency.”
It’s understandable. That’s how DevOps got operationalised in most places — as tooling and velocity. But DevOps wasn’t conceived to only make delivery faster.
Patrick Debois, the “godfather of DevOps”, never framed DevOps with a singular focus on delivery speed. He framed it through the lens of feedback.
The DevOps Handbook, which he co-authored with Gene Kim et al., talks about DevOps as flow, feedback, and continuous learning.
That’s system-dynamics thinking, even if nobody used that term at the time… and well, even now.
Debois cared about how software engineering could take advantage of this.
His thinking focused on:
How fast signals travelled
How quickly the drift was corrected, and
How learning could compound improvements across teams
Coming back to today, we should not merely be optimizing for delivery speed. We should also optimize for feedback speed.
If you zoom into any software delivery flow today, for the most part, the commits themselves aren’t the problem. In fact, they are fast. Pipelines are flowing fast. Rollouts are fast.
What’s slow is everything between commits:
How long it takes to interpret an alert
How long it takes for an insight to become a design change
How fast one team’s learning propagates to another
This “between commits” zone is the rate-limiting step for truly smooth DevOps.
Here’s a composite story of the kinds I have heard over the last 3 years alone:
During a large-scale outage, the alert fired instantly, but it took 45 minutes before anyone realised the signal was noise-shaped by a mis-configured dashboard. The root cause was understood the same day, but the design change sat unscheduled for eight weeks. Worse, another team triggered the same failure pattern three months later because the learning never left the postmortem.
Feedback is the layer that determines whether DevOps creates stability or chaos.
In system-dynamics language, DevOps is a dance between two loops. The:
balancing loop of continuous improvement (detect → understand → act) and
reinforcing loop of (deploy → drift → more deploys).
This zone is where the balancing loop either outruns (stability) or falls behind (chaos) the reinforcing loop. Which is more common in your team or organization?
When your feedback travels slower than your commits, the reinforcing loop wins.
That’s when system reliability begins to decay quietly in the background.
But when your feedback travels faster than your commits, the balancing loop wins.
That’s when reliability earns its rightful place as a default system property. Really, it should not be seen as a sociocultural artifact like team effort or heroic effort.
Optimizing pipelines makes delivery fast. Optimizing feedback makes delivery safe. Doing both gives you real DevOps.
High-performing teams don’t ask, “How do we deploy more often?”
They ask, “How do we learn faster than we deploy?”
Love the framing here. The idea that feedback loops are the actual bottleneck nails it. I've seen this exact pattern where CI/CD was green across the board but teams wre still burning out becuase nobody knew what to fix first or how learning from one incident made it into the next sprint. That system-dynamics lens is clutch for thinking about this stuff.