Making Your First Analytics Hire? Don’t Make It a Data Scientist

There is a disconnect that often exists when an organization is just getting started with analytics. One of the key factors is what and how you hire when it comes to analytics talent. I have had multiple discussions on the topic in recent days.

The first few hires in analytics—statistics, data science, etc.—are critical, because they can make it or break it. A wrong hire can set you so far off course and even kill analytics for you.

I have had a first-hand look into what it entails to be the first analytics hire. Albeit a long time ago, I was the one statistician in an organization. I’ve run analytics consulting practices whose clients included those who hired us for their first analytics initiative. I’ve advised organizations wanting to get started in analytics. And I’ve worked with organizations who needed course corrections because they erred on the first analytics hire.

In short: your first hire in analytics should not be a data scientist or a statistician. It definitely should not be a data science developer or a machine learning engineer. Rather, it needs to be someone on the side of the business/research domain with enough technical background to understand how analytics works. Furthermore, that someone needs to understand how to work with the technical types.

There are some exceptions, notably some (but not all) tech startups and consulting firms whose business is solving someone else’s business/research problems. But these are special circumstances; the vast majority of the organizations getting started in analytics are not these.

Why can’t I just hire a data scientist or statistician?

Among others, here are three main reasons why this is make-or-break.

• Organizational infrastructure for leveraging analytics is a thing. Your first analytics hire has to be the most important piece of that organizational infrastructure—the bridge to technical capabilities. Without that bridge, there is no effective leveraging of those technical capabilities. Start with technical hires, and you have a lot of technical capabilities on the other side of the river you can’t reach.

• The biggest initial opportunities in analytics are usually complex problems for which simpler solutions are more effective, anyway. They are the analytical low-hanging fruits that need to be super connected with the business/research domain. It is remarkably easy to confuse the complexity of a problem with the complexity of the solution. Technical people are always going to interpret the problem from the solution perspective because that’s just what they do naturally. “This solution is too simple for me,” said no business/research person who really understands analytics, ever.

• Having a person from the business/research domain perspective who understands all this makes the overall analytics resourcing more effective, especially in the beginning stages. Who doesn’t want ROI from analytics? In addition, the first analytics hires need to focus on activities that are functionally difficult to outsource. Analytics development is unbelievably simple to outsource if you know what you’re doing. Development is also where you can leverage flex capacity most effectively in analytics.

No amount of technical prowess is going to address these initial needs.

But analytics people are problem solvers!

Many organizations make the mistake of bringing on analytics resources that are too technical for the situation. They are expected to solve important business/research problems because they are problem solvers. Unfortunately, statisticians and data scientists often exacerbate this themselves. They believe they are problem solvers, and they are right! But therein lies a key problem.

We often forget, fail, or even refuse to admit, that the primary competency of data scientists and statisticians is to solve problems with data. Not define them, as much as we’d like to believe to the contrary! Some data scientists and statisticians can help articulate the problem, but that is different from defining it.

One of the prevailing problems in analytics today is that technical folks are hired before the problem is defined. As a result, they are left to articulate in their own terms what they believe the problem is. Not what the problem actually is.

You need a problem definer, not a problem solver, someone closer to the business/research domain than to the technical domain. In fact, you’re much better off with a business/research person with enough technical understanding who knows how to work with technical people than with a technical person with business/research domain knowledge. You can always outsource development, although this is an entire discussion in itself.

But I’m going to hire a really smart data scientist or statistician!

The technical people will always approach the problem from the technical side. This is natural and expected—that’s their strength. While experience can help with understanding the problem domain, in my experience, it has a lot more to do with how the person naturally thinks. It’s the quintessential “nature vs. nurture.” For many, even years of experience cannot overcome how they naturally think.

Although other well-known assessments such as Myers-Briggs and DISC exist, my clients often hear me reference HBDI (Herrmann Brain Dominance Instrument). I reference HBDI specifically for its focus on one’s thinking style rather than on one’s personality.

Personality profiles certainly impact teamwork and collaboration which is critical in today’s world. However, the fit for specific roles has a lot to do with how that person thinks, especially in the information domain. I had intuitively hired that way for years, and it worked. Later I was presented formally with the idea, and it all made sense.

As a real example, my HBDI profile is a 50-50 mix of big-picture thinking and analytical thinking. I am a schematic thinker who thinks analytically. People on my teams will vouch for this (“I need more context”). Although I am capable of technical thinking, I am not your pure data science developer. There are much better resources in the market for that. Fortunately, I’m exactly where I should be—addressing organizational and other big-picture challenges related to the information domain, which are always bigger than data, analytics, and technology. This is where I am most effective.

I’m not trying to sell HBDI; it doesn’t have to be HBDI. I reference it mainly because I have my own assessment results which serve as a convenient case study. The point is, identifying the right person for your first analytics hire is more than evaluating technical competencies and experience.

Where do I find these people?

Good question.

As I said, experience can help. That said, if natural technical thinkers were to force themselves to do this, they end up doing something they do not do naturally. If you do that all the time, it is very exhausting; it is not fun when the novelty wears off. Some may have a ceiling on how much you can improve on it. More importantly, many don’t want to do this to the extent required to be successful. A big part of the success in analytics is putting resources in roles that allow them to thrive. Putting a natural developer, who wants to be a developer, in a heavy bridge-building role is asking for failure. Or the developer leaves for greener pastures. Unfortunately, too often that’s what happens.

It also merits saying this really is a rare breed. Having recruited and hired for my own teams as well as for others, I say the vast majority of those with highly technical skills (with or without experience) are pure technical thinkers who are better suited as developers. If I were to put a figure on it at the risk of controversy, I’d say easily over 95% fall in this category.

And they want to be developers, even if they say otherwise. I have not come across many who truly understand what bridge building entails and are willing to embrace it. Most ideas of bridge building by technical thinkers are still technical renditions, just slightly re-imagined toward the business/research interest.

Finally, some develop this bridge-building skill more quickly than others, even among this rare breed. But I’ve made, or helped others make, multiple hires for the thinking style at the expense of experience. Rarely ever has it not worked.

One thing is for sure: they are not the cheapest resources. But the right hire gets you the return. Go for the cheapest technical resource for your first analytics hire, and you have set yourself up to fail.

What do I look for in my first hire?

Despite the business/research domain emphasis, I don’t mean the only solution is to convert seasoned business/research experts into analytics practitioners. Neither do I advocate that this role report into the business/research area rather than the information area. What I do mean is that I look for the following things beyond sufficient technical understanding: (1) deep business/research acumen, with or without experience, (2) the ability and the willingness to really represent the business/research interests, and (3) the ability to relate to both business/research experts and technical experts.

So, what is sufficient technical understanding? Ideally, it is the equivalent of graduate-level coursework in applied statistics, say the first-year graduate-level probability and applied statistics sequence. This may seem like overkill, but I will stand in the paint that it is not. It is also on purpose I say statistics rather than data science, and it has nothing to do with the fact that my degree is in statistics. As a starter, there were no “data science” programs back when I went to school! [ Insert your favorite “yo mama so old” joke here. ]

But the real reason is that your first analytics hire needs a solid understanding of statistics and, more importantly, probability. Probability is foundational to data analysis design, which is the source for the vast majority of the issues with analytics. Spotting a foundational issue in analysis design also requires a business/research perspective. This is also where analytics outsourcing often fails.

In today’s world, the lack of data is not the issue. There is data. Or will be. The technical types may say you don’t have the right data based on their heavily technically colored understanding of the business/research problem. But someone needs to figure out whether you don’t have the right data for the problem or you don’t have the right problem for the data. And that someone is not going to be a pure technical thinker.