Making your first analytics hire? Don’t make him a Data Scientist

There is often a disconnect when an organization is just getting started with analytics. One of the key factors is what you hire and how you hire when it comes to analytics talent. I’ve had several discussions on the subject over the past few days.

First-time hires in analytics (statistics, data science, etc.) are essential because they can succeed or fail. A bad hire can throw you off course and even kill the analysis for you.

I got first-hand insight into what it entails to be an analyst’s first hire. Even though a long time ago, I was the only statistician in an organization. I’ve run analytics consulting firms whose clients included those who hired us for their first analytics initiative. I have advised organizations wishing to embark on analysis. And I’ve worked with organizations that needed course corrections because they got the analysts wrong when they first hired them.

In short: your first employee in analytics doesn’t have to be a data scientist or statistician. It certainly shouldn’t be a data science developer or a machine learning engineer. Rather, it should be someone from the business/research side with enough technical knowledge to understand how analytics works. In addition, this person must understand how to work with technical types.

There are a few exceptions, including some (but not all) tech startups and consulting firms whose business solves someone else’s business/research problems. But these are special circumstances; the vast majority of organizations that engage in analytics are not.

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

Among other things, here are three main reasons why this is decisive.

  • The organizational infrastructure to leverage analytics is one thing. Your first analyst hire should be the most important piece of this organizational infrastructure, the bridge to technical capability. Without this bridge, there is no effective use of these technical capabilities. Start with technical hires, and you have a lot of technical ability across the river that you can’t reach.
  • The biggest initial opportunities in analytics are usually complex problems for which simpler solutions are more effective anyway. These are the handy analytical fruits that need to be super connected to the business/research domain. It is remarkably easy to confuse the complexity of a problem with the complexity of the solution. Technicians will always interpret the problem from the point of view of the solution because that is what they naturally do. “This solution is too simple for me,” never said any business person/researcher who really understands analytics.
  • Having a business/research person who understands all of this makes the overall resourcing of the analysis more effective, especially in the early stages. Who doesn’t want ROI from analytics? Additionally, early analyst hires should focus on activities that are functionally difficult to outsource. Analytics development is incredibly easy to outsource if you know what you’re doing. Development is also where you can most effectively leverage the flexible capability in analytics.

No amount of technical prowess will meet these initial needs.

But analysts are problem solvers!

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

We often forget, fail or even refuse to admit that the primary competence of data scientists and statisticians is to solve

problems with the data. Not define them, although we want to believe the opposite! Some data scientists and statisticians can help articulate the problem, but that’s different from define this.

One of the prevalent issues in analytics today is that technicians are hired before the problem is defined. As a result, they need to express in their own words what they think is the problem. Not what the problem actually is.

You need a problem definer, not a problem solver, someone closer to the business/research domain than the technical domain. In fact, you are much better off with a business/research person with enough technical knowledge who knows how to work with technical people than a technical person with business/research knowledge. You can always outsource development, although that’s a whole discussion on its own.

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

Technicians will always approach the problem from the technical side. It is natural and expected, it is their strength. While experience can help to understand the problem area, in my experience it has much more to do with how the person naturally thinks. This is the epitome of “nature versus nurture”. For many, even years of experience cannot naturally overcome their way of thinking.

Although there are other well-known assessments such as Myers-Briggs and DISC, my clients often hear me refer to HBDI (Herrmann Brain Dominance Instrument). I refer specifically to HBDI for its focus on his style of thinking rather than his personality.

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

As a concrete example, my HBDI profile is a 50-50 mix of global thinking and analytical thinking. I am a schematic thinker who thinks analytically. Members of my teams will attest to 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 on the market for this. Luckily, I’m exactly where I should be: tackling organizational and other general information challenges, which are always more important 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 refer to it primarily because I have my own evaluation results that serve as a practical case study. The thing is, identifying the right person for your first analyst hire is about more than evaluating technical skills and experience.

Where to find these people?

Good question.

Like I said, experience can help. That said, if natural technical thinkers force themselves to do this, they’ll end up doing something they don’t naturally do. If you do this all the time, it’s very exhausting; it’s no fun when the novelty wears off. Some may have a cap on what you can upgrade. More importantly, many do not want to do this to the extent required to be successful. A big part of analytics success is allocating resources to roles that allow them to thrive. Put a natural developer, which wanna

to be a developer, in a heavy bridge-building role, is asking for failure. Or the developer leaves for greener pastures. Unfortunately, this is too often what happens.

It is also worth saying that this is truly a rare breed. Having recruited and hired for my own teams as well as others, I say that 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 had to put a number on it at the risk of controversy, I would easily say more than 95% fall into this category.

And they want to be developers, even if they say otherwise. I haven’t met many who truly understand what building bridges entails and are willing to embrace it. Most bridge building ideas by technical thinkers are still technical interpretations, just slightly reimagined towards commercial/research interest.

Finally, some develop this bridge-building skill faster than others, even among this rare breed. But I’ve done, or helped others do, several hires for thinking style at the expense of experience. Rarely did it not work.

One thing is certain: these are not the cheapest resources. But the right rental pays off. Go for the cheapest technical resource for your first analytics hire, and you’re doomed.

What am I looking for when I first hire?

Despite the focus on business/research, I don’t mean that the only solution is to convert seasoned business/research experts into analytics practitioners. Nor am I advocating that this role be in the business/research realm rather than the information realm. What I mean is that I am looking for the following beyond sufficient technical understanding: (1) strong business/research acumen, with or without experience, (2) the ability and will of really representing business/research interests, and (3) the ability to connect with business/research and technical experts.

So what is sufficient technical understanding? Ideally, it is the equivalent of a graduate course in applied statistics, say the first year probability and applied statistics sequence. This may sound over the top, but I will stand in the paint that it is not. I also purposely say statistics rather than data science, and it has nothing to do with the fact that I have a degree in statistics. For starters, there were no “data science” programs back when I was in school! [ Insert your favorite “yo
mama so old” joke here. ]

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

In today’s world, lack of data is not the problem. The
is The data. Or will be. The technical guys can tell you don’t have the right data based on their very technical understanding of the business/research problem. But someone has to figure out if you don’t have the right data for the problem or if you don’t have the right problem for the data. And that someone will not be a pure technical thinker.

Sean N. Ayres