There’s a reason many of the most widely viewed sitcoms rely on miscommunications and misunderstandings. These concepts hit close to home — they’re funny, but most of all, they’re universal experiences.
Whether it’s the generational or cultural misunderstandings that drive plots in Modern Family, the technical misinterpretations that drew record numbers of viewers to The Big Bang Theory or the mundane mishaps that The Office exploits to humorous effect, the misaligned interactions of everyday life are so funny because they are relatable.
In data science, a highly technical field where the terminology used in everyday work can be easily lost in translation to outsiders, communication is the lifeblood that ensures hard work can have wider ramifications.
But that’s easier said than done, and lapses in communication that prove funny in fictitious environments are frustrating in reality.
By leveraging visualization tools, translating concepts into digestible analogies and comprehensively sharing niche knowledge, data scientists can ensure they see the impact of their contributions.
Data scientists at Ahold Delhaize USA and Arity shared how they enable frequent touch points with stakeholders, simplify the complexities of their work for wider audiences and secure buy-ins.
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 nontechnical ones — benefit your team?
When we first stood up our data science department, communication with cross-functional stakeholders was rare. 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 directly opened the communication channel from every cross-functional stakeholder 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, 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 nontechnical 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 nontechnical 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.
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.
Share an example of when you needed to get buy-in for a data science initiative from a nontechnical 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 Ahold Delhaize USA 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:
- 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.
- We aligned main KPIs with the stakeholders, refined the list and harvested all data points year to date.
- We identified the top five areas of search that could benefit from the algorithm.
- We presented the use case and shared our hypothesis for each enhancement.We developed the first use case and deployed it through A/B testing to measure gain-loss on the KPI.
- Following a positive result, we deployed the solution sitewide.
Arity is on a mission to improve transportation by collecting and analyzing data and leveraging predictive analytics.
How does frequent communication with cross-functional stakeholders — especially nontechnical ones — benefit your team?
Data science is often depicted as the center intersection of a Venn diagram between applied statistics, computer science and domain expertise. Data science tends to attract math-minded individuals with a propensity for problem-solving and automation. In fact, with more schools offering data science and analytics programs, it’s becoming easier and easier for future data scientists to acquire skills in both the statistics and computer science realms. However, the old saying “there is no substitute for experience” is a cliché for a reason: domain expertise is harder to come by without working in a specific field or customer vertical.
A saying one of my former managers used to repeat often springs to mind: “We’re not here to solve math problems. We’re here to solve business problems using math.” Analysis without a business goal in mind just satisfies intellectual curiosity. To fully harness the powers of a data science team, each team member must understand why they’re working on their projects and how their work impacts the business. One of the best ways to accomplish this is for the team to regularly work with experts in other functional areas of the company, especially product and engineering but also marketing, sales, operational excellence and customer success. By understanding the business problems those areas are trying to address, our data scientists are better equipped to deliver models and analyses that help accomplish those goals.
Even if the prospect of expanding one’s domain expertise and becoming a better business partner isn’t a strong enough reason to regularly meet with cross-functional stakeholders, there is a much more self-interested reason for data scientists to want to meet with their business partners. By meeting with stakeholders and understanding what business problems they hope to address, data scientists can establish better project requirements and propose alternative — and often simpler — approaches to addressing those problems.
By meeting with stakeholders and understanding what problems they hope to address, data scientists can establish better project requirements and propose alternative approaches.”
Stakeholders sometimes have difficulty articulating what they are hoping for from data scientists. So, rather than having to interpret suboptimal requirements and trying to build solutions that may or may not get at what the business partner wants, data scientists can avoid frustration on both sides by taking the time upfront to understand the problems they are being asked to solve.
An effective way to accomplish this is by getting this information as a project starts. An even more effective way of accomplishing this is by continually meeting with and learning from your business partners so that the data science team understands the business goals and can even anticipate future goals.
Data science is highly technical. When it comes to updating nontechnical stakeholders on your team’s latest efforts, how do you translate the complexities of your work into digestible language?
A crucial idea to understand is that you don’t need to translate every complexity of the work for your nontechnical stakeholders. Unlike in math class, you don’t need to show every step of your work to your stakeholders. This may feel unnatural or like you’re trying to hide something from your audience, but full transparency often loses sight of the big picture that your stakeholders care about.
The business problems we’re asked to address daily are often not addressed by the mathematically “best” model for reasons ranging from operational and practical to legal and ethical and any other considerations in between. So, while you may be focused on how you optimized your convolutional neural network by tuning hyperparameters, your audience may be more focused on whether your model is accurate enough for the use case and whether it can be scaled. Focus your explanation on what your audience cares about the most. If your audience asks deep, technical questions about your model, you should share that information with them. The key point is that they probably won’t ask, so you should cater your communication to their primary focus areas.
The above was more focused on what information to convey. The following are some ideas around how to convey information that I’ve found helpful:
- Avoid jargon — words like ‘precision’ or ‘recall,’ ‘supervised’ or ‘unsupervised’ and ‘dimensionality.’ Instead, pretend like you’re talking to a family member who doesn’t understand exactly what your job is.
- Admit what you don’t know. Nontechnical audiences may be intimidated by what data scientists do and chalk it up to the data scientists being much smarter than they are. Put this concern to bed by admitting what you don’t know. It humanizes you and makes your audience more willing to ask questions to understand what they want to know.
- Where possible, incorporate a narrative along with pictures and diagrams into your discussion.
- Make sure to explain the context of your work, which numbers or charts are important and, most importantly, what the results mean to your audience.
Share an example of when you needed to get buy-in for a data science initiative from a nontechnical stakeholder. How did you secure that buy-in, and what learning did you take away from it?
I wanted to convince my product counterpart of the importance of revamping our modeling pipeline so that we could more easily introduce updated data and new features into the process. Completing this work would be an upfront capital investment of time and resources, but once operational, it would reduce our model development timelines considerably. When pitching the idea, I focused on the outcomes that my product manager cared about: faster model development and quickly testing more models would improve the product’s accuracy.
To drive home the point, I compared the current and proposed process to something everyone has a frame of reference for: checking out at the grocery store. Under the current approach, we arrive at the register and hand each item individually to the cashier. If we realized that we forgot an item, we’d go back out into the store, find the item, and resume handing the items to the cashier, slowing down the entire process. Under the proposed approach, we could put the items on the conveyor belt and allow the cashier to scan them as they arrive. If we forgot an item, we could go out to the store without interrupting the cashier from scanning the current items. My product manager didn’t understand every detail of the proposed process but had a good enough idea to give us the green light to make those improvements.
In terms of key takeaways, I think it’s crucial to understand what is important to your stakeholder and frame how your work supports their goals. Additionally, using analogies to reframe technical ideas in concepts people can understand can be extremely helpful when asking nontechnical folks to support analytic initiatives.
