A policeman sees a drunk man searching for something under a streetlight and asks what the drunk has lost. He says he lost his keys and they both look under the streetlight together. After a few minutes the policeman asks if he is sure he lost them here, and the drunk replies, no, and that he lost them in the park. The policeman asks why he is searching here, and the drunk replies, "this is where the light is". - The Streetlight Effect
This rant is based on a LinkedIn post I did earlier this week.
Data professionals often act in ways surprisingly similar to the drunkard standing under a streetlight, hopelessly searching for their keys. When interacting with “the business,” we spend our time discussing data (where the bright light is), avoiding the hard stuff like learning how to speak to stakeholders in their language and discovering and solving problems they care about (the pitch black area where your keys are lost). This should be so blindingly obvious that it doesn’t need to be mentioned. Yet like the drunkard, we often do inexplicably pointless and wasteful activities.
Here’s the deal. The business doesn’t care about data1. The business cares about making money. If data can help make money, people care, and data get more investment. When data is a costly distraction, bye-bye data. Data is just a means to an end. As a data professional, the sooner you realize this, the longer and more successful you’ll be in this industry. Ignore this at your own risk.
This is a conversation I’ve been having with various data professionals and luminaries over the last few weeks. The most significant thread to this discussion is that, as technicians, talking about data and technology is easy and well within our comfort zone. It’s what we’re good at. It’s also where we fall short.
I speak from experience, and here’s one of many examples of how I learned the hard way about how to talk with non-data people properly. Having finished my math degree, I figured my time on the job would be spent with fancy statistics and writing cool algorithms. My first job out of school was doing forecasts and pricing optimization for a consumer packaged goods company. During my first week at a new job, my boss asked me how things were going. I got into a very mathy discussion about exponential smoothing and correlations. In the discussion, I did not talk about the problem he needed to solve or use the language he could understand. After a minute of hearing me talk, he said, “When I ask for the time, don’t tell me how to make a watch. Just tell me the time.” Point taken. I humbly returned to my desk and spent the weekend reflecting on what he said. He was spot on. I was just blathering.
As Bill Inmon (the father of the data warehouse and good friend) replied in my post.
Bill’s 1000% correct2. We’ve got it entirely backward. The divide between data and business will not be solved until we stop approaching things from a data-first viewpoint.
The solution is to learn to speak the language of your stakeholders and work to truly understand their needs. If you can, have regular lunches or calls with them to get updates on their challenges and how your initiatives are helping them. Get nerdy here. Track the progress of your conversations with stakeholders - Is there alignment with your stakeholders, and how data fits their needs? Was the discussion cordial, or were there arguments? Another suggestion is to get stakeholder feedback using a customer satisfaction score (CSAT) or net promoter score (NPS). You get the idea. This exercise gets you outside of your data bubble and creates a feedback loop with your stakeholders and your outcomes with data.
Again, this rant is to say - stop leading with data in your discussions with the business. Learn and speak the language of your stakeholders. Only after you genuinely understand their problems should you start thinking about using data as a solution.
If you’re at a “data native” company or somewhere with mature data practices, this point is moot. Carry on.
Also, a shoutout to Chad Sanderson. He’s working on some cool stuff.
The Business Doesn't Care About "Data"