A presentation at All Day DevOps: Spring Break Edition by Quintessence Anx
A P R I L 17 , 2 0 2 0 @QuintessenceAnx How to Advocate to Not You: Non-Technical Considerations for our Technical Tools
It starts like this: You want/need a tool.
And so: You prepare a case, focused on your needs and present them.
Source: PhD Comics
After being pulled off stage, you develop a new strategy that looks like this…
Source: XKCD Comics
Why does this happen?
Because you’re trying to discuss tech specs with non-technical people.
What to do instead? 🤔
411 on Modes of Persuasion
Pillars of Persuation
Source: Backdrops by Charles H Stewart
• Need to: establish your credibility • Examples: • “10 years of engineering work has taught me that…” • “When I encountered a problem like this previously, I resolved it by…”
• Need to: logic your way through the issue • Examples: • “Before we streamlined our workflow, we lost Y hours of productivity.” • “The addition of campaign tracking allowed us to see how impactful each of our efforts were.”
• Need to: establish empathy • Examples: • “Implementing these new security features will improve customer trust.” • “Being able to more quickly resolve problems will reduce team stress, which will propagate upwards.”
Keeping these in mind
Know what and when to compromise
Keep the discussion points brief and simple
Provide Context
Reciprocate: Give and Ask
Tying this into the main question
Q: How do we (you) convince non-technical people to value the tools the way you do? A: You don’t!
You convince non-technical people to value your preferred tools from their vantage point.
Let’s do this.
Learning by Example: Build a Case for a Monitoring Tool
Some Anon. Monitoring System (SAMS) and Some Other Monitoring System (SOMS)
Some context for your situation
Currently you have either 1 ) no monitoring (👻) or 2 ) SOMS (👻 👻)
And you want something that exists and doesn’t suck is good.
Unfortunately, SAMS is … well … 💸💸💸
No problem! Just get your boss/company to pay for it!
That’ll be easy! (Said no one, ever.)
Start with the familiar: a basic technical case
What do you want? • What infrastructure do you have? • What languages are your apps written in? • What compliance requirements do you have? • What other tools do you have (integration)?
It might be barely spring, but this rabbit hole already looks like…
Well, this.
Pause and breathe
And then be more abstract
What do you want? • The ability to quickly triage and troubleshoot issues • The ability to integrate with other tools, in the case of monitoring usually at least • A ticketing system • An incident management system • As much tool consolidation as possible • As much compatibility as possible
What do you want? • To see latency issues • To see outages • To see potential vulnerabilities • e.g. If there are recognition patterns for various attacks • To see usage patterns • Can help determine user experience (UX) • Correlate metrics with any latencies or failures
What do you want? • See how New Feature X is working out • Be able to work on Oh My Outage without pausing your work (too much) to give status updates • Be able able to link to specific errors / warnings in your tickets for later…
How does this translate to what they want?
Well, who are “they”? 🤔
Borrowing the “Persona”* concept, define something like…
Define The Personas (a.k.a. Stakeholders) • .Allies Supporters • .Antagonists Competitors • Other Tech Deciders • e.g. security team(s) • Financial Deciders • e.g. executives / management • (And so on)
Focusing on management et al
What do they care about? • How does this benefit: • • • • The team Other teams The business, e.g. the customer experience Them
What else do they care about? • To be kept informed / in the loop / transparency • So they can answer questions without needing to call someone • … or worse be called by someone and caught unawares. • To know the total cost • Not just licensing, but time cost to train and roll out • To know what they’re paying for is being used
Keeping these in mind
Find the overlap
The Overlap • If already familiar with tool = decreased cost • (Less or no time needed for training) • More effective triage + troubleshooting means • Better results for KPIs like MTTR, MTBF • More features, it’s what businesses crave • Integrations = more effective use of existing tools • Compatibility = don’t need to add/replace anything to use it
The Overlap • Decreased latency -> increased transactions -> increased revenue • More automation -> less time lost to manual updates • Tool consolidation = lower costs • Links in tickets = more visibility, fewer pings
Beyond the overlap
Ask for help
“What abouts” discussion points? • What about SOMS? • What about budget? • What if our needs change?
Exec / Manager Visibility
Recall amongst their wants • To be kept informed / in the loop / transparency • So they can answer questions without needing to call someone • … or worse be called by someone and caught unawares.
Non-IT use case: Exec Dashboard
Executive Dashboard • Allows topmost view on health for various apps and systems • Allows the manager or exec to be able to answer “is there a problem?” directly if asked, rather than fencing the question to engineering team(s) • Mobile app, for if/when “on the go” is ever a thing again, would be a huge benefit for upper level execs
Because…
Even Starfleet knows command staff likes dashboards
Slides & Additional Reading https://noti.st/quintessence
Thank you Quintessence Anx Technical Evangelist 🥑 @ https://noti.st/quintessence
One of the things I struggled with as an SRE was being able really grok what non-engineers/non-devs like my manager, whomever they reported to, and various chains in my employer’s business, cared most about when it came time to tool selections. A specific example that I will anonymize and discuss is a business case for changing from Monitoring Tool A to B (Some Anonymous Monitoring System and Some Other Monitoring System) - the final decision isn’t based on B necessarily being a superior tool for a team’s specific technical needs, but rather on other management criteria like license consolidation. Depending on the size of the employer, startup to enterprise, there are increasing numbers of non-engineering folks who have decision making power over the team’s tools. Thus, as devs, ops, etc. we cannot keep our focus on just the technical aspects of different tools and frameworks or we’ll miss the opportunity to appropriately make our case to these other stakeholders. In this talk, I’ll be discussing what these other groups need to know to help them make a decision in your best interest.
*** Important *** To view the ADDO Spring Break recording of this talk, you will need to expand the Cultural Transformation track.
The following resources were mentioned during the presentation or are useful additional information.
The modes of persuasion, often referred to as ethical strategies or rhetorical appeals, are devices in rhetoric that classify the speaker’s appeal to the audience. They are: ethos, pathos, and logos, and the less-used kairos.
What made those descriptions different from all of the rest?
In a nutshell, they expertly employed four powerful rhetorical strategies known as the modes of persuasion.
We are confronted by persuasion in a wide variety of forms every single day. According to a study by a media trend-tracking group, the average person is exposed to more than 5,000 advertisements per day. Food makers want us to buy their newest products while movie studios want us to go see the latest blockbusters. Because persuasion is such a pervasive component of our lives, it is often all-too-easy to overlook how we are influenced by outside sources.
Templates for different audiences, more lengthy guide than the title suggests.
Detailed ideas for how to make an IT Business Case
for free. You
can too.