If you are familiar with my articles, you know I’m a big advocate for stakeholder management skills. I’m a true believer that a good data scientist should not only be an effective implementer of stakeholders’ data vision, but also a thought partner that helps stakeholders find analytics solutions for their business problems. However, just like the process of building up any skill, working with stakeholders will not always be smooth sailing.

I have definitely encountered my fair share of frustrating stakeholder situations; some of them quite honestly used to ruin my day. Unfortunately, those situations are fairly common based on my conversations with other data scientists. . If you are a stakeholder of a data team, I’m hoping this article will shed some light on how to work more effectively with your data partners and be a better stakeholder. If you are a data scientist, hopefully you can get some inspiration how to NOT let the following statements ruin your day but use them as opportunities to find out the stakeholder’s real needs.

1. “This (result) is different from what I thought…”

While it is a very common response I get from stakeholders. It’s honestly not the worst among all the ones I will mention in this article. Nonetheless, it’s frustrating because it’s too abstract to provide any value.

However, stakeholders’ domain knowledge is often extremely valuable for data work because usually those sniff tests are the first line of defense against any data error or other mistakes. So when this statement is made, it’s actually a perfect collaboration opportunity for data scientists to dig deeper.

How to turn frustration into opportunity

Sit down with the stakeholder and ask questions. Find out exactly how the data/result of the analysis surprises them. Then with their help, dig into the data to determine the root cause of the discrepancy. Of course, just because the data does not fit someone’s expectation, it does not mean it’s wrong. But sometimes this kind of root causing will provide new insights into the data or business processes and might help you uncover a data issue that you might not have noticed without domain expertise.

2. “We need this (data, analysis, XX) yesterday”

Honestly, whoever invented this phrase should have been branded as the worst collaborator of the year and exiled to social Siberia. The only solution-driven response for this passive aggressiveness would be “oh, then let me grab a time machine…”. Understandably, a lot of data needs are urgent (or at least they appear like that at the moment). But most analytics projects cannot be churned out in hours like high-level slide decks, so efficient communication about the timeline and needs is very helpful for data scientists to prioritize their work.

How to turn frustration into opportunity

Try to find out why the project is urgent and what the most reasonable timeline for it is. Be crystal clear about why it’s not possible to develop something instantaneously and manage expectations.

Also, it’s likely that if something is super crucial, it’s not the first time someone has thought about doing it. So most likely some work has already been done to help answer some part of the ask and will buy everyone a little bit of time to develop more complete solutions. Not reinventing the wheel can save you a ton of time as a data scientist.

Finally, in order to avoid situations like this from happening repeatedly, try to understand where the breakdown in communication happened. If someone needed this analysis yesterday, and today is the first time the data team is hearing about it, someone likely did not loop you in early enough.

3. “Why can’t we find a temp solution”

We can, but at what cost? There is a permanent discrepancy between the time it takes to develop robust data tables/sources and the speed the business needs to answer questions. As a result, the business often asks for hacky interim solutions. Don’t get me wrong; I’m all for hacky solutions when necessary, as long as everyone is aware of the caveats and still works on developing a long-term solution to replace the stop-gap eventually.

How to turn frustration into opportunity

In my opinion, the best data scientists can help stakeholders come up with relatively robust temp solutions and in parallel help design long-term sustainable solutions. One example is when data for analyses or metrics monitoring is not being recorded in the database. The stop-gap solution could be asking someone to manually record the data in an Excel sheet if the number of entries is reasonable. In these situations, data scientists are usually the domain experts to design the data entry sheet to guarantee data integrity (e.g. build in dropdown lists instead of using free-text entry etc.).

However, it’s important NOT to stop there; temp solutions usually won’t scale and often take a disproportionate amount of time to maintain. It’s crucial to get the required alignment to develop a scalable long-term solution (e.g. in the example above, have Engineering commit to start automatically logging the required data by date X); otherwise, you will be stuck with inefficient, menial tasks for all eternity.

4. “Can we have real time data?”

Real-time data is overrated… in a lot of cases. Data latency ONLY becomes an issue when it delays decision making. So the first question I ask in those situations is “What decisions will be made based on the real-time data?” to make sure the answer is NOT “It would be cool to see it in real time”. It turns out, many managers are interested in seeing data with virtually no delay, but often do not have a clear idea of what they would actually do with it.

How to turn frustration into opportunity

In some situations, real-time data is absolutely necessary. A good example would be the real-time surge pricing algorithm used by Uber. Without real-time data, the model can’t work to correct the supply and demand imbalances of the marketplace. However, surfacing real-time data to humans (as opposed to ingesting it into a model) is often much less valuable. It is difficult to act on and often just results in information overload. In most cases, especially if it’s for metrics monitoring purposes, real-time data is at most a “nice to have”.

Good data scientists should be able to listen to stakeholders’ pain points and their reasoning for wanting to have real-time data and be able to act as a thought partner in determining the right data latency and retention period for the use case.

5. “Why does XX (analysis, data visualization, etc.) take so long if the data exists already?”

People with no data background often mistake the existence of data for the usability of data; just because a piece of data “exists,” doesn’t mean it’s in a digestible and usable format, at least not to people with no in-depth data training. And every data scientist knows data cleaning and formatting takes a painfully large amount of time in their day-to-day job. Unfortunately, this lack of understanding of data usually leads to mistrust between stakeholders and data scientists.

How to turn frustration into opportunity

It’s important for data scientists to learn to explain analytical concepts in layman terms and bring the stakeholders along on the data transformation journey. If the data “exists” in the database but as a raw log, then showing a small sample of data to the stakeholders may help explain why it’s hard to generate any informative insights and/or visualization before transforming it. The better business stakeholders understand the data analytics workflow at a high level, the more empathetic they can be of your timeline requirements.

Article was originally published on Towards Data Science.