>>Folks in IT often actively avoid learning
how to speak the language of business.
We fail to acquire the skills that allow us
to make our case and this doesn't serve us
as monitoring engineers or as IT professionals.
We can do better
and that's what I'd like to discuss.
But first, I'd like to start with a story.
This is my friend Phil.
Now, it's hard to get a sense of scale
but Phil is 6 foot 4.
He's every ounce of something north of 300 pounds
and he's been my friend since high school
which is the only reason he would let me
use this picture of him.
Now, Phil is an executive chef.
He studied in the Culinary Institute of America.
He's had jobs like being the executive chef
over at The Ritz-Carlton few other places.
But now Phil has a cushy job as an executive chef
at a 500 bed major metropolitan hospital system.
So, for those people who aren't familiar with
how commercial food preparation works
here's a little bit of a summary.
Meals are planned and prepped three services ahead.
After breakfast the staff is already making
breakfast for the following day.
Food is prepped to 75% and then it's put into a
cooler, not a freezer, a cooler.
At meal service the food is brought out
heated to 100% and served which means that
proper cooling temperature is essential to avoid
problems that put people into the hospital.
Well, my friend Phil came and told me he was
having a problem with his coolers.
It wasn't keeping everything at the right
temperature which meant there were a lot of
problems with the food and that was an issue and
I thought oh my gosh this is my chance to help my friend.
I mean all I would need is some CAT5 cables
some industrial temperature sensors a little
Raspberry Pi Box and all of a sudden
Phil's gonna have notifications on his phone
about when the food is too hot or too cold
or out of spec or whatever it is.
That's great we priced it out $5000 out the door.
Fantastic
Phil took the idea to his management and their
response was less than enthusiastic let's just say.
All right fine; we tabled the idea no big deal.
Well three months later it happened.
The air conditioning went out.
Actually, that's not what happened.
What happened was somebody on third shift
left one of the cooler doors open
that meant the compressor kept running
all night and around one o'clock in the morning
the compressor completely died which meant
that the temperature in the open cooler and
all the other coolers started to rise steadily.
By the time first shift came in none of the food
was able to be used which meant they had to
have an emergency food order.
They needed to have emergency overtime
to get everybody in to start preparing
breakfast and then lunch and then
all the three meals ahead.
Of course they had an emergency repair
for the air conditioner total cost, say it
with me now, one million dollars.
Okay.
Let's do some Monday morning quarterbacking what went wrong.
Maybe the executives are less than enlightened.
It's possible, however that's not what went wrong.
What went wrong is that a geek, a technical person,
explained a technical solution to a chef.
And then that chef had to explain a technical
solution to a business executive.
So you think maybe the value proposition of that
whole thing was lost in translation?
Yeah that's what happened.
So what I want to talk to you about is how to make our case.
And there's really two times that you can make your case.
Upfront when you're setting up monitoring
or every single day.
Let's talk about making our case upfront first.
Now before I go into that I'd like to point out something.
In IT we love languages.
We love our Command Line languages whether that
is the DOS prompt or PowerShell or whatever it is.
We love our programming languages.
The one true line of code whether that's
.NET or Perl or anything else.
We love our different monitoring systems
which have their own syntactic variations.
We love our languages that belong to culture.
For example, Star Trek or Star Wars or Tolkien or
different sports, like I dunno, curling that have
their own language that go along with it also.
And finally we love our actual languages
Spanish and French and Klingon and Elvish
and all of those.
We love those languages and the thing about
those languages is that they give us a sense of
culture that comes along with it.
And I'd like to point out the business
is just another language.
Now, when I learn a language it doesn't mean
that I stop being able to speak my original
language, it also doesn't mean that I become
the culture that goes with that language
I simply have an appreciation for it
and that's what we wanna do.
So, I'd like you to dust off your passport
because I'm gonna take you to a strange
and exotic land called management.
Cause we're gonna learn to speak that language now.
So here is the Xenophobe's Guide to Management.
First of all I have to ask a question.
Do you even know what the business wants to hear
about problems, let alone how to communicate it?
So you probably don't and there are two major
fears that IT professionals have that hold
them back from learning this type of language.
The first fear is that if we understand how
management thinks the next step is we become
that pointy haired boss. Right?
But that's not the worst fear the worst fear
is if we learn how to sell a solution.
Oh sell?
That means we become sales and that means we
become pure evil, so we don't want that to happen.
And the fact is that's not true.
It's also not effective.
You see management doesn't care about the tech.
So stop talking about it.
If I'm standing on a street in Paris screaming
in English not only are people not going to
understand me they're not gonna wanna help me either.
Stop shouting in tech to management.
But there's some good news
they don't care because they hired you.
You're the one who understands that language and
they believe you when you say this is gonna work.
Really what you need to do now is translate
it into a form that they understand.
And the other good news is that business
really only cares about three things.
They care about increasing revenue,
reducing cost or removing risk.
You need to frame your technical project
in one of those three ways or more and then
they're gonna be able to listen to you.
They're gonna be able to understand.
You won't be shouting in tech to somebody
who doesn't speak that language.
And the fact is that your manager
wants to help you, they wanna say yes but
you need to help them by giving that business case.
Because even if your manager is one of those people
who's made that leap from a technical role
into a management role they have to explain
it to their boss who probably doesn't
have that background.
So you need to help them do the translation as well.
Or to put it another way.
If you like it you shoulda put it in your
fiscal request for the budget year.
[upbeat music]
All right so that how to make the case upfront.
After a short break I'm gonna talk about
how to make the case every single day.
[Upbeat music]
Welcome back
Now I'd like to talk about how we make
our case every single day.
So what you're looking at is a fairly
standard monitoring design.
You've got the three pillars of observability.
You have an alerting engine.
You have a ticketing system tied to a knowledge base.
And of course you have long term storage and reporting.
So what's missing from this design?
Was it worth it?
Is any of this, any single monitor, any single alert
worth the effort that it takes?
Well, how do you know that?
How do you figure it out?
Here's one way of calculating it.
You take the cost to run a system per hour
per minute the value that it brings in
something about it something financial
about that system.
You take the duration of an unalerted event.
That means the time it takes to notice a problem
and then the time it takes to repair
that problem and then you see what monitoring
and alerting reduces in terms of that time.
That gives you the formula to know how much
value an alert or monitor brings to the system
and that's how you know whether it's worth it to do it.
Now of course you can make that
formula much more complicated.
You can add in variables like the cost of an
emergency vendor visit or the cost of staff
overtime during repair or the cost of emergency parts.
This should start to sound a little familiar because
it's exactly the story of me and my friend Phil.
This is what we did wrong.
If Phil and I had done the math
and brought that to his management
we'd have gotten the system and they wouldn't
have had to spend a million dollars to save $5000.
The mostly unnecessary summary.
Do you buy those protection plans from
the electronics store?
You probably don't because you don't need to spend
$5 to protect your $20 headphone investment.
But you do buy the extended warranty on your car
because the left tire rod could cost you $80000.
Don't let monitoring fall into the same trap.
You need to be able to understand the value
that monitoring has.
You need to have the numbers that prove
that value and you need to build the skills
to communicate that value to management
the people who are going to enable you
to put that monitoring in place and provide
that value to your organization.
Thank you.
[upbeat music]