Ah yes, the hallmark of any good analytics job description. I want to take a few minutes of your time to unpack what this means, because I don’t think people get it.

Does this mean you should be really good at explaining technical concepts? Should you be proactively sending out a new email every day with your daily digest of insights? Or is this about communicating progress with your stakeholders?

The deviousness behind “strong written and verbal communication skills” is that it’s (probably intentionally) brutally broad in scope. So let’s prune it down.

My thesis: excellence in communication in a business context is primarily about alignment. All else is secondary.

Communication is about alignment, not education

I once regrettably viewed excellence in communication as proficiency in transferring knowledge to my audience, and I imagine for many of you, you’ve defaulted into this understanding as well

But the real world is obviously not academia

Once that is done, and only when that is done, you can focus on the ancillary aspects of good communication — knowledge transfer and dissemination. But if your work isn’t solving business problems, you’re just adding to the noise.

So that’s it. That’s the whole post. But to drive the point home, I’ll throw you an analogy because I know you data people like technical things (the irony is not lost on me).

An analogy: we should ETLT, not EL

Analytics is a lot like ETL/ELT. But instead of loading data into your warehouse, you’re pipelining business requests and munging the artifacts you procure along the way.

Specifically, the optimal analytics process (in an ideal world) looks a lot like ETLT:

• Extract (get) request

• Transform it into a business objective

• Load it into the warehouse w/SQL

• Transform the result into words

And to clarify, I don’t just mean inbound requests — even proactively sourced analyses qualify as part of the “extract” process. Any request, idea, or suggestion that spurs your itch to dumpster dive into the data should be categorized as part of the extract process.

The problem: we spend too much time on the technical bits of the analysis and not enough on the pre- and post-analysis process: ensuring that what we put in and what we get out is valuable. We too often drop the two transform steps (the blue boxes above). I.e.:

1. We dumpster dive w/o thinking about business objectives

2. We drop results without interpretation

Or, in other words, we are doing ELT, ETL, or just plain EL.

• ELT: dropping the transformation of an inbound request into the underlying business objective. This means poor alignment, wasted cycles when the wrong question is answered, an excess of follow-up requests because your work doesn’t actually do what your stakeholders expected it to do.

• ETL: dropping the interpretation. This can be fine at times, but as the expert on data, you’re shirking your responsibility if you always leave interpretation of data up to non-technical folks. This is the offense most likely to lead to bad decisions.

• EL: when you’ve given up and are working as a SQL monkey. For your own sanity, you need to expand the scope of your role.

Why you shouldn’t leave this to stakeholders

If you don’t pull data that’s aligned with a clear business objective and communicate so your findings so they are applied correctly, your stakeholders will have no choice but to take on this work themselves. But no one is going to be as well-versed in using data as you are, so they will inevitably butcher this. They’ll come up with the wrong requests and have the wrong interpretations.

Things I’ve heard:

“Whoa 400 people clicked that button? That means the feature is a success!”
Nope.

“That’s not nearly enough <BUSINESS SEGMENT HERE>. We shouldn’t go into business there.”
No, it was enough to drive the metric we wanted, and we did.

“This has an NPS score of X! That means it’s impactful!”
It wasn’t, we axed the program because it was experimentally neutral and a huge cost center.

I love my stakeholders, but they just don’t speak in data (and honestly, shouldn’t be expected to) — it’s your responsibility to do that for them or you’re hamstringing the impact of your data work.

What to do about this

Alright, let’s take a step back from the technical analogy.

Some practical advice: humans tread desire paths, so if your business counterparts are used to working with analysts in a way that doesn’t involve them outside of the technical work, it’s going to be hard to change that. In my experience, there are two immediate steps you can take: (1) ask why and (2) write up your work.

There will be some resistance. But the great boon here is that even your baby steps should start to kick off a virtuous cycle: high leverage analytics work is a preferential attachment process — the more you add clarity of thought and interpretation to your work, the more your work will be valued for its clarity of thought and interpretation, and consequently, the more interesting work you’ll get in the future.

So: Listen better. Explain better.

A final comment on Hyperquery

Okay, I know I promised no vendor content on here. But up-leveling this workflow is our bread and butter at Hyperquery, so I thought I’d say my piece. There are a lot of tools for technical exploration work, but they tend to make the rest of your work — sharing, aligning, organizing, communicating — a huge mess. If you want to try an exploratory analytics interface that can make it easier to communicate, try out Hyperquery. 🙂