I still remember the look. The questioning, doubting look from a CEO who was disillusioned with the technobabble that technologists often engage in—especially promises around a sweeping devops transformation. He was ready for it, and the only question was would I really try to go there?
To set the stage, I was a technology executive for a growing Fortune 100 organization. The organization had dipped its toe in Agile and DevOps waters and invested more than $3 million in its first Agile initiative to build a business-critical system. Eighteen months had passed with no results, no working software, and more than 30 new Agilists were offering excuses for why things were not working. Many of those same Agile excuses are still in use today. In truth, we were facing classic devops adoption challenges.
A month earlier, the technology executive leading this initiative was replaced -- with me. My job was to either to engineer a turnaround or be the one to blame when I went to face the CEO. This called for practical devops leadership. And, that time had come. The only questions were what would I be foolish enough to say, and how long would it take for him to kill the project?
Summary
DevOps matters because it aligns technology and business through culture, collaboration, and rapid feedback to deliver reliable software quickly. This story shows a turnaround from a stalled, costly “Agile” effort to working software in production by focusing on outcomes over technobabble and engaging cross-functional teams. Tools and practices enable speed and reliability, but success depends on leadership, mindset shifts, and shared values—there is no silver bullet. Ultimately, DevOps is about people, trust, and continuous learning to adapt to constant business change.
What did I say?
What I said to the CEO was, "We have working software in production." You could have heard a pin drop. The stare changed from palpable anger to disbelief. How did we get there?
Let's first talk about what we did ++not++ do. In short, we did not speak in technobabble and talk of the promises of DevOps and Agile. Instead, we showed him what talented people from technology, the business, and even from "shadow" technology groups could do when they worked together to push towards a shared goal. The synergy was unstoppable. That collaborative energy is the essence of devops culture.
At the end of the day, Agile and DevOps are touted as many different things. Here are a few examples of how DevOps tools are described in the marketplace:
- "...a single intuitive drag-and-drop UI for all solutions and can act as a central point of management for your entire business."
- "...automate the full software development lifecycle, preventing downtime, increasing performance, and meeting or exceeding your customers' high expectations."
- "...execute key development functions without compromising quality, performance, or reliability."
And as for Agile, in previous blog posts, we addressed Agile misconceptions. Something very different is going on. We are changing the way people work, and in the process changing the role of the technologist from code writer to critical thinker, and from order taker to business partner.
DevOps and feedback
The motivation for DevOps is simple. The projects we work on can be extremely complex. Business change is constant. So, we need a way of working that adapts to constant business change and fosters rapid feedback as we develop software—short, devops feedback loops that make it easier to learn and adjust. Agile and DevOps also allow the opportunity to pivot, turn and adjust as frequently as the business requires. This stands in stark contrast to starting a project with a stack of requirements documents and taking months to deliver.
At a high level, DevOps utilizes a set of practices and tools. These automate the way development teams that are building the software product, and those IT teams that are deploying or operating the software. The goal is simple: We want to develop, build, test and deploy software faster and more reliably. If we are successful, the benefits of devops include increased devops speed to market for the business.
There is one important, crucial caveat. Neither DevOps or Agile will work unless technologists and the business are willing to change the way that they approach their work. For Agile, the Scrum Guideputs it this way: "when the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, they build trust for everyone. Successful use of Scrum depends on people becoming more proficient in living these five values." The same is true for DevOps, as noted on the Atlassian DevOps website: "At its essence, DevOps is a culture, a movement, a philosophy (that fosters) a firm handshake between development and operations that emphasizes a shift in mindset, better collaboration, and tighter integration."
And there is the challenge. Culture is not created by methodology. Firm handshakes, commitment, courage and respect are not tools. People must put them to use to overcome obstacles and create synergy. We must be able to get out of our own boxes and work differently with each other. The difference between success and failure is completely within our control -- if we are willing to change. As I discussed in Leadership Patterns for Software and Technology Professionals, "This type of leadership begins with leading yourself and changing the way you think about yourself, your career, and your work."
No silver bullet...
As I spoke about leadership and Agile recently to a group in Houston, an executive pointed out that there are no silver bullets, reminding us of an old but proven truth. Nothing you can buy is going to make our problems go away. The CEO that I was working for knew it, too.
And guess what? The same is true for Agile and DevOps. They are only as valuable as the people who are using them and, more important, the way they interact with each other and their customers. Interactions with people solve big problems like the one we were facing. No technology ever will.
Q&A
Question: Why should business leaders care about DevOps?
Answer: Because it directly links technology work to business outcomes—delivering reliable software faster through culture, collaboration, and rapid feedback. In a complex, constantly changing business environment, DevOps provides short feedback loops and a way of working that lets teams learn, pivot, and ship value quickly. The story here shows a stalled, costly effort turned into working software in production once the focus shifted from technobabble to outcomes and teamwork.
Question: What actually drove the turnaround from “18 months, no results” to “working software in production”?
Answer: Leadership focused on outcomes over buzzwords and built a cross‑functional team—including business, technology, and even “shadow IT”—around a shared goal. That collaborative energy, supported by short feedback loops, replaced excuses with delivery. It wasn’t new jargon or more “Agilists”; it was people working together differently to produce visible results.
Question: Isn’t DevOps mostly about tools and automation?
Answer: Tools matter, but they’re not the point. Automation helps teams develop, build, test, and deploy faster and more reliably, but success hinges on culture and mindset—trust, commitment, courage, focus, openness, and respect. As Atlassian notes, DevOps is a culture and a “firm handshake” between development and operations. Without that shift, no tool will fix underlying problems.
Question: How should a leader start a practical DevOps transformation?
Answer: Start by aligning on a clear, shared outcome (e.g., “working software in production”), form a cross‑functional team with the business, tighten feedback loops, and model the values that build trust. Avoid silver‑bullet promises and technobabble; let early, visible delivery do the talking. Bring in tools and practices to remove friction, but keep culture and collaboration at the center.
Question: How do you know DevOps is working?
Answer: You see working software in production, faster and more reliable delivery, and the ability to adapt quickly as the business changes. Trust improves across teams, excuses fade, and conversations shift from process and promises to outcomes and learning. The measure isn’t how many tools or ceremonies you adopt—it’s the tangible value reaching customers.
