career path

How to Make Bridges between Data and Business Functions

Communication issues between Data Scientists and Business Managers are a growing pain in companies new to the data world. It is easy to throw the blame on the other side but, often, the reality is more complex and both sides have some improvements areas. Let’s learn how, as a Data Scientist, you can become a bridge maker.

And there is a simple question you can ask a Data Scientist to gauge his or her current business acumen:

What are you working on those days?”.

Hand moving a pawn on a conceptual maze. Shortcut to success or career guidance.

It’s not all about the tech

Some data scientists, in particular at a junior level (but not only!), will answer you:

I am training a logistic regression model on our customer data. The accuracy is actually better than with Random Forest but I have to do some proper cross-validation right now”.

This is fine if you are talking to another data scientist but, if you are talking to business partners, they will legitimately be confused.

Many Data Scientists see their main task as coding, creating models and sharing the results and, to some extent, this is true. But, on a different scale, their job is to provide a solution to a problem your company — represented by business managers — has to solve. And often, data scientists lose this perspective and forget which problem they want to solve.

It is hard to blame them. Zooming out from a deep technical perspective (e.g. dealing with advanced statistics and programming concepts at the same time) to a higher level business perspective (e.g. what is the current business strategy) is hard. Making the bridge between the two worlds is the best way to ensure your company’s data effort is not doomed.

But here is the good news: there are easy ways to improve on this.

Become a Bridge Maker

Coming back at our initial question, a business manager would likely have preferred an answer on the lines of:

I am working on our project to predict the probability of a customer to make repeat purchases so that we can target them with tailored email campaigns. I have developed a method that gives a good accuracy and am working on validating it before it can be considered for production”.

You can understand your business manager will likely find this more informative: they understand every word, have the context and the goal of your project as well as a progression status.

Here is a method on how to boost your business acumen and make sure your communication with the business side of the project is fruitful and not the reason the project could eventually fail.

Write some specs. And read them.

Data Science projects can not always be managed as software development projects but that should not prevent you from writing some specs, involving both the business and tech teams.

In addition to the purely technical aspects we won’t cover here, good specs should highlight:

  • Which problem are we trying to solve? (e.g. we want to drive more repeat purchases on our website).
  • What is the final deliverable? (e.g. We will generate a list of users we identify as potential repeat purchasers so that we can target them with a specific email campaign).
  • What does success look like? (e.g. At least 5% of the targeted users engage in a new purchase within the next month).

All these points should be mostly written by business managers although data scientists should also be involved to discuss feasibility (e.g. do we have the right data?) and manage expectations (e.g. “No, we can not have a 100% accurate model”).

Once written, do not forget the most important step: read them. I am not saying read them once and start coding. Read them regularly. Every time you have a meeting about the progress of the project, use this document as a reference to see if you are on track, even in absence of any business manager. If it needs to be updated, do it and keep using the new version.

Using such an approach makes it less likely to not match the business expectations as both sides of the table committed to a same plan.

Have a Process

Now that you have a clear goal defined with your main stakeholders, set a process in place to reach the final objective.

The process should cover:

  • What are the major milestones of the project? (e.g. data exploration, try two potential approaches, optimize the best of those approaches, generate the recommendation).
  • When is a milestone reached? (e.g. allow a time box or when a specific objective such as a given model accuracy is reached)
  • When do you update your stakeholders? (e.g. when each milestone is reached or weekly)

With Data Science projects you never really know which path you will ultimately take to the final goal as this depends on what you find on your way. The role of such a process is to make sure you don’t get lost or side tracked and you reach your final objective efficiently.

Keep Regular Contact

The process outlined above includes some regular catch ups with your stakeholder and you should ensure they are as frequent as needed. This should happen under different forms.

  • Weekly updates. Book a time slot to discuss the project, even if you don’t know what you will talk about. If nobody really has anything to discuss you can still cancel it.
  • Milestone updates. If a major milestone has been reached, send an update, e.g. as an email or Slack message. Detail what you’ve done so far and how it gets you closer to the objective.
  • Choices to be made. Your specs will never cover all the small details. If you face a situation where an important choice has to be made, inform your stakeholders.
  • If you made the call (e.g. we won’t process customers who joined before 2015 because of a data quality issue), send an update explaining what is the issue and why you took this decision and document it somewhere.
  • If you are unsure about the decision to be taken, contact your stakeholders, explain the issue, what are some potential solutions and what you believe is the best one.

Doing so, you decrease a lot the probability that the data science work will not meet the business expectations.

Don’t go too technical

When communicating with your stakeholders, keep one single thing in mind: they do not care about the technicalities. Rather than knowing which algorithm you chose, they want to know how close you are from delivering.

Your communication should therefore not focus on the tech but on the following two elements: Progress and Trust.

Progress: you have to convey that you are closer from the deliverable than you were last time you talked. This is where the process is necessary. If you first defined what is the road to delivery, you have a common reference to use. For example, if you initially said the model building phase will take two weeks, there will be no bad surprises if there is no final model after a week only. You can also use it as a visual reference (e.g. last week we were at step 2, now at step 3 and we should get to the final step next week), which people tend to remember better.

Trust: people will trust you can do a good job if you show them you are in control. Be honest about the hurdles you might have found and show them how you overtook them to build yourself some credibility. They will also not care how you fine tuned your model performance, they will focus on whether the approach ultimately worked.
On a similar note, you will trust people to do their job once to deliver your final email list, you don’t need to know how they will design their email campaign, it’s their job.
The same applies to you. It’s your job to deliver something that works in due time. If you can do that and show you are in control of your project, people will trust you do your job well and won’t question you on how you did it.

Go beyond enemy lines

I am not saying that business managers are the enemy but, to some people, their territory is definitely an uncharted area.

The key to a good communication is empathy, and this does not apply to this unique Data Science <> Business relationship. To know how to communicate efficiently with someone, you have to understand what is their world like, what are their main preoccupations and which kind of vocabulary they use. And you won’t learn that talking to data scientists only.

That’s why it is important to get out of your comfort zone and go attend some business meetings. Ask your stakeholders if you can attend one of their meetings so that you can better understand what is their job about and their objectives. If it can help, offer to give a hand with small details like writing a minute of the meeting.

Once there, observe and learn as much as possible and focus on:

  • What are their main objectives? (e.g. are there currently focusing on getting new users or capitalizing on their current audience). This will help you make sure you are focusing on problems they actually have, not problems they don’t care about at the moment.
  • How do they communicate? Do they focus on the final product? On milestones? On the next step only?

Once you identify how their work and thoughts are structured, use the same structure to communicate with them to make sure your message is perceived more efficiently.


There are simple steps you can take to make sure the business and tech parts of your project are better connected and, as you have seen, it has little to do with technology.

It will take time to develop those interpersonal and management skills but you can already start tomorrow. To begin your journey towards becoming a Bridge Maker, next time your business manager asks you how is your work doing, make sure you talk about your progress towards the objective, and not the technology.

Originally published on Towards Data Science. Published with author’s authorization.


  • […] Start-ups, in particular in the early stages, have very low headcounts. You will likely be the only data scientist and might report to someone who is not an expert. It can be to the CTO who will at least have a vague idea of how things should work and help you with technical stuff or the CMO who will be most interested in results and not on how to set up a full data collection pipeline. In such a case, they and you both will be interested in How to Make Bridges between Data and Business Functions. […]

  • […] Start-ups, in particular in the early stages, have very low headcounts. You will likely be the only data scientist and might report to someone who is not an expert. It can be to the CTO who will at least have a vague idea of how things should work and help you with technical stuff or the CMO who will be most interested in results and not on how to set up a full data collection pipeline. In such a case, they and you both will be interested in How to Make Bridges between Data and Business Functions. […]

Comments are closed.