Should we be more persuasive?

Let's talk about persuasion, intellectual honesty, and how we should toe the line.

👋 Hello! I’m Robert, CPO of Hyperquery and former data scientist + analyst. Welcome to Win With Data, where we talk ~weekly about maximizing the impact of data. As always, find me on LinkedIn or Twitter — I’m always happy to chat. And if you enjoyed this post, I’d appreciate a follow/like/share. 🙂

---

We data folk tend to be loudly logical. We lament even the most subtle logical fallacies — post-hoc justification, multiple hypothesis testing, when correlation is presumed to be causality. So of course, we’d scoff at any argument that strays from pure cold logic. We’re Ts, not Fs, on the Myers-Briggs spectrum. We wear our intellectual rigor with pride. No decision is better than a mis-informed one, we say.

Unfortunately, no matter how often you say “this data is too rough to make decision X,” people are going to what they want. The realities of business might be intellectually sloppy, but the realities of business are real and so must be faced. In response, some of us wash our hands of the subjectivity, leaving interpretation of our work entirely up to our stakeholders. Or, more insidiously, others of us take the path of darkness, trying to persuade our stakeholders of our supposedly unbiased viewpoint.

In this post, I’ll talk about how to toe the line, and inject our take into the conversation without sacrificing our intellectual honesty. I believe we should not persuade, but we should certainly advise. I want to propose two behavior changes to consider making: (1) you should always come with a recommendation, and (2) you should understand how your work will be used.

Have a recommendation

A former coworker of mine once created an elegant deep-dive into one of our company’s core metrics. He was technically apt, of course, and I recall thinking he had some intellectually interesting findings — ratio metrics that exhibited curious instabilities. But when stakeholders tried to make these findings actionable, he had no real recommendation. Worse, he’d push back against any attempts at bringing him to one. Not conclusive enough. More research required.

And that was the problem: he didn’t solve anything. He found a few interesting things, but they had no bearing on any business decisions. And when decision-makers pored over his ideas trying to find something actionable, he shooed them away. This may sound obvious, but the lesson to take away here is simple: you should have a recommendation. Data teams are not responsible for simply exposing data — our charter is to maximize the impact of organizations through data. And that is tautologically best achieved by not simply sharing raw data, but by shaping the interpretation of that data to the problem at hand.

But many of us would deign to offer a recommendation. Only when it’s tortured out of us by our stakeholders and only with numerous asterisks do we mutter our quiet “the data suggests that the presence of water on the ground is a consequence of prior precipitation, but we cannot definitively say so without the presence of a control universe.”

But you should do your best to always have a recommendation in mind. This is for two reasons:

1. It forces you to learn deeply about why you’re analyzing data.

   Too often we respond to requests reactively. Defaulting to having some recommendation means you need to understand what your data is being used for, nudging you to take one of the most important actions when working with stakeholders: asking why.

2. It conforms your work more closely to the decision being made.
   Thus, you create a more direct line to impact. Your work more closely aligns with the intended decision, meaning it’s more likely to be used in the way you believed it should.

So enter the messy fray. Ask why, give recommendations, and argue with your stakeholders until you can get to a better representation of what’s true.

Understand how your work will be used

Imagine you’re driving somewhere. You’ve set up your GPS, and you’re on your way. Your good friend Al the Analyst sits in the passenger seat. You ask Al to think about where to eat. He does some research, then presents his findings. He has a long list of restaurants, grouped by food type, by proximity, by Yelp rating. He goes on to discuss the economic impact of the different restaurants on the local community. He finally gives you a recommendation: let’s eat at The Win With Data Diner to maximize impact to the local economy.

But it turns out its 50 miles off the route. It also turns out you can’t eat there because you’re vegan. While the wealth of information that Al provided was undoubtedly fascinating, he committed a cardinal sin that we analysts often commit: he did his analysis without thinking about how it would be used.

And while not so absurd, this is often what we do. We craft elegant analyses, then expect force our stakeholders to sift through it until they find something relevant to them. Instead, we should understand the decision space that our stakeholders are in, then help them to optimally bring the key points of your analysis into it. Your analysis isn’t everything, after all, stop acting like it is.

Final comments

Perhaps I’m giving stakeholders too much credit. The tenuous assumption behind everything I’ve written so far is that stakeholders are willing to engage in an intellectually honest discussion with you, which certainly may not always be the case. Your stakeholders might be looking for numbers they like, rather than the truth of the matter. And all I can say in those instances: try to double down and spelunk into your stakeholder’s brains. Behind all intellectual dishonesty there’s always some sort of truth to pull out.