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.

DevOps Moves from Experiment to Standard Practice

By early 2017, DevOps had crossed the line from experimental to essential. A survey of Gartner Research Circle members conducted in 2016 found that 38% of respondents were already using DevOps practices, with a further 35% planning to implement them in the following year. That meant more than 70% of the IT market was actively engaging with DevOps — a dramatic shift from just a few years earlier when it was largely confined to web-scale companies and startups.

Alongside broader adoption came a wave of venture capital investment in DevOps tooling companies, and IT budget owners began treating DevOps capability as a requirement rather than a nice-to-have. The challenge was no longer whether to adopt DevOps, but how to do it well — at scale, securely, and without accumulating technical debt in the toolchain itself.

With that backdrop, five changes were emerging that would define what mature DevOps actually looked like in practice. These themes remain highly relevant today.

Change 1: Continuous Updating Becomes the Baseline

When every company effectively becomes a software company — whether they sell retail goods, financial products, or healthcare services — the cadence of software delivery becomes a direct competitive variable. Quarterly or monthly release cycles were already too slow for many markets by 2017; the expectation had shifted to continuous or near-continuous delivery.

This pressure meant that CI/CD pipelines were no longer optional infrastructure. Teams needed to be able to merge, test, and deploy code multiple times per day without manual hand-offs causing bottlenecks. The organisations that thrived were those that treated their delivery pipeline as a product in its own right — instrumenting it, improving it, and removing friction systematically.

Key enablers of continuous updating in 2017 included:

• Automated build and test pipelines (Jenkins, Travis CI, CircleCI)
• Feature flags to decouple deployment from release
• Trunk-based development to reduce long-lived branch complexity
• Deployment automation tied to version control events

Change 2: Reliable, Language-Agnostic Tooling

Most real-world engineering organisations do not operate with a single programming language or a single technology stack. A typical enterprise in 2017 might have Java services, Python scripts, JavaScript frontends, and Go microservices all in production simultaneously. DevOps tooling that only served one language or runtime was a liability, not an asset.

The market responded by pushing platforms toward language-agnostic design — tools that could instrument, test, package, and deploy artefacts regardless of the underlying runtime. Containerisation, particularly Docker (which had gone mainstream by 2016), played a major role here: by packaging an application and its dependencies together, containers made the deployment target largely agnostic to language choice.

Beyond language support, enterprises also demanded high availability from their DevOps infrastructure itself. A pipeline that goes down takes engineering productivity with it. The expectation shifted from “reliable enough” to “highly available and clustered” — the same bar applied to production services was now applied to the tools that build and ship them.

Change 3: Hybrid Infrastructure Becomes the Default

The binary debate of “cloud versus on-premises” had largely resolved itself by 2017: most enterprises were running both, and DevOps tooling had to work seamlessly across both environments. Hybrid infrastructure models — where some workloads run in private data centres and others in public cloud — became the dominant architecture for large organisations.

This created both opportunity and complexity. On the opportunity side, teams could burst workloads to the cloud for CI test parallelism while keeping regulated data on-premises. On the complexity side, pipelines needed to handle differing network topologies, credential models, and deployment targets transparently.

Infrastructure-as-code tools — Terraform, Ansible, Chef, Puppet — gained significant traction precisely because they allowed teams to describe infrastructure intent in version-controlled files that could target multiple providers. The pipeline that provisions a staging environment in AWS could, with minor configuration changes, provision the same environment on-premises.

Change 4: Security Gets Embedded in the Pipeline (DevSecOps)

Faster release cycles create a real security risk if security checks are applied only at the end of the development cycle — or worse, only in response to incidents. The 2017 shift was a growing recognition that security scanning had to move left: into the CI pipeline, into the code review process, and into the dependency management workflow.

Three specific areas drew attention:

• Dependency vulnerabilities: Open-source libraries are the majority of most application codebases. Tools that scan dependency manifests against known vulnerability databases (such as the CVE list) became standard CI pipeline components.
• Outdated packages: Even non-vulnerable packages that are significantly out of date represent operational risk. Automated dependency update tools began to emerge as a category.
• Licence compliance: As open-source adoption grew, so did legal exposure from incompatible licences. Automated licence scanning became part of the release gate for many organisations.

This shift is now widely referred to as DevSecOps — the practice of treating security as a shared responsibility embedded throughout the software development lifecycle, rather than a gate applied by a separate security team at the end.

Change 5: Scalability Without Penalty

By 2017, many organisations were moving past proof-of-concept DevOps initiatives. Teams that had piloted a toolchain with a handful of developers now needed to roll it out across hundreds of engineers, dozens of teams, and multiple business units. The question was whether their chosen tools could scale with them — technically and commercially.

On the technical side, this meant that CI/CD servers, artefact repositories, and monitoring systems needed to handle significantly higher load. Distributed, horizontally scalable architectures for these tools became a hard requirement rather than a premium feature.

On the commercial side, organisations scrutinised vendor pricing models carefully. Tools with per-seat or per-build pricing that penalised growth created a perverse incentive: the better your DevOps practice, the higher your tooling bill. The market shifted toward pricing models that rewarded adoption rather than punishing scale.

Practically, this means evaluating DevOps tooling not just on current team size but on what the cost and operational burden looks like at 5x or 10x current scale before committing.

What These Changes Tell Us Now

Looking back from the present, all five of these 2017 predictions proved accurate — and in most cases, the trends accelerated further than the original analysis anticipated. Continuous delivery is now table stakes. Container-native, hybrid-ready toolchains are the norm. DevSecOps has become a recognised discipline with its own tooling ecosystem. And scalability is a first-order requirement in any serious DevOps platform evaluation.

If you are evaluating or evolving your DevOps practice today, these five dimensions — delivery velocity, tool reliability, infrastructure flexibility, embedded security, and scalable architecture — remain the right axes on which to assess your current state and identify gaps.