Are you Treating your Analysts like Task Rabbits?

Throughout my career I’ve seen a number of different analytics teams and as you might expect, there are a handful of similarities and a handful of differences in how each team operates. But one thing that has consistently stuck out is how analysts are frequently hired, viewed, and utilized within an organization. Many times, analysts appear to be utilized as task-rabbits as opposed to integral members of the team.

Okay. I’m guessing that I have quite a few people disagreeing with this statement. And for those of you that disagree, let me ask you a few questions. Does your analyst (frequently) make business decisions? Does your analyst know how to operate your business as well as you do? When you have a request for a “metric”, do you always explain why you need the data and what problem you’re trying to solve? When making a request, do you always ask for more than to “pull a quick number”? If you answered “no” to any of these questions, you’re treating your analyst like a task-rabbit.

Before we go any deeper, I should probably define a task-rabbit. A task-rabbit in this context is a term for someone or something (computer program) that performs a basic task with little input and with little skill. You simply provide the task-rabbit with an instruction such as, “can you tell me how many website visits we had last month”, and the task-rabbit will return you a value such as, “123,584”. Unfortunately, these types of questions or instructions, without any context can result in misleading information.

The Importance of Context

Frequently, these “can you tell me x” questions are the type of questions that analysts hear from stakeholders. And while the people that ask these types of questions are getting answers, chances are they aren’t getting the answer that they truly desired. This is because many times in the analytics domain, the answer is the equivalent of, “it depends”. Allow me to paint a picture of this with my example question from the previous paragraph.

In our question, “Can you tell me how many website visits we had last month?”, the analyst doesn’t have any context as to why you are asking this question. Are you looking to compare this information to website visits from last month? Do you want to estimate conversions based on this value? Are you trying to forecast future traffic for some reason? The reasons behind your question could be limitless, but you as the requestor, almost certainly have a reason (and hopefully it isn’t just because you’re curious).

The problem with not understanding this context is that the analyst is going to present you with potentially misleading information. For example, if you were attempting to forecast demand, you might not want “the last month” of data. What you might want is a daily average because it’s February and there are only 28 days in the month, which is going to impact your average if you’re forecasting for a month with 31 days in it. Or maybe “last month” had an anomaly in the data where there was an outage or special event that was going to inflate or deflate the results. Again, you’re going to get your number, but without proper context, you’re getting data, not information.

What is an Analyst?

Ideally, an analyst should be a trusted business partner and on my teams, I view and train my analysts to be just that. My expectation is that an analyst can perform many of the functions that the business owner can perform, and that the analyst understands his or her business inside and out. So what’s the difference between the analyst and the business owner? It’s subtle.

I view the analyst as a person who has access to additional tools in her toolbox to provide insights and solve problems. And like the business owner, this person could perform many of the duties of the business owner. However, the analyst doesn’t usually have to focus on the people management or the execution aspects of a process or product change that is derived from an analysis.

Understanding and embracing this definition of the role and involvement is critical for high-levels of success on your team. Because without the level of expectation, your analyst isn’t going to fully understand the business problems, opportunities, or how to produce information in proper context to the problems that are being solved. But when when you view an analyst as a partner that can provide insights and solutions, you’re going to get even better results than you’ve ever expected. By treating your analysts as a partner, they will feel ownership of the problem and they will provide you with value added information and solutions. However, the inverse is also true.

Why are Analysts Treated like Task-Rabbits?

There are probably more reasons in the world than I can list, but based on my observations, there are a few key reasons that bubble to the top of the list.

First, many requestors simply don’t realize the importance of context when asking their question. Which is why most analysts receive a question or a task, instead of having someone explain the business problem that needs to be addressed. And if we were performing a root cause analysis, we might come to the second reason, which frequently has to do with time constraints.

Time is valuable and everyone seems to be in a rush to finish a report, send an email, or make a decision based on some piece of information. And due to the hectic pace, the requester may innocently ask for a piece of data because they don’t feel that they have the time to explain the problem in detail to the analyst. But again, this lack of explanation will ultimately lead to misleading information and continue to keep your analyst from truly understanding the business and providing value.

The last reason comes down to power and control. While I haven’t seen this reason crop up too many times in my career, I have seen it from a handful of individuals. These individuals usually kept analysts at-bay due to a fear of being outshined by the analyst, with reasons such as, “If the analyst is good enough to make business decisions, then why am I needed or what will I do?”. I’ll avoid getting into the details of what the requestor could be doing, but suffice to say, safeguarding information isn’t a quality of a strong leader or team member.

How Do We Better Utilize Our Analysts?

Now that we’re aware of some of the reasons for why analysts are frequently treated like task-rabbits, we can focus on practicing good habits that will create a strong partnership and allow you to obtain the most accurate information. These habits include: embracing your analyst as a true partner, asking the right questions, and allowing them to help solve the problem.

To start, we need to embrace the analyst as a key partner, where they are part of the business conversation. Analysts should be provided with an understanding of what problems need to be solved, what constraints they are working within and the overall direction of the business. With this information in hand, the next thing that we can do is to practice asking the right questions.

Instead of asking, “can you tell me how many donuts we sold last month”, try explaining a problem statement such as, “I’m trying to forecast sales [what are you doing] of 1-dozen donut orders [what are you trying to measure], so that I can ensure that we have enough 1-dozen donut boxes in-stock to meet demand [why is this data important]. Can you help me with this forecast?”

By stating the problem instead of making a data request, you’ve provided some important context and you’ve opened the door for additional questions from the analyst. For example, if the analyst is going to provide a full forecast, she might ask about current inventory levels, lead time needed for orders, pricing discounts and more.

This could lead to the analyst returning with an answer stating that you’ll probably have 1,000 boxes sold in the next 30 days, but 5,000 in the next 45 days, and 5,500 in the next 60 days. Also, the analyst might also inform you that while 95 of your 100 stores will probably run out of inventory, 5 of your stores are closing and have more than enough inventory on-hand to meet your needs in the next 30 days, if you can reallocate the inventory to other stores.

But if you simply asked, “how many donuts did we sell last month”, your analyst might tell you that you sold 12,000. With only this number in-hand, you’d have to estimate how many of these 12,000 donuts were part of a box. Or worse, maybe you thought that you asked for how many 1-dozen donuts were sold but in reality you asked for how many total donuts were sold. A small oversight, but something that your analyst may have been able to clarify if she had the proper context.

Over time as you engage more frequently with your analysts, your analyst will gain a greater understanding of your business and context. And with this understanding, they will be able to supply you with more accurate information and provide valuable insights for solving problems as a team.