Remember how adults sound in Charlie Brown? When data scientists communicate with stakeholders, an overabundance of technical jargon can quickly become an ineligible blur of wah-wahs.
The term’ convolutional neural network’ can come across as, well, convoluted. Meanwhile, to the untrained ear, ‘bias-variance tradeoff’ is an incomprehensible concept; understanding each individual word won’t bring those outside of the field closer to grasping the term’s deeper meaning.
When the language data scientists understand and use in conversation is so easily lost in translation to the various parties and teams they collaborate with, finding a way to translate complex concepts into digestible bits is crucial.
“Data science can be difficult to communicate even to informed audiences, so it is always important to keep in mind who your audience is and adjust for their background knowledge,” said MORSE Corp’s Lead Data Scientist Kaci Kus. “Communication is also a two-way street.”
According to a 2022 Data Science Skills survey, the ability to communicate effectively is the third most essential quality recruiters look for in data science professionals. Only hard skills like machine learning and statistics are more valued than this soft yet integral skill.
Communicating details and insights to non-technical parties effectively ensures insular concerns defy semantic limits to reach a cross-functional audience. Data scientists must bridge these gaps to reach a wider audience; only then can the true impact of their work be applied.
Built In Boston spoke to data scientists at five different companies to better understand how their teams communicate technical concepts to uninitiated audiences and how this attention to delivering data insights to non-technical stakeholders secures buy-ins.
Liberty Mutual is a Fortune 100 company and a leading property and casualty insurance provider.
How does frequent communication with cross-functional stakeholders — especially non-technical ones — benefit your team?
One of our core mantras on the data science team is that we build with our stakeholders rather than for our stakeholders. That means we co-create in an agile manner. We are consistently talking to them and showing our progress to gather quick reactions and feedback and pivot if needed. “No surprises” is another key mantra. Spending time with our stakeholders immensely increases our data scientists’ knowledge about the business and the challenges our stakeholders face, which allows us to build better products.
Data science is highly technical. When it comes to updating non-technical stakeholders on your team’s latest efforts, how do you translate the complexities of your work into digestible language?
I have found that it is very critical to present information to our stakeholders in a style and manner that is most relevant and relatable to them. Our data science teams emphasize “de-teching” our presentations before each meeting, where we take a step back, think about the most technical concept and discuss how we can present it in a digestible way.
Our stakeholders are immensely smart in their domains and busy, so the last thing we should be doing is sharing technical terms like AUROC or Confusion Matrix or Convolutional Layers without context. The key is to make time to do this “translation” before any meeting.
I have found it is critical to present information to stakeholders in a manner most relatable to them.”
Share an example of when you needed to get buy-in for a data science initiative from a non-technical stakeholder. How did you secure that buy-in, and what learning did you take away from it?
We recently worked with a very successful and experienced stakeholder who manages a large portfolio. Their business deals with very low frequency and high severity risks. When we started working with them, there was healthy skepticism about whether data science tools could find any signal to differentiate risks. We started our work by showing them examples of similar “finding-needle-in-the-haystack” problems that we had solved in other domains.
Over a few months, by working closely with the stakeholder and their team, we built an AI model that could help them segment their risks and increase business profitability. A lot of the insights we generated proved our stakeholders’ hypothesis, but we also were able to generate new insights that have proved very valuable to them. The key learning here was that irrespective of how good our models are, we won’t get value if our stakeholders don’t trust it and use it — so winning their hearts and minds is as important as building a world-class model.
WHOOP’s wearable fitness tracking device and performance optimization platform empower users to perform at a higher level.
How does frequent communication with cross-functional stakeholders — especially non-technical ones — benefit your team?
Very rarely can a project be carried out from beginning to end without cross-functional collaboration and communication. Most of the projects we work on at WHOOP require many components — some technical and others non-technical — to ship a final product. If these pieces are developed in isolation, the end result is incredibly messy: either timelines get delayed or there’s a lot of scrambling and stress, resulting in the team delivering a subpar product.
Without regular communication, teams that are oriented in ever-so-slightly different directions at the start of a project will end up in very different places. However, when teams meet regularly and operate in lockstep, each team can make micro-adjustments to keep their trajectories tightly coupled. Keeping cross-functional teams aligned throughout a project takes time and effort, but it’s always worth it.
Data science is highly technical. When it comes to updating non-technical stakeholders on your team’s latest efforts, how do you translate the complexities of your work into digestible language?
Visualizations are key for communication with non-technical stakeholders. And with particularly complex data science topics, interactive visualizations can be really compelling. When creating figures to represent complex ideas, remember Edward Tufte’s graphical design principles; one of my favorites is the data-ink ratio. The idea here is that there should be no redundant information on a figure, so erasing any feature of a figure — size, color, a dimension — would remove information from the figure as it’s not captured elsewhere. Some critics feel that Tufte’s principles are too strict, but I think the idea generally holds. Every aspect of a figure should be intentional, whether redundant or not.
Another key piece for working with non-technical stakeholders is to develop a shared language around data. Fortunately, WHOOP employees — both technical and non-technical — live and breathe data, so developing this shared language is much easier. It’s important to align with stakeholders on key terms and metrics that you’ve defined, avoid overly technical language and encourage questions and feedback.
Visualizations are key for communication with non-technical stakeholders. With particularly complex data science topics, interactive visualizations can be really compelling.”
Share an example of when you needed to get buy-in for a data science initiative from a non-technical stakeholder. How did you secure that buy-in, and what learning did you take away from it?
At the beginning of the COVID-19 pandemic, I was really curious about the effect of a SARS-CoV-2 infection on WHOOP metrics. Members were able to record in the mobile app when they tested positive for COVID, so I scraped together an analysis looking at deviations in WHOOP metrics in the days before and after members reported testing positive. My boss and I pitched the idea with the analysis, and a few weeks later, we published a paper in collaboration with a research university.
Developing an initial proof of concept to share with stakeholders — whether that’s an n-of-5 analysis or a visual prototype — can be a helpful tool for conveying the impact of a data science initiative. And the impact is the important piece to focus on when getting buy-in from non-technical stakeholders. It’s easy to get lost in the technical details of a creative architectural solution to a complex problem, and these are certainly important pieces to think through when understanding feasibility. When trying to convince stakeholders, the high-level impact on key metrics that stakeholders value should be the central focus of the pitch.
MORSE Corp. provides practical solutions to solve complex multidisciplinary national security problems.
How does frequent communication with cross-functional stakeholders — especially non-technical ones — benefit your team?
Frequent communication with cross-functional stakeholders benefits our team by improving our understanding of the context of the work so that other data scientists on the team and I understand the impact our tasks bring to the larger project. I have had several experiences where non-technical stakeholders provided real-world examples of how data science might help them with their objectives. These conversations offer valuable insight that we wouldn’t have known without open communication and are often the inspirational spark behind new research projects for the team!
Communication is also a two-way street. By improving our understanding of the problem space, we can provide better solutions and, in turn, communicate those solutions to stakeholders meaningfully. One of the biggest benefits of regular communication is that it helps us to align stakeholder expectations with the capabilities and limitations of data science so everyone is on the same page.
Data science is highly technical. When it comes to updating non-technical stakeholders on your team’s latest efforts, how do you translate the complexities of your work into digestible language?
Data science can be difficult to communicate even to informed audiences, so it is always important to keep in mind who your audience is and adjust for their background knowledge. This means avoiding jargon and choosing examples and analogies that the audience will relate to. Providing real-world examples also helps to bring the data science concepts to life and communicate value to the audience.
Data visualization is an overlooked skill for data scientists, but it is essential when it comes to communicating results. We spend a lot of time choosing specific charts, graphs and diagrams to represent the data and our results visually. For example, if we want to communicate high-level takeaways, we may use a simple bar chart as it is clean and easy to interpret at a glance.
However, if we want to communicate data distributions, we might choose a violin plot, box plot, swarm plot and so on. There are many different options for visual communication, so it is important to be thoughtful with the choices you make. Lastly, we always get feedback on reports from a variety of people on our team before the final delivery to stakeholders to try to ensure we can improve any potential gaps.
Providing real-world examples also helps to bring the data science concepts to life and communicate value to the audience.”
Share an example of when you needed to get buy-in for a data science initiative from a non-technical stakeholder. How did you secure that buy-in, and what learning did you take away from it?
Recently my team has been reevaluating our methodology for making test-validation data splits. This is the process of deciding what data a machine learning model should be evaluated on, which has significant implications for which model gets recommended for deployment. We had been doing the same methodology for a long time, and so we needed to communicate our reasoning behind the change clearly.
To get buy-in, we first broached the topic to try to understand how much push-back there would be. This gave us an initial understanding of what information we would need to provide to gain support for the new method. After getting a feel for the stakeholders’ perspectives, we prototyped the new methods on existing data and analyzed how they would impact past results. Doing experimentation work on real data was extremely valuable as it demonstrated the benefits of the change realistically and enabled us to flag potential risks up-front. By clearly explaining each method’s pros and cons, we showed a high level of understanding of the problem space. In the end, we were able to get all external stakeholders on board by communicating clearly early.
Linus Health’s platform provides users with up-to-date brain health insights by leveraging neuroscience and AI technology.
How does frequent communication with cross-functional stakeholders — especially non-technical ones — benefit your team?
Frequent, honest and open lines of communication between cross-functional teams and stakeholders are absolutely essential for a successful project. For the data science team at Linus, we need to put out work in context with our internal medical subject matter experts, ensure alignment with market forces through our product teams and engage with downstream engineering teams to integrate our models and data products seamlessly. Having all data science team members, including junior team members, at the table from day one ensures we maintain a holistic view of our projects. This increases both engagement within the team and awareness across teams, producing a strong product overall.
Data science is highly technical. When it comes to updating non-technical stakeholders on your team’s latest efforts, how do you translate the complexities of your work into digestible language?
Updating executive and senior leadership on technical output from data science teams is a critical skill for senior and lead data scientists to master. I find that translating highly technical outcomes into easily digestible ones is best accomplished through three questions: What did we do? How did we do it? Why does it matter? And doing so in as few slides as possible.
In a perfect world, executive sponsors have already signed off on the project’s importance for the business. This makes it easier to reiterate the value when delivering results. Then it’s a matter of a quick summary, one to two compelling graphics summarizing the results and then closing the loop on whether the expected value was realized.
Quite often in data science, an outcome is difficult to quantify with KPIs, so it is key to translate the findings into the next steps and validate learning. To borrow a phrase from Eric Reiss, “Stakeholder updates, regardless of background, must strike a balance between highlighting the key project outcomes and conveying how these outcomes can be incorporated into the project or product roadmap.” Finally, never come to the table with a problem without a solution!
I find that translating technical outcomes into easily digestible ones is best accomplished through three questions: What did we do? How did we do it? Why does it matter?”
Share an example of when you needed to get buy-in for a data science initiative from a non-technical stakeholder. How did you secure that buy-in, and what learning did you take away from it?
At Linus, we do a significant amount of R&D that can take many cycles before making it into production. It is all too easy to lose touch with product teams due to the nature of these data science initiatives — long burn, low certainty of success but high reward. We recently successfully crafted several models we thought were good candidates for incorporating into our healthcare delivery platform. However, the product teams had filled out their backlogs and were loath to incorporate a new feature they weren’t familiar with. Rather than wait until the backlog opened up, which at Linus can be several quarters, we put together a proposal that explained the model, presented a range of options for incorporating it and quantified both the internal requirements and dependencies and an expected return from the market.
This engaged the product and design teams in the conversation about new capabilities arising from the proposal and resulted in a plan to incorporate the model in the near term and a roadmap to continuously iterate and integrate related features in the future. The key to securing buy-in was to meet them in the middle with a well-thought-out set of options.
Ahold Delhaize USA, the e-commerce engine of Ahold Delhaize USA, is an online grocery business.
How does frequent communication with cross-functional stakeholders — especially non-technical ones — benefit your team?
When we first established our data science department, communication with cross-functional stakeholders was not frequent. We mostly interacted with our product team, who then managed communication with our other stakeholders.
Two years after we started the department, this paradigm shifted dramatically. Our solutions saw drastic growth, and we were able to scale and expand with new use case scenarios across the organization. When we started to see that most companywide use cases were achievable by reusing existing work with a layer of customization, we opened the communication channel from every cross-functional stakeholder directly to our data science team. We also created our business solution architect department to handle this system.
Now that this line of communication is open, I would say we’re communicating on a near-daily basis, particularly with merchandising, marketing, product, media monetization and supply chain.
Data science is highly technical. When it comes to updating non-technical stakeholders on your team’s latest efforts, how do you translate the complexities of your work into digestible language?
It all depends on the initiative we’re presenting. Personalization is a well-known mechanic in the market, even for non-technical stakeholders. I usually start with competitor applications of the work we deliver. For instance, when we delivered a new algorithm that predicts your next shopping cart, I referred to the “buy it again” module that you can find on Amazon and Target.
When we’re delivering a new, innovative module that we don’t find commonly on our competitor landscape, I simplify the core algorithm and explain it in a few sentences.
For example, we could use our new algorithm — “Predict My List” — and break it into three parts: “Staples,” “Complementary” and “Inspire.” Staples is an algorithm that predicts what you will order next. Complementary identifies products that go well with those Staples. Inspire refers to items that are new to the consumer but could easily become Staples in the future. Breaking it down this way makes the information digestible and easy to understand. Now if a person wants details on the core logic, I go a bit deeper and explain what data we use and some of the business rules.
We’re communicating on a near-daily basis, particularly with merchandising, marketing, product, media monetization and supply chain.”
Share an example of when you needed to get buy-in for a data science initiative from a non-technical stakeholder. How did you secure that buy-in, and what learning did you take away from it?
Buy-ins are easier to secure when you can back up the value proposition with actual data. In this way, we can demonstrate the monetary impact a data science initiative would bring to the business. We’ll use our in-house search algorithm as an example. As with most e-commerce, search is a key functionality that drives conversion. When PDL decided to take its search capability to the next level, we looked to data science to enhance both the conversion outcome and customer experience.
We started exploring Search enhancements through an algorithm, proceeding in this order:
- First, we ground our team with data and defined KPIs: “Add to cart” from search, overall “add to cart” rate, “add to cart” rate per terms, revenue from search and proportion of revenue sitewide.
- Second, we aligned main KPIs with the stakeholders, refined the list and harvested all data points year to date.
- Third, we identified the top five areas of search that could benefit from the algorithm.
- Fourth, we presented the use case and shared our hypothesis for each enhancement.
- Fifth, we developed the first use case and deployed it through A/B testing to measure gain-loss on the KPI.
- Six, following a positive result, we deployed the solution sitewide.
