Ever feel that when it comes to the way the executive team and your tech team see success, they are so polarized they’ll never see eye to eye? We understand, but if it seems like business lies on one side and dev the other, it might be your DevOps thinking that can bring the two together.

How? Simply put, your metrics.

Can DevOps metrics really set the stage?

We know. Metrics are seen as things that build walls between people, not bring them together. They’re not cuddly-feely, don’t offer tea and cake, and are often met with confusion and fear.

Even so, if your executive team and tech team feel miles apart, you know that is simply the way it seems and not the way it actually is. DevOps is of major benefit to the whole company and most definitely the executive team. Their primary concerns are progress, profit, and competitiveness, and DevOps helps on all three fronts. What's keeping you apart is that they just don’t realize it yet!

DevOps will save you, just not in the most direct way possible.

By carefully choosing your metrics and data (and the way you present them), you will illustrate all that is positive about DevOps. Because you’re catering to a non-tech team, you’ll present this data in a very accessible way,  allowing them to see where you are aligned, understand what you’re doing, and champion what you want to do in the future - once they realize how good it is for the entire company.

DevOps metrics - as easy as ABC?

Even within the DevOps team, the mere mention of metrics might make you balk. DevOps is notoriously hard to assess. There’s no formal ”DevOps” methodology and no checklist - so it’s hard to know how to judge its performance.

If you decide to strike out alone, it can be hard to find appropriate metrics but easy to go wrong. Some argue that DevOps needs fresh, custom-made metrics and frankly, many of us aren’t really in a place to do that for our own teams, let alone in a way that unites both DevOps and the executive team.

“When adopting DevOps, organizations should consider a new approach to identifying and implementing a DevOps measurement program.”

Peter Waterhouse, “Metrics That Matter”—Developing and Tracking Key Indicators of High-Performance IT

Do not despair.

By bringing the best of your DevOps thinking to the problem, you will choose metrics that naturally lean towards collaboration. If you are cultivating a silo-free environment, you’ll be aiming to work closely with the executive team - having metrics that include their needs from the very start saves time, breaks down barriers, and - let’s face it - makes DevOps look good.   

Let’s take a look at how you might start creating these metrics and what pitfalls you might come across. Excellence won’t happen overnight, but DevOps metrics are a matrix for success that you can start building at this very moment.

Bad metrics - avoid these no matter what

It’s not accurate to say you need totally new metrics. Instead, you’re going to curate existing metrics, not create them. This data is already out there - there are concepts that exist, aspects that tools measure, and formulae that you can leverage. Your job is to pick the metrics that best illustrate what DevOps is trying to do for the wider business, and use that as a communication device when talking to the c-suite.

First, we want to give you a heads up. Some metrics out there suck. Here are our top 3 to avoid:

Vanity metrics

Vanity metrics are dangerous because they play to the hero coder, urging her or him to produce more, more, more! A go-go-go attitude like this will produce pretty graphs, but it will do nothing for collaboration, cross-function, or meaningful goals - no company aims to “produce more code”! Vanity metrics prize volume over actions that refine, streamline, and make agile, making them very dangerous indeed.

Conflict-encouraging metrics

Yikes, gamified metrics might be cool, but they pit teams against each other, comparing and contrasting achievements. They’re usually output-based and - gasp! - incentivize anti-DevOps behavior. All those great things that you want to encourage, like peer programming, cross-project collaboration, and communication, are endangered by metrics that encourage unnecessary work and blinkered behavior.  

Old school metrics

Many leaders persist in utilizing incumbent metrics, like mean time between failures (MTBF) and the ratio of full-time equivalents (FTEs) to servers. But while these may have been useful in the past, they can work at cross-purposes with DevOps transformation today. After all, with faster delivery of services, some failure is to be expected. And as IT improves its responsiveness, the average time between failures may not be as useful as, say, a distributed representation.

Don’t get us wrong, it’s not because they’re old-school that we don’t like them. It’s more to remind you that some of the old reliables are solid, but they were more useful when tech teams moved differently and had different concerns. Take process metrics, for example, from ticket-based systems - more tickets processed is not a sign of DevOps progress! Likewise, many symptomatic metrics - like CPU and memory usage - are ok for troubleshooting, but no good for progress reporting. In general, output-only metrics aren’t as useful as they used to be.

DevOps metrics that work for everyone

So now that we have it clear that bad metrics help no one, and in some cases can even hurt, let’s take a look at the metrics and ideas that will help you, keep your devs happy, and facilitate your dealing with the c-suite.

Consider your audience

Any metric or, beyond that, most conversations you’re going to have in the workplace, can be divided into internal and external audiences. In broad terms, internal metrics deal with nuance, nitty-gritty, and detail. They let other experts on the same level as you know exactly what’s going on, why, and what you can expect to do next. External metrics, on the other hand, deal with the broad strokes and the big pictures. They deal with business outcomes and results - rather than how exactly we’re going to achieve those results.

One of the best tips we have for having these cross-team conversations is to always remember and respect your audience. You’ll do this not only by curbing or expanding on your information depending on the external/internal divide, but also by avoiding language that is music to your ears, but indecipherable jargon to somebody else’s.

You don’t always need the full monty

Whatever metrics you choose, ensure that the wider the audience, the pickier you are about the data you bring. Observability is key in DevOps, so we know that you have a full and fascinating array of data to hand, but if you’re addressing a wider audience, less is more. This doesn’t mean you have to shy away from data-led metrics, but always bringing a full ticket of data for every metric will complicate things and scare people away.

Instead, choose limited metrics to bring to external audiences and try to base them around the people/process/tools triad, which is clear and accessible. Over time, you’ll find which ones work well and which don’t, and you can allow them to evolve as a function of that. As time goes on, you’ll find common points over which departments can collaborate and, as long as they’re useful, you should always make space to let them in.

Better cross-department metrics

"The ROI analysis I think is still very early and immature around dev-ops, and we have lots of hypotheses about that”

Carol Carpenter, CEO ElasticBox

Better cross-department metrics really boil down to one thing. Whether it’s the executive team, marketing, or product, the bottom line is that you need to understand their point of view, and then use your DevOps-given collaborative skills to find the points of intersection.

Understanding the perspective of the "other" is a key skill in all collaboration, whether we're talking about negotiating with secretive forest tribes or convincing the boss to give you a fair chance.

In our E-book, DevOps Business Value: prove it or lose it, we go into some practical ways of understanding your executive team's perspective, but in short, it means really understanding what success means to them, the quickest way to that success, and watching out for problems that could prevent that success. Once you understand, there's a good chance you can talk to them on their own level.

Accept that it will be hard, for the moment, to prove actual ROI - the conversation is still very early. Instead, you're looking to collaborate with the exec team, using your soft skills to adapt and curate the metrics and data that you and your tech team get excited about. With a little careful editing, the c-suite will get excited about them too!