Data Science Jargon – Why your client might not be listening


To effectively communicate, we must realize that we are all different in the way we perceive the world and use this understanding as a guide to our communication with others. —Anthony Robbins

Words and Jargon

Have you ever worked your fingers to the bone developing a model or other analytic solution to a problem for your client or department, and then observed that your solution was never used? Is the boss or customer listening to your advice? If the answers are Yes and No, respectively, then there is a problem, but it is a common problem. There a number of root causes for this, but the most common is communication.

As big data analysts, we have our own language. This is sometimes called jargon. We understand it, but other do not. Others may include managers, hiring managers, intelligence analysts, chief technology officer, etc. When we talk they are probably nodding their head and do not have a clue what we are saying.

The two words ‘information’ and ‘communication’ are often used interchangeably, but they signify quite different things.  Information is giving out; communication is getting through. —Sydney J. Harris

Poker Faces

There is a group on YouTube called Studio C (If you have not watched them before, you are missing out on some good comedy). I watched one yesterday called Poke Face, Each player is showing their poker face and we get to hear each one of their thoughts. One guy does not know the game at all—not the rules, the poker chips, etc.—and when it is time to show his hand, he is showing UNO cards. However, he kept his poker face the whole time. This is your client. Just because you are an outstanding analyst, providing excellent analytic solutions, does not guarantee that people will listen to you. You have to speak their language.

Don’t use words too big for the subject. Don’t say infinitely when you mean very; otherwise you’ll have no word left when you want to talk about something really infinite. ― C.S. Lewis

Communication Complexity

There was a certain Christian missionary who was trying to reach a certain native tribe in a remote part of the world with his message. The tribe killed him. Later, the tribe was converted to Christianity, and it was not until then they understood what they had done was wrong. There had been a communication gap of several layers. One was language, one was culture, and another was belief system. The tribal chief is your client. You have to speak his language, understand his culture, and recognize his belief system.

In the land of Gibberish, the man who makes sense, the man who speaks clearly, clearly speaks nonsense. ― Jarod Kintz, This Book Has No Title

Recently, a colleague asked for some advice for an upcoming interview. The telephone interview was with the CTO and this is what was taken away from that interview. In answering what kind of projects would be expected, the CTO said that the following could be expected:

  1. Message testing
  2. Spent-time model of customers that are at risk and at grow
  3. Atomization of models/algorithms/etc.

Here is what I draw out of the CTO’s description:

  1. Message testing probably involve constructing an acquisition model, like a propensity to buy or engage. These models are typically logistic regression models. Once you build a model, say in SAS, you can deploy it and make it operational on a mainframe, for example. The client could run the model on a regular basis. The output would be a score of customers’ propensity to buy or engage. Using the score file, they would market/message the top deciles. This way they are spending marketing dollars on those whom the message would have the most likelihood of a response.
  2. Customers at risk is also a propensity model: the propensity to shed. This is also a logistic regression model and the same principles from above apply, except the scores would be high for people who are at risk.
  3. Automation could take a number forms, but the most common is model deployments as I described about. For example, when I build a model in SAS Enterprise Miner, I take the score code and wrap it in a execution macro and then give that code to a guy who deploys it for production on a mainframe.  The same guy runs the model each month along with about 20 other models during the first week of the month.  The process is automated and the scores are sent to a marketing directory for access. He also runs a model performance report on each model, which is partially automated. An emerging process is real-time modeling. The same models would be used, but they might be written in Python in a Hadoop environment and the data would be refresh a regular short time periods. This could be used to direct traffic to call center. For example, if a caller has a high score for propensity to shed a mortgage, that customer could be directed to the mortgage company and provided some incentive not to shed their mortgage.

The ability to simplify means to eliminate the unnecessary so that the necessary may speak. —Hans Hofmann

The CTO is speaking a different language. To understand the CTO’s language you must first understand his culture, belief system and context. Not knowing these, I am guessing at my interpretation above. However, if you interview for a job you should understand these things first. The same is true for our communication with clients. We must understand their culture, belief system—their corporate belief system, not religious—the relative context, and then their language they understand. If we do not do these things first, our analysis results land on deaf ears and we fail. Our solutions are neither understood nor implemented.


Jeffrey Strickland

Authored by:
Jeffrey Strickland, Ph.D.

Jeffrey Strickland, Ph.D., is the Author of Predictive Analytics Using R and a Senior Analytics Scientist with Clarity Solution Group. He has performed predictive modeling, simulation and analysis for the Department of Defense, NASA, the Missile Defense Agency, and the Financial and Insurance Industries for over 20 years. Jeff is a Certified Modeling and Simulation professional (CMSP) and an Associate Systems Engineering Professional (ASEP). He has published nearly 200 blogs on LinkedIn, is also a frequently invited guest speaker and the author of 20 books including:

  • Operations Research using Open-Source Tools
  • Discrete Event simulation using ExtendSim
  • Crime Analysis and Mapping
  • Missile Flight Simulation
  • Mathematical Modeling of Warfare and Combat Phenomenon
  • Predictive Modeling and Analytics
  • Using Math to Defeat the Enemy
  • Verification and Validation for Modeling and Simulation
  • Simulation Conceptual Modeling
  • System Engineering Process and Practices

Connect with Jeffrey Strickland
Contact Jeffrey Strickland


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s