How to Advocate to Not You: Non-Technical Considerations for our Technical Tools

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…

• You may also hear these referred to as “stakeholders”.

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