Why You Should Learn Effective Communication in Data Science
Riding the line of the communication gap between technical and non-technical
The most significant gap I have seen in soft skills in Data Science and engineering is communication. Not enough people know how to translate between technical and non-technical audiences. Think about your work. When you are giving a sprint review, showcasing a demo, or just having a conversation with someone, are you able to tailor your speech to the audience watching? Many folks struggle at this skill, and it often causes rifts between teams who do not fully understand one another. Today, I want to share a story on why communication is critical and my lessons when working with my past clients.
Understanding What the Business Needs
One of the first steps to solid communication between the business and the technical is understanding; what does the business need from you? When working with one of my past clients, I spent the first-month diving deep into the project they had started. I wanted to understand what they were doing with their data and why. In essence, they wanted to look over thousands of records for electronic devices and find the failures.
It can be easy to run off and create a data science project that can find failures when looking at that problem statement. For example, you can look for failure codes, check for anomalies, and run the most complex algorithms to spot patterns in the data. But before you run off to do that, are you sure that is the entire problem?
Yes, the client wanted to look over thousands of records for electronic devices and find the failures, but they wanted more than that. They tried to understand why these failures were occurring, could we detect a cause or set of reasons for this failure, was a specific type of failure, and much more. Often, the business problems we face in data science are not as simple as they may sound at first, so it is essential to learn how to communicate and ask the right questions. Why is it important to understand your client’s needs? Because you need to provide them with a solution that will work to fit their needs. Before you dive deep into your solution – start by asking questions.
When I am evaluating business needs and working with my clients or business customers, here are the areas I consider in the beginning:
- Do you correctly understand the business problem and needs?
- What are the use cases you see that can leverage data science?
- Are there other areas that should be involved, such as DevOps, web application development, etc.?
Set up meetings to discuss your initial thoughts on tackling these problems based on your data. What is the feedback you receive from your clients? When you have these meetings, you should also discuss anything you currently do not have data for and discuss what you or your client could do to resolve this.
- Can they provide you with more data?
- Could you alter the problem statement to something that would work with the data you have?
Bring those up if you have any absolute blockers that make it impossible to move forward. This is the time for you to make sure the project starts on the right path, and if that means pointing out significant issues, then point them out. Most people I have worked with would rather have someone point out the big risks and blockers upfront than hide the problems.
Telling the Business What You Can Provide
Once you have a good sense of what the business needs and what is possible with the data that you have, you can start drafting your solution. Whether this is creating a proof of concept, developing some form of a demo, or coming up with a set of diagrams that explains your solution, make sure you are communicating this to your client. Your client or customer wants to know what you can provide them with your solution and the data they have.
My personal preference when developing a solution is to show incremental progress and get feedback at each step of the way. No matter your preferred process, feedback is key. By asking for feedback, you are working with your client to understand if the approach you are taking is working and providing the output they expected. They may have agreed to the approach when you were originally drafting your plan, but implementation can sometimes show unexpected results. Asking for feedback often can help eliminate issues of getting to the end of a project with a solution no one is happy with but you.
If you are like me, asking for feedback can be a nerve-racking experience. Thoughts like, are they going to hate my whole solution? Did I do something wrong and it messed up the whole project? And so on, may pop into your head. But honestly, feedback can be much better and more useful than that. When I am working with a client to solicit feedback, I often focus on their business problems we defined originally.
- Does this solution solve your business problem?
- Are you seeing unexpected results from this solution, and if so, why?
- What can you tell me about what you are seeing?
- Does the data look as you would expect it with the analysis that has been performed? If not, what are you seeing that is different?
Relating these conversations to their work and their understanding of the data, makes for a smoother conversation.
Translating Your Outcomes to be Their Successes
Now that you have understood your business problem and created solutions to solve those problems, how do you translate your outcomes to your businesses success? How do you show the process improvements you have made and the power of the data you are analyzing? Honestly, for me, this skill was a hard one to learn. I could do the technical work, I could interact with the business and understand their needs, but I didn’t know how to showcase this in a positive light that was digestible by the business. An executive doesn’t want to know the nitty gritty details of the technical work you are doing, they want to know the impact to the business.
When it comes to being able to translate technical work to the business, the best advice I have gotten was to grab metrics before, during, and after your improvements. Use these metrics to show why your work is beneficial. Some common metrics I have seen used include: decrease in time to complete a task or set of tasks, decrease in the cost of a particular activity, or decrease in the number of failures of a product. No matter the industry you are working in, find and understand the common metrics of your company. Work with your business partners to understand how they would like to see improvements quantified and then showcase those metrics for your work.
Final Thoughts
So why is technical and non-technical communication key in data science? Because it can make or break a project. No matter your field, communication can be hard. But it can get even harder when trying to translate between technical and non-technical colleagues while working on a data science project. One of the biggest issues I have faced in data science and STEM is this communication gap. Not enough technical people can translate their work to a non-technical audience nor can they translate a business need to a technical capability. Today I shared with you how I approached one of my past clients when it came to understanding their business needs, providing a solution, and translating the outcome. My biggest lessons learned during this experience? If you are like me, asking for feedback can be nerve-racking, but it can be a game-changer for if a project goes well or not.
Why do you believe technical and non-technical communication is key in data science?
Happy Holidays, and thanks for reading! I hope you enjoyed reading about what I have learned. If you would like, you can support my writing by becoming a Medium member using this link.
Share This Article
Towards Data Science is a community publication. Submit your insights to reach our global audience and earn through the TDS Author Payment Program.
Write for TDS
