This article is based on reporting originally published by TheServerSide.com, covering Verizon’s enterprise DevOps transformation strategy as described by Ross Clanton and Nanda Kumar.
Why Tool-First DevOps Adoption Fails at Enterprise Scale
A common mistake organisations make when beginning a DevOps transformation is to lead with tooling—selecting a CI/CD platform, containerisation stack, or monitoring suite and then mandating its adoption across engineering teams. At a company with hundreds or thousands of developers, this top-down, tool-first approach tends to generate anxiety, resistance, and shallow adoption rather than the cultural shift DevOps actually requires.
Verizon, which has undertaken a large-scale migration to public cloud infrastructure, took a deliberately different path. Rather than prescribing a fixed toolchain, the company focused on immersing developers, managers, and business stakeholders in a lived DevOps experience—one they could carry back into their day-to-day workflows. By the time this strategy was described publicly, Verizon had already stood up more than 1,000 teams operating with DevOps toolchains and delivery pipelines.
According to Ross Clanton, a fellow of technology transformation at Verizon, a central insight driving the approach was that successful DevOps adoption depends on tapping into developers’ pride and passion rather than imposing a pre-defined agenda.
The People Bottleneck: DevOps at 20,000-Developer Scale
Verizon’s toolchain itself was not the hard part. “We have a pretty familiar toolchain,” Clanton acknowledged. The real constraint was human: how do you bring DevOps practices to 20,000 engineers distributed across the United States and India, without losing the agility and collaborative energy that makes DevOps work?
Large development teams are inherently harder to make agile. Breaking them into smaller, cross-functional units is a prerequisite for faster delivery, but it also requires a shift in mindset that cannot simply be trained in a classroom. Verizon’s answer was to create a network of dojos.
The DevOps Dojo: Immersive Learning on Real Work
The term dojo is borrowed from the Japanese martial arts tradition—a dedicated space for deliberate practice and skill-building. Verizon adapted this concept into an immersive engineering environment where teams work alongside DevOps coaches for a concentrated period, focused on real projects rather than contrived exercises.
“The dojo is an immersive learning environment modeled on the Japanese concept of a place you go to build your skill,” Clanton explained. “We are bringing teams in for extended periods and working with coaches while learning about the products they are creating for the organisation.”
How the Six-Week Dojo Sprint Works
- Duration: Each cohort dedicates six weeks inside the dojo environment.
- Real backlog: Teams arrive with genuine work items they are already responsible for delivering—not synthetic training scenarios.
- Coaching: Dedicated DevOps coaches work alongside the team throughout the engagement.
- Skills focus: DevOps practices, Agile methods, cloud development, and incremental delivery so teams can demo progress with internal business customers.
- Cross-functional working: Engineers, managers, and business representatives collaborate in a single physical space.
Managing the “Speed” Expectation
One of the most important management lessons Verizon learned was to reframe what success looks like during a dojo engagement. Many managers initially expected teams to deliver software faster over the six-week period itself. In practice, that rarely happened—and Clanton argued it is beside the point.
“The purpose of the dojo is learning, and we prioritise that over everything else,” Clanton said. “That means you have to slow down to speed up. Over the six weeks, they will not speed up. But they will get faster as an outcome of the process.”
Aligning management expectations to this outcome—faster delivery after the dojo, not during it—was identified as the biggest cultural adjustment required of the programme’s sponsors.
Dojo Locations
At the time the strategy was publicly described, Verizon operated three dojos in the United States and two in India, reflecting the company’s primary engineering hubs.
Scaling Globally: The Dojo-in-a-Box Programme
Physical immersion is powerful, but it is also logistically demanding. Asking engineers to leave their homes and families for six weeks is a significant ask—and one that is not always feasible for globally distributed teams.
To address this, Verizon developed a lightweight variant called Dojo-in-a-box. The programme packages dojo guidance—frameworks, coaching materials, and structured practice resources—and distributes it to teams that cannot participate in a physical dojo. In some cases a live coach is also deployed remotely or on-site; in others the team works with the materials independently.
Verizon experimented with fully remote dojo participation but found it was less effective than physical co-location. Dojo-in-a-box is therefore positioned as a pragmatic compromise rather than a direct replacement.
Building Cultural Momentum: Internal Conferences and Bottom-Up Excitement
Technical programmes alone cannot sustain a cultural transformation. Verizon supplemented its dojo network with internal events designed to generate genuine enthusiasm rather than mandated attendance.
The company created an internal DevOps conference exclusively for employees. Clanton was deliberate about the formula: “Get the external speakers that will draw a crowd, and get people to share and talk internally. Market it like crazy, make it fun and keep doing it.”
The underlying principle was that DevOps adoption requires momentum from both directions—enthusiasm generated from grassroots practitioners and visible commitment from senior leadership. Neither alone is sufficient.
Gamification: Friendly Competition to Spread Best Practices
One of the more distinctive elements of Verizon’s strategy was a formal gamification programme designed and led by Nanda Kumar, a fellow at Verizon Global Technology Services. The programme introduced a competitive framework—including an actual physical cup awarded for demonstrated DevOps mastery—to motivate teams across the organisation to raise their game.
Design Principles of the Competition
Tool choice is a sensitive topic in DevOps communities. Mandating a specific toolchain can alienate experienced engineers and undermine the autonomy that makes DevOps teams effective. Verizon’s competition was designed explicitly to avoid this trap.
“With gamification, we wanted to define the high-level guardrails to achieve and let developers figure out if the current tools satisfy these needs,” Kumar said. “If not, they can gravitate towards tools that work for them.”
The competition evaluated teams against outcome-based criteria and best-practice benchmarks rather than adherence to a prescribed stack. This preserved engineering autonomy while establishing a shared standard of excellence.
Secondary Benefits: Vendor Dialogue and Cross-Team Learning
The competition produced two valuable secondary effects:
- Improved vendor relationships: When developers discovered gaps between commercial off-the-shelf tools and their actual needs, the competitive context gave them a concrete reason to open a dialogue with vendors. This created a feedback loop that influenced product roadmaps.
- Cross-team knowledge transfer: Participating teams were inspired to study the practices and tooling choices of winning teams, accelerating the organic spread of effective patterns across the organisation.
Visibility Through the Hygieia Dashboard
Verizon used the Hygieia open source DevOps dashboard to make each team’s progress visible across the organisation. Hygieia aggregates data from CI/CD pipelines, version control, testing, and deployment systems into a single view, making it possible to compare team maturity in a transparent and objective way.
The Tech Fair Format
As part of the cup competition, Verizon organised a tech fair that brought teams together to showcase their work. Tool vendors partly sponsored the event, helping to offset costs. The energy in the room had a notable effect on leadership engagement: Kumar described one senior manager who had blocked only 15 minutes for the event but cancelled the rest of his day’s meetings when he witnessed the enthusiasm firsthand.
“This can provide the value to get things going,” Kumar observed.
Key Takeaways for Enterprise DevOps Leaders
- Lead with people, not tools. At enterprise scale, the toolchain is rarely the limiting factor. Cultural adoption is.
- Immersion beats classroom training. Working on real projects with expert coaches produces durable skill changes that slide-deck training cannot replicate.
- Set the right success metric for immersive programmes. Measure outcomes after participants return to their teams, not throughput during the learning period itself.
- Preserve engineer autonomy on tooling. Define outcome-based guardrails and let teams select tools that meet them. This reduces resistance and often produces better outcomes.
- Make it fun and visible. Internal conferences, gamification, and public dashboards create social proof and peer motivation that mandate-driven programmes cannot generate.
- Build both top-down and bottom-up momentum. Senior sponsorship and grassroots enthusiasm must reinforce each other for a transformation to sustain itself.