From DevOps to DevSecOps to GovOps: How We Keep Getting Better at Work Without Calling It That
DevOps gets described in a lot of different ways–a movement, a practice, a culture, a tool, a job title, a tool category.
Technology changes. Tools change. Acronyms change—sometimes daily. But the underlying problem doesn’t: go from idea to value efficiently, safely, and reliably. At its core, DevOps is about optimizing the speed of new features and the reliability of releases. Put more simply: it’s the optimization of work. To understand where we are going, you need to know how we got here.
The Goal: A Process of On-going Improvement Eliyahu M. Goldratt in 1984 remains relevant and surprisingly entertaining. It revolves around a fictionalized Socratic dialog between Jonah, the professor, and Alex, the plant manager. Goldratt's story of Alex battling to save his plant that was about to be shut down, popularized Goldratt’s Theory of Constraints. The premise? Work flows (not workflows), constraints matter, and optimizing the system (not each individual component) is how you win. DevOps applies the same concepts developed in The Goal to software delivery.
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, published In 2013 by Gene Kim, George Spafford, and Kevin Behr updated The Goal for our current era of software development A new story for a different time. Now the Socratic pair is Erik, the eccentric board member, and Bill, the newly promoted VP of IT Operations who must save the chronically failing Phoenix Project (and the company).
DevOps: The AHA! Moment
The Phoenix Project has been around for years and The Goal for decades. When did I read them? Last fall 2025--it's never too late to educate yourself!. Even without this historical context DevOps made a big impression on me. For many years into my career, development and operations lived in friction. Things broke. Ops got blamed for dropping the ball in the endzone. Dev got blamed for handing off code that shouldn’t have been near production.
When I first heard the word DevOps–I’ll admit—it felt like a revelation. DevOps—literally mashing the words Development and Operations—showed that closer collaboration, better tools, and automation could speed feature delivery and increase operational stability. I wasn’t thinking about work flow or constraints as I was “automating everything,” but the side effects of these efforts? Handoffs, waiting, rework, and mistrust dropped. Flow improved. Releases became faster. Systems became more reliable. Work was optimized.
Security: Turns Out the Internet Can Be Dangerous
While the Internet has made information systems accessible, vulnerabilities in the software running those systems made them exploitable. Often, security was ignored—or set up to fail—slapped on at the end, but still expected to prevent problems that had already been coded and deployed.
DevSecOps solved for this by pulling security into the system rather than treating it as a gate:
Build securely from the start
Automate controls
Share responsibility
Security does not have to be a bottleneck. It can be part of the flow. Features can move fast—and safely.
Automation: Solving One Problem, Creating Another
DevOps leans heavily on automation:
“If you have to do it twice, automate it.”
This work has made a mountain of change to how software is released and operations are managed. Traditional automation is fast, but GenAI (including Machine Learning) is driving change, yet faster. With GenAI automation penetrates more of the life-cycle, including business processes:
Policy generation
Code development
Infrastructure deployment
Incident remediation
Breadth has increased dramatically—control has fallen behind.
A Philosophical Detour (Because I Can’t Help Myself)
DevOps shortened the distance between thought and reality. A developer has an idea. They type code. That idea is suddenly running somewhere, affecting real people—sometimes in ways no one fully anticipated.
GenAI compresses that distance further. Ideas, implementations, and changes now propagate faster than Monday morning coffee disappears. At some point, you have to pause—preferably while sipping said coffee—and ask:
Who—or what—is actually in charge here?
Enter GovOps: Because Someone Has to Be in Charge
Governance has always existed, and yet, is generally unappreciated and typically done poorly or just well enough to meet regulatory requirements. Governance has not lived in the system. It’s been policies, audits, and slide decks no one reads. Continuous delivery and AI-generated everything break that model. We can no longer afford the risk of leaving Governance out of the loop.
So we do what we did with DevOps and DevSecOps: pull governance into the flow. This is GovOps.
GovOps: Making Governance Real
GovOps isn’t about adding more controls—it’s about making controls operational:
“We require encryption” → enforce it in code
“Review access quarterly” → monitor it continuously
“Produce audit evidence” → the system generates it automatically
And here we go again.
The Pattern Should Look Familiar
We keep doing the same thing:
Identify the constraint
Pull it into the system
Automate
Improve flow
DevOps did it for delivery. DevSecOps did it for security. GovOps does it for governance.
Reality Check
It may sound neat, but it’s going to be messy:
People resist change
Organizations protect silos
Each new layer (DevOps, DevSecOps, GovOps) gets turned into a tool category before it’s understood as a way of working
Where This Lands
If The Goal taught us to optimize systems, and DevOps applied that to software delivery, what we’re doing now is extending that thinking across the lifecycle:
Build it
Secure it
Prove it
Continuously.
We’re not just doing more work. We’re not just doing it faster. We’re understanding how work flows, where it breaks, and how to fix it—systematically. Everything else—tools, AI, acronyms—is just how we’re expressing that idea right now.
Give it a few years. We’ll rename it again.
