One of the things the other Developer Relations Advocates here at New Relic and I often hear from customers is, "Even though I understand why observability is important, I'm having a dickens* of a time getting leadership to buy in (literally)."

Let me begin by pointing out how important it is for us—IT practitioners—to be willing and able to speak to management and leaders of the business about the work we do, and to do so in a way that is understandable and meaningful to the audience. I'm not implying you have to explain observability in a patronizing "explain it like they're five" kind of way. I mean you need to explain the WHY of observability in the context of what the audience feels is important.

I'm presuming YOU already understand why observability is important—to you, to your team, to your applications, to your network infrastructure, and more. My goal here isn't to write one more DevOps- and SRE-centric love letter to (and about) observability. We already have plenty of those.

The question at hand is, "How can I convince my boss to prioritize observability?"

The key to answering the question lies in where the emphasis of that sentence is. For starters, I need to underscore that this is your boss we're focusing on. Not my boss. Not bosses everywhere. And not your boss' boss (at least not yet). And so I have to ask you to think for a moment about what motivates, drives, and convinces your boss about anything.

Maybe they're motivated by technical ideas or ideals.

Now, I want to be clear: this isn't the same as saying "my boss is technical." I've known plenty of leaders who, themselves, are incredibly non-technical but nevertheless are deeply intrigued with, and convinced by, technical arguments and justifications. Equally, I've seen a fair number of managers who are skilled technologists but nevertheless absolutely refuse to make business decisions based on the technical merit of a particular option.

If your manager is motivated by technical ideas and arguments, you've got it made! In fact, you probably aren't still reading this article. You—the IT practitioner with deep experience in observability—can simply lay out the many benefits (to the manager individually, to the projects currently in flight, to their team, and to the organization at-large):

Reducing downtime even when application complexity and rate of change exceeds the capabilities of traditional monitoring tools.
Improving time to deploy new features while also reducing toil.
Correlating performance to revenue.
Relieving the cognitive load on teams.

Or you can just say, "Ultimately, the goal of observability is to enable teams to take action with shared data. Connect people with processes and technology performance across the entire organization and tie it to specific business outcomes."

After doing so, your manager will nod their head sagely, murmur appreciatively, "Yes, yes of course that's exactly it," after which they will approve every request you place in front of them.

It. Will. Be. Glorious.

But here we are, 500 words into the blog post and you're still reading, so I feel it's safe to presume your manager is NOT one of those rare birds. They don't care about toil, release velocity, or reducing MTTR (or at the very least, they're not factors that influence their approval of projects, tools, or initiatives). They want to understand how observability will impact and, more to the point, improve the business.

If that's the case (and it most likely is) then first I'd like to offer a quick primer on "what the business cares about." It's actually quite simple, with little variation between industries, companies, or even managers.

What every business-minded manager wants to know is how your proposal might:

Increase revenue
Reduce cost
Remove risk

That's it. That is, as the cool kids say, the tweet.

This may be new and even surprising information, even for folks who've worked in tech for decades, but the driving forces behind almost every business come down to those three elements. And if your request doesn't speak to at least one of them, the likelihood of a manager or leader being able to say "yes" goes way down.

I'm not suggesting that you spin some implausible-sounding lie about how observability will somehow double sales in the next 2 weeks, or help your company win the big account. "Increase revenue," while possible, is nevertheless unlikely to be the most relevant benefit observability brings to the table.

It's far more likely you will make your case based on the ways observability can reduce cost and/or remove risk.

The unfortunate news, however, is this isn't something I can describe in a blog post. The truth is, I couldn't describe it even if we were face to face. YOU have to be (or must become) knowledgeable about the specific costs and risks (and sources of revenue, if you think you can make that pitch) involved in your company. This is why I can't tell you what specific aspects of observability will influence your business.

What I can describe is how you can go about framing the information you find.

First and foremost, "say it with data." Be specific. Have both the current situation and trends, and the evidence for why observability will make a positive impact. When I say "have data," I don't mean throw a spreadsheet at people nor do I mean you must patronizingly simplify everything down to a single slide drawn in crayon. You have to present the data in a way that fosters both understanding and appreciation and allows the audience to draw conclusions.

For data to be effective, it must be transformed into information. And information is only useful when it leads to action.

Next, learn the language of business. It is just as unreasonable to demand business leaders become fluent in the technical jargon of our work as it is for me to stand on a street corner in Paris demanding people speak English and give me directions to "Lah fowntayn doo man-ee-keen pees."**

This doesn't mean you need to run out and earn an MBA and begin framing everything in terms of ROI and EBITDA. Simply become familiar with the mechanisms business is built on. Your ability to understand (and put technology into the context of) profitability (vs liquidity), the types of costs, what goes into a three- or five-year plan, and so on may very well be the key to getting your manager on board with observability.

I find IT folks sometimes get hung up on the idea of learning more about business concepts out of fear they will somehow be sucked into "the dark side." One of the joys of learning another language is having the ability to choose to speak one or the other. The language of business is no different. You don't become less technical, you simply gain the ability to frame goals in other ways.

Finally, at least for now, make sure you are approaching the task in a way you can be successful. A mistake many people make, especially when speaking about this subject to IT practitioners, is to propose we "sell" our idea, or "market" our plan, or "get into the management headspace." If there's one thing I know about my career in IT, it's that I never, EVER want to be in sales, marketing, or management (no insult meant to my colleagues in those areas. It's just not where my passion lies). So telling me I must do these things is counter-productive.

What does work, at least for me, is to focus on being a good storyteller. Not "telling stories" in the sense of lying, but in the sense of spinning an epic tale of technical daring-do. If done right, my audience—the manager(s) in question—see themselves and their struggles reflected in the hero of the story, and my suggestion of how to slay the twin dragons of cost and risk can be accepted as a way of protecting our peaceful village... I mean business.

If this sounds like a lot of work, you're not wrong. But having worked in IT for a while, I'm sure you realize the question isn't whether or not something is a lot of work but whether the work is worthwhile. So here's my last bit of encouragement:

Not only is the effort of learning how to effectively make the case for observability worth every minute of time and every ounce of sweat, the skills you pick up along the way will be useful to you in every other project and request you make for the rest of your career.

..* OK, I'll admit "dickens" isn't the word we typically hear. But I'm trying to keep this blog post family-friendly.

..** Which is in Brussels in any case.

Shameless Promotion Section
Join data nerds from across the globe for FutureStack, the observability event of the year, May 17-19 in Las Vegas. Drop in, code on.
https://www.futurestack.com/VyPOLB?RefId=R-DEV|

Making the Case for Observability (to your boss)