Anyone who’s ever played the game of chess knows there’s more than one way to reach a desired outcome. There are 400 possible setups after the first turn; 197,742 after the second; and just north of 120 million after the third—all of which are marching toward the same desired outcome.

“So, what does any of this have to do with DevOps?” you ask? Fair question. Much like there’s no one way to approach a chess match, there’s also no one way to engage in a DevOps transformation.

So how do you manage the kind of transformation that promises faster deployment, increased stability, and improved collaboration without majorly disrupting your business, your existing processes, and your people?

At PagerDuty, we’ve found that businesses that have successfully embarked on this journey followed five key tactics.

Acknowledge Inevitable Change

One thing is certain: companies today need to transform and innovate their digital services to meet rising customer expectations or risk losing ground to the competitors and becoming irrelevant. Change is often uncomfortable, and many organizations experience push back from their teams regarding transformation initiatives—and in some cases, teams will experience attrition. Oftentimes, the reality of DevOps’ “you build it, you own it” motto can be one step too far.

But that’s okay. We’ve seen the pushback and employee attrition happen in many organizations—after all, not everyone likes the idea of being on call. But in this scenario, the short term-pain is worth the long-term gain because you want people who are willing to help you get to where you want to go; those who can’t will just slow you down.

For those willing to go on the journey with you, help them visualize what this transformation might look like. Instead of ripping and replacing existing processes, start with smaller projects so teams can test new ideas, assess risk, get some quick wins, and get a feel for the future “new normal.” The goal is to shift thinking so that being on call becomes an opportunity to learn and grow instead of a barrier to change. Plant the seeds for success and get some early, small wins so that even if change is inevitable, it’s at least more familiar.

DevOps is not a zero-sum game; it’s additive. The intent is to continuously improve the quality of the output and skills of the team.

Create Buy-In for the Vision

It’s important to highlight that the shift to developer teams having more ownership can’t happen without buy-in from the top as well. Ensuring both management and development teams have a mutual understanding of the future state and potential benefits is critical.

Starting small and getting some wins under your belt serve two purposes:

• It demonstrates that an Agile approach is achievable and works well for developer and ops teams alike.Getting groundswell support makes it an easier sell at the executive level because you can showcase these early successes and have the developer support that will be living out these new processes
• Whether these successes are described by faster deployment frequencies and improved code quality on the dev side or fewer impact incidents and more resilient infrastructure on the ops side, it’s crucial that these successes are material and visible for executive buy-in. By quantifying results, executive teams can better understand the positive impact these new processes can have if the organization fully implements them.

Sparking this buy-in from your development teams may seem like a big obstacle to overcome, but their eventual support will become your most valuable asset. Committing to the vision aligns roles and responsibilities and helps create a holistic approach to DevOps.

Understand the Change in Incentives

We hear a lot from our customers that using PagerDuty helps shift the development culture and enable more accountability. So what does this mean, exactly?

In a traditional Ops model, incentives for developer and ops teams are typically misaligned. Developers want to ship fast, but have less visibility into reliability once code is in production. On the other hand, ops teams want reliability and perfectly running code, even if it means shipping slower.

A DevOps approach changes the incentives. Because developers own the code that they ship, they are more motivated to place an increased focus on quality to avoid being woken up in the middle of the night with production problems. A lot of developers fear being on call for this exact reason. But what we’ve found is that it happens a lot less than expected because the code quality is vastly improved in an agile DevOps architecture.

Being on call is the tactic that drives ownership home and aligns incentives, and it also facilitates real-time learning, which in turn drives better quality and faster innovation.

Make DevOps Your Own

There’s an abundance of information available out there to help teams navigate a DevOps transformation. But at the end of the day, the way you implement DevOps will be unique to your team and/or organization, and tools or processes alone won’t get you there.

The principles of DevOps are simply a framework, but it’s how you tailor that framework to mold to your team that makes DevOps unique to your organization. Keeping your team involved in the transformation process is the most important step to eventual success. For example, gathering feedback from teams on new processes and keeping the forum open for suggestions or new ideas from across the organization can help build team chemistry and motivate your team to take the new changes in stride.

Along the way, you’ll gain more support and more adoption as you achieve more success, and the cultural shift will happen organically. It’s a lot of upfront work, but the investment early on can pay dividends down the road.

Understand the Metrics

To make a convincing argument about the benefits of DevOps, you need proof. Make sure you measure and quantify existing processes to create a baseline for comparison by asking discovery questions such as:

• How long does it take to deploy new code to production?
• How often are deployments?
• How long does it take to troubleshoot bugs?
• How much downtime do you see quarter over quarter?

These are just sample metrics, and what you measure in your organization could be quite different. The key thing is to have a good grasp on the metrics in the “before” state so you can assess the “after” state performance of a DevOps model.

Ideally, the metrics should demonstrate better results with a DevOps approach. For instance, you could have better uptime or improved deployment frequency. Our customers typically look at mean time to acknowledge (MTTA) and mean time to resolve (MTTR) issues for teams on call, but those are by no means the only metrics that matter.

Capturing these metrics also provides more visibility into areas for improvement. As management guru Peter Drucker once said, “You can’t improve what you can’t measure.”

DevOps has a wide interpretation, and what it means to your organization can mean something completely different for another. Moving to DevOps is a significant change that involves risk, patience, and commitment, and it can be jarring if it’s done too fast or without organization-wide buy-in. But with a thoughtful approach, you can alleviate many of the concerns and growing pains that can come up as you transition into a DevOps world with developers on call.

To learn how PagerDuty can help your team take on a DevOps transformation, contact your account manager and start a 14-day free trial today.