When DevOps conferences first appeared, the dominant conversation was about convincing management that DevOps was worth pursuing. Engineers from development and operations took the stage to share hard-won stories of persuading skeptical executives. That dynamic has since reversed. Today, many managers arrive already convinced—their challenge is getting engineers on board. The shift reveals just how far DevOps has moved from grassroots movement to mainstream business priority.
DevOps began as a bottom-up revolution—a reaction to the chronic pain of siloed teams, slow releases, and brittle infrastructure. But like all revolutions, it now faces the risk of becoming institutionalized in ways that hollow out its original intent. Understanding how leadership can prevent that outcome is critical for any organization serious about a genuine transformation.
DevOps and Agile: Two Revolutions, One Warning
DevOps is often described as a continuation or extension of Agile—the argument being that Agile addressed collaboration within development teams but left operations largely out of the picture. That framing is useful, but it also carries a cautionary lesson.
Agile began as a principled revolt against heavyweight, document-driven software development. Its manifesto elevated individuals and interactions, working software, customer collaboration, and responsiveness to change. Yet as Agile matured, it became institutionalized into frameworks—Scrum, SAFe, LeSS, and their many variants—that made it easier for organizations to adopt in a checklist fashion. The result, in many teams, was the opposite of the original intent: processes valued over people, backlog ceremonies more important than delivered value, and engineers who felt manipulated rather than empowered.
DevOps rose partly because Agile, in its institutionalized form, had stopped serving engineers well. Unhappy engineers write lower-quality code and disengage from the systems they maintain. Customers and businesses suffer the consequences.
Unlike Agile, DevOps has no single authoritative framework. It has tools—continuous delivery, infrastructure as code, containers, feature toggles, microservices—and it has guiding principles. The most widely cited set of principles is captured in the acronym CALMS:
- Culture
- Automation
- Lean practices
- Measurement
- Sharing
The term CALMS is attributed to John Willis and Damon Edwards, with further development by Jez Humble. The tools and methodologies most people associate with DevOps primarily address Automation, Measurement, and parts of Lean. They do little on their own to build Culture or Sharing. An organization that implements only the tooling side risks falling into the same formalistic trap that undermined so many Agile initiatives.
Escaping the Formalism Trap
Suppose you are a manager who wants to lead a DevOps transformation. You understand there is no plug-and-play framework. You know the guiding principles. You have seen what happens when organizations mistake process compliance for cultural change. So how do you actually build culture, encourage sharing, and foster genuine collaboration?
You cannot simply instruct people to cooperate, show empathy, or be innovative. Cooperation and sharing are driven by emotion, trust, and psychological safety—none of which respond to mandates. Incentive structures help at the margins, but they cannot manufacture the intrinsic motivation that sustains a healthy engineering culture.
The answer is leadership—not as an abstract concept, but as a set of concrete, practical roles that managers and technical leads can consciously adopt. Social scientists have studied leadership extensively, and their findings offer a useful foundation.
A Brief Survey of Leadership Theories
Understanding where modern leadership thinking comes from helps clarify which approaches are most relevant to DevOps transformation.
- Great Man Theory: Leaders are born, not made. Largely discredited as impractical, but it prompted researchers to ask what traits effective leaders share.
- Trait Theory: Focuses on identifying personal characteristics associated with effective leadership—things like confidence, decisiveness, and integrity. Useful but unwieldy, as researchers identified dozens of relevant traits with no universal set emerging.
- Skills Theory: More actionable than trait theory. Identifies three categories of learnable skills: technical credibility in one’s domain, interpersonal skills (persuasion, diplomacy, empathy), and conceptual skills (strategic thinking, systems perspective).
- Transactional Leadership: Leadership based on reciprocity—rewards for compliance, consequences for non-compliance. Effective for stable, well-defined tasks but limited in environments requiring creativity and innovation.
- Transformational Leadership: Leaders who inspire commitment by articulating a compelling vision, showing genuine care for their people, and actively reshaping the environment and relationships around them. Results come from motivation rather than transaction.
- Servant Leadership: Prioritizes identifying and meeting the needs of followers. By serving rather than being served, leaders build environments of trust and reciprocal cooperation—ultimately producing higher performance. Popularized by Robert Greenleaf in the 1970s, though the principle has much older roots.
Each theory captures something real. The challenge is translating these ideas into actionable roles for the managers and technical leads driving a DevOps transformation.
The 4 Roles of DevOps Leadership
The following four roles are not job titles. They are functions that DevOps leaders—whether a VP of Engineering, a team lead, or a principal engineer—need to consciously perform throughout a transformation.
Role 1: Tell the Story
For small, greenfield projects with a compact cross-functional team, skills-based leadership is often sufficient. The leader has direct visibility into technical work, team dynamics, and strategic direction simultaneously. But greenfield projects are not where DevOps delivers its greatest value.
The real opportunity—and the real difficulty—lies in transforming large, complex environments that were never built with DevOps principles in mind. At that scale, transformational leadership is essential. Engineers need to understand why the organization is changing, not just what is changing. They need a vision of what a better working environment looks like and a leader they believe is genuinely committed to getting there.
Culture is built through narrative. The story has to be authentic—leadership must visibly live inside it, not narrate it from the outside. If a manager tells engineers that psychological safety and experimentation are valued, but then blames individuals publicly when things go wrong, the story collapses.
Practical implication: If you are leading a DevOps initiative, either develop your own clear, honest narrative about why this change matters and what it will look like in practice—or identify someone inside or outside your organization who can credibly carry that story. Without a compelling story, tooling adoption will remain superficial.
Role 2: Be the Safety Guard
Once people believe in the story, they still need to feel safe enough to act on it. Experimentation is central to DevOps—continuous improvement depends on trying things, measuring outcomes, learning from failures, and iterating. None of that happens when engineers fear that a failed experiment will cost them their job.
The servant leadership model is most relevant here. Leaders who protect their teams from organizational punishment for well-intentioned failures create the psychological safety that enables genuine innovation. Leaders who allow—or create—an atmosphere of fear will find that engineers optimize for self-preservation rather than system improvement.
A common question from managers embarking on DevOps transformation is whether automation will allow them to reduce headcount. The honest answer is that building a culture of collaboration and innovation is fundamentally incompatible with an atmosphere of job insecurity. If staffing reductions are necessary, address them directly and transparently rather than allowing uncertainty to poison the cultural environment you are trying to create.
Practical implication: Establish explicit norms around blameless post-mortems, encourage teams to surface problems early without fear of reprisal, and visibly defend your engineers when experiments do not go as planned. Safety is not permissiveness—it is the precondition for accountability to feel fair rather than threatening.
Role 3: Build the Kernel Team
Transformational and servant leadership provide the cultural foundation, but work still has to get done. DevOps organizations rely on independent, self-organizing teams that operate with the speed and focus of a well-run startup. Those teams need skilled technical leaders who can coach, lead by example, and maintain alignment between team-level work and the broader organizational direction.
One useful pattern is to build a small group of highly capable technical leaders—sometimes called a Kernel team—whose explicit mandate is to support the transformation, identify bottlenecks in the end-to-end delivery flow, and facilitate coordination across teams. In management literature this concept appears under various names, including synerteams and cross-functional task forces, but the function is the same: ensuring that the connections between teams do not become the point where flow stops.
These leaders are backed by the transformational leader and given the authority and incentive to cooperate across organizational boundaries. In return, they provide ground-level intelligence about where the real impediments to flow exist—information that is essential for steering the transformation accurately.
Practical implication: Identify two to five engineers who combine strong technical credibility with the interpersonal skills to work across team boundaries. Give them explicit time and mandate to work on systemic improvement, not just their primary team’s delivery commitments. Make their coordination work visible and valued.
Role 4: Be the Communication Enabler
Ideas do not spread by themselves. The Protestant Reformation is a useful, if non-technical, illustration: earlier reformers had criticized Church practices before Martin Luther, but Luther’s ideas achieved unprecedented reach because he used the then-new technology of Gutenberg’s printing press to distribute the Ninety-Five Theses as a widely circulated pamphlet. The medium amplified the message in ways previously impossible.
For a DevOps transformation to take root across an organization, the vision, the experiments, the wins, and the lessons learned all need to flow freely. Modern engineers communicate naturally through tools like Slack, collaborative wikis, shared code repositories, and chat-based operations workflows. The concept of ChatOps—making operational work visible and collaborative through chat platforms—popularized by GitHub, is one expression of this principle. GitLab has articulated a related concept called Conversational Development.
Organizational leadership has a responsibility here that is analogous to infrastructure maintenance: establishing, promoting, and actively maintaining the communication channels that allow ideas and information to move. Open communication cannot be mandated into existence, but it can be enabled or blocked by the structures leadership puts in place. If the channels do not exist or are not modeled by leadership, the conversations will not happen at the scale needed.
Practical implication: Choose communication tools that match how your engineers already prefer to work. Create shared spaces—channels, forums, retrospectives—where cross-team learning is the norm rather than the exception. Participate in those spaces visibly. Make work and its outcomes transparent so that the organization can learn collectively, not just individually.
Conclusion
The ultimate goal of a DevOps transformation is a self-organizing system in which teams collaborate effectively because trust, shared understanding, and mutual respect are simply how things are done—not because a process mandates it. That is an ambitious vision, and it does not arrive automatically.
Organizational systems tend toward disorder without active effort to maintain structure and alignment. As a DevOps culture matures, the nature of leadership must evolve alongside it—shifting from forming and driving the transformation to connecting the organization with the outside world, sustaining the feedback loops that prevent stagnation, and ensuring the culture remains adaptive rather than merely habitual.
The four roles—storyteller, safety guard, kernel team builder, and communication enabler—provide a practical framework for that leadership work at every stage of the journey.