Photo by Luke Chesser on Unsplash, style via Fotoram.io

Analytics and data science are better together

Level up your combined value by focusing on how to smoothly handoff ideas between the two functions

If you’re an analyst or data scientist in an organization blessed to have defined roles for both, “Who does what?” confusion can, at best, stop your organization from maximizing innovation and value. At worst, it can create negatively competitive dynamics, where teams fight over who gets to work on any given project.

Here, we’ll cover practical strategies for making sure that dedicated analytics and data science teams can be mutually reinforcing, and help each other maximize their value throughput. Throughout, I’ll use analytics as having a primary focus on making the organization smarter, and data science to refer to roles with a focus on model building. There’s overlap, naturally. We’ll cover that.

Readers of either role will come away with practical interpersonal strategies to drive more value, with low incremental effort. If you’ve found other techniques to be helpful in improving your collaborations, drop me a line—I’d love to hear about them.

Adopt a Mutual Learning mindset

Roger Schwarz’s Mutual Learning approach offers a mindset and set of behaviors that help teams get unstuck and make better decisions. I first learned of them from his book Smart Leaders, Smarter Teams, which remains my all-time favorite book on leading teams. He also covers them in The Skilled Facilitator, with more focus on facilitation and consulting roles, and offers a free, condensed version in his article “Eight Behaviors for Smarter Teams.”

Huge recommendation to read at least that last article, which gives a succinct, comprehensive rundown of the framework. Core to the framework are its values, assumptions and behaviors. Here’s Schwarz in that article, describing the mindset’s core values (in bold, author’s emphasis):

When you’re transparent, you share all relevant information, including your thoughts, feelings, and strategies. When you’re curious, you are genuinely interested in others’ views and seek them out so that you and others can learn. When you value informed choice, you act in ways that maximize your own and others’ abilities to make decisions based on relevant information. When you’re accountable, you take responsibility for your actions and their short- and long-term consequences. You expect to be asked to explain your beliefs, actions, and decisions to your team and others. When you’re compassionate, you understand others’ concerns and connect and respond to others. You suspend judgment temporarily so that you can appreciate other people’s situations. When you act with compassion, you infuse the other core values with your intent to understand, empathize with, and help others.

If you’re finding yourselves struggling to figure out which team should do what, or finding that your stakeholders are confused and frustrated they can’t get value from your team, living these values can help. As can the eight behaviors, which I’ll mention where related throughout.

Accept the challenge of helping your non-technical partners get the right support

Dirty secret: Not all of your stakeholders will ever fully appreciate the difference between your analytics and data science teams. As goes the first Mutual Learning assumption, “I have some information; so do other people.” The practical distinctions between data analysis and data science is information we have that others do not. That’s okay.

Much like how I will likely never understand why I might need to see an endocrinologist, I don’t need to: That is my doctor’s job. Yet, despite my ignorance, I can still serendipitously wind up in the right place, as I did when I went straight to an ENT and said, “Doc, the other day I had a sinus headache I could feel in my eyes. What gives?”

Had I been wrong, he surely would have sent me to a better choice of specialist. Had I gone to an allergist, she’d likely have treated me within the bounds of her discipline and referred to an ENT. That’s what’s important, that every function help the other make connections to the people who can help them deliver value.

“But I build models,” my disgruntled data science friends will say. “I don’t spend weekends reading about the latest in deep learning so I can dodge requests to build dashboards.”

“Everyone keeps asking me about AI,” our analyst friends chime in, “when what we need is good business intel and decision support, not a buzzword salad.”

I get it. They’re very different jobs, each with their own unique value prop, skills and challenges. Meanwhile, recruiters in a hot market make all of us feel like unicorns and pegasi. But our non-technical friends sit from a pretty far remove, so much so that if we were to ask them what either of us are, you can’t really blame them for squinting a little bit and answering, “…basically a horse?” For a quick exercise in empathy, let’s all imagine how muddy an answer we data pros would give if asked, “Can you help me draw clear lines between finance and accounting, or marketing and sales?”

So every time somebody “asks the wrong person,” we have the choice whether to react with disgruntled indignance, or to be helpful and say, “That’s not the kind of thing my team does, but I think I might know who can help.“ It’s an easy, free way to add value, and become better liked. Which will generally come in handy down the road. Make this sort of response a habit. It demonstrates the values of transparency and compassion.

Aggressively fight the fiefdom impulse

“No, that’s our thing” is the sign of a toxic, unproductively competitive environment. By unproductively competitive, I mean that teams employed by the same organization—and thus, one would hope, having shared objectives—view each other as competitors instead of their shared, external competitors.

There are productive forms of internal competition, for example, “who can clear the most bug tickets” hackathons, outstanding customer service awards, and things of the like. These forms of competition focus teams on behaviors that support shared interests. There’s a key common trait shared by the most and the second most valuable player on the winning team: They both won.

Infighting among teams for resources, stakeholders, or the opportunity to support any given project, is not productive competition. It’s an aggressively stupid waste of time, and a sure fire way of delivering less with the resources you have than you could if you stop aiming at each other and start aiming at a shared target. As goes the fifth Mutual Learning effective behavior, “Focus on interests, not positions.”

As a means of getting on the same page, spend some time thinking about each team’s unique value prop. Both functions exist for a reason, and if you can articulate that purpose to each other and recognize shared different value, you’ll be miles closer to explaining it to stakeholders. Then, draw out where you see shared capabilities and contributions, and commit never to draw artificial lines that cordon off specific individual contributors from work they’re capable of doing.

For example, say we have an analyst who has built a sales dashboard. She also has a masters degree in statistics and experience in forecasting, and notices both linear growth and seasonal patterns. She pitches a small project to extend the sales dashboard to include forecasted values based on a model.

If the response she gets from her supervisor is, “We leave the modeling to data scientists,” that’s a sign of fiefdoms that stifle data entrepreneurialism and ultimately impede progress. Likewise if data scientists in the office pushback at the idea. Her job is to make the organization smarter. In deciding whether she should do this work, there are a few reasonable tests we might apply:

  • Is she able to do the work? (Yes.)
  • Does it support the analytics mission to make the broader organization smarter? (Yes.)
  • Among the projects she could be doing, is this the one with highest ROI? (Depends.)

Notably absent is “what’s her title?” Live that value of informed choice, and maximize each other’s choice of where and how to add value.

Couple, but loosely

Here’s a fun metaphor from systems engineering. If you Google “loose coupling,“ this definition will be among the first results: “Loose coupling is an approach to interconnecting the components in a system or network so that those components, also called elements, depend on each other to the least extent practicable.”

Of course, the detail devil is waiting to hear our definition of “least extent practical.“ Here it is: analytics and data science teams should each be able to function interdependently; neither should need the other to drive value; through nimble kind spirited communication with the other, each should be able to add more value.

In practice, that means that a data science team who is familiar with the body of work produced by an analytics team will be better able to identify modeling opportunities, and better able to accelerate their own modeling efforts. Most of us as modelers begin a project by coming up to speed on the data we have on hand, running some exploratory data analysis, building plots, etc. If you have friends in the analytics shop that have worked on similar problems and data sets, why waste time repeating any of that work? Why not arm yourself with their hard earned understanding of the gotchas present in the data set? (If you are a data scientist who works somewhere that has the luxury of data so magnificent, so pristine and comprehensively documented that there aren’t any gotchas to trip people up, please be in touch. My résumé is linked above.)

Likewise, an analytics shop is better able to make its organization smarter if it has ready access to anything modelers learn while they’re trying to build AI. “Hey, our first model used an interaction effect between income and gender and found a substantial affect, might your stakeholders for the marketing dashboard appreciating this broken down?“

Returning to our sales dashboard example, that analyst should be able to very quickly ask DS counterparts whether anyone has ever modeled forecasted sales. If a model exists, the updated dashboard reaches its internal market much faster. All thanks to our curiosity of each other’s work, and our transparency in sharing it.

Hand off questions and hypotheses

There’s a straightforward fact any of us trained in science know, but easily forget in practice: Anything we learn implies another, future investigation. It’s among the reasons we have a future work section in scientific papers, and the reason the scientific method is so frequently depicted as cyclic.

One simple way to magnify value of data deliverables without magnifying level of effort, is for analytics and data science teams to be cognizant that future work can be implied for either team from the work of the other.

Returning again to our sales forecast example, let’s imagine that our analyst learned that her data science team did in fact have a forecasting model. Then, because it was the lowest LOE and highest ROI path, the teams decided to serve that model’s predictions in the dashboard. That same analyst is then asked to examine seasonal patterns in demand for different products, to help sales and operations get a handle on what is bought when.

Following that analysis, she shares her findings that some products exhibit very spiky demand patterns. “Hey Alex,” she says, “We just found that there are a lot of items and categories that exhibit specific patterns around certain days of the year. One hypothesis is that accounting for item- or category-level seasonality could improve accuracy of our forecasts.” If that input is valued and accepted as moving both teams forward, she’s working in a good place.

Getting started

Team dynamics are complicated and take constant tending. Here’s a few quick, actionable ways to start:

  1. Develop simple, nimble intake processes. Make it easy for non-technical stakeholders to ask either team for help with problems. “Process” can conjure images of elaborate forms, but you can start as easily as, “kick off a conversation in this channel, we’ll scope your request together and figure out how we can help.” Your stakeholders have information you don’t, make it easy for them to share.
  2. Make referrals between the teams common, natural and easy. “That sounds like something Sam’s team could help you with. Sam, do you agree?” Live the mutual learning values, and be transparent with your counterparts and support them making informed choice.
  3. Be transparent with each other about what is asked of you, what you’re committed to and what other opportunities you see that you cannot action quite yet. If there are items they could work on, avoid the urge to pushback. More transparency and informed choice.
  4. Celebrate each other’s contributions, regardless of whether its form falls in the overlap between the two functions. If you hear yourself or others saying, “We should have done that first,” that’s not a good sign. Remember the Mutual Learning value of accountability, namely that you chose to work on other projects, and the core assumption that we can all contribute to the problem.
  5. Read Schwarz, really. The eight behaviors will give you easy, actionable ways to level up your collaborations and relationships with partners of all stripes.

I hope these techniques help you collaborate across functions, and I invite you to get in touch and tell me either way.

Sean M. Easter
Data Science Leader

Posts may contain affiliate links, read more here