One of the best aspects of my career has been developing and mentoring some fantastic analysts over the years. I get a huge amount of satisfaction seeing analysts create things that they didn't think possible, and driving results that the organisation didn't think were possible.

So how do I train brilliant data analysts?

Conceptually as a mentor, I place more value on growing strengths than grinding out weaknesses. Playing to an individuals strengths builds confidence. Confidence is infectious. Confidence is also self-realising. When an individual is confident, I find that they stress less and that makes them fail less. There is absolutely merit in grinding out your weaknesses and imperfections, but this is an introspective and slow process that comes with time. The majority of my focus goes into aligning the individual's strengths with organisational success.

---

Core skills

There are some core skills that I need from an analyst. They can excel in some and not others, but I find that they should have skills in these core competencies:

• Mathematical skills - A basic understanding of some core mathematical concepts is important in an analyst, and differentiates a good analyst from a great one. Being able to pull together a whole bunch of pretty graphs is great, but being able to statistically prove correlation is where the rubber hits the road. For many, those math skills are buried in the deep recesses of their brain, but as long as they're in there somewhere - I'll take it.


• Visualisation and communication skills - Being able to articulate your point of view is important. The more compelling that communication is, the more engagement the analyst will have from the broader organisation. Communication comes in many forms, and it's not just verbal or physical. The ability to succinctly communicate a message in written form is also important. I once had a great analyst with a very thick accent: so thick that most people had a lot of difficulty understanding him. However, his strength was in written communication, and I always thought of his written work like an ornate, finely crafted wooden box. His work was clean and refined and it spoke for itself.
  Communication is also critical to understanding the problem. Analysts don't need to be an expert in every aspect of an organisation. They just need to have the ability to draw it out of those around them.


• Business acumen - Individuals that can see the interrelationship of the broader organisation generally make better analysts than strong technical experts. Analysts need to be able to empathise with the business, and understand what matters to them. They also need to be able to understand what good performance looks like, in order to spot deviations from good business process.


• Data / computer science / coding skills - Of course, understanding how to manipulate data and use software is a key technical part of the job. The faster one can manipulate data, the faster they are at generating insights. I have trained great analysts that started from a basic understanding of excel, so a computer science degree is not a necessity (but it sometimes helps). I find that if someone can grasp basic SQL skills, the rest can be taught, but the more basic computing skills one has, the better.
  I find with data skills that it is important to match the maturity of the organisation. In an organisation just starting out on the reporting and analytics journey, the office spreadsheet expert could be a great data analyst, and an MIT computer science graduate genius might feel themselves isolated and creating solutions that no-one else is able to support them on. Conversely, in a highly mature organisation with terabytes of data, coding skills that efficiently churn through millions of records are absolutely essential.
  When I'm transforming reporting and analytics for an organisation, I am assessing their maturity, and looking at the people, processes and systems that match that maturity.

---

If an individual's strengths fit most of these 4 categories, you have an analyst on your hands.

Once I have my analyst, in order to put them in a role that is suited to their strengths, I classify analysts into 3 broad categories:

• Hunters
• Builders
• Unicorns

---

The Hunter

The role of the Hunter analyst is to go searching for the little nugget of information that you didn't know. The root cause. The most profitable business unit. The best performing team member. They are suited to understanding the business problem, and getting what they need to solve it. It doesn't have to be pretty. It doesn't have to be permanent. It just has to be right.

When I'm training a Hunter, I always find myself saying "Build in sticks, and then build in bricks". The ends justifies the means when it comes to pulling together some analysis.

They should be strong on business acumen and communication: the other two are less important (but not irrelevant).

How do I develop my hunters?

As a mentor, I spend my time guiding Hunters on these three things:

• Is that gold, or have you just got a shiny rock? - As I mentioned before, a Hunter's role is to tell me what I don't know. Representing the same thing cut 15 different ways in Tableau doesn't give me any benefit. The benefit of analytics to an organisation is that it makes for a smarter organisation. If you can't tell me something I don't know, why are you telling me? Hunters need to be trained to focus on what adds value and what will drive performance.
  I also need it to be accurate. In the fast paced search for answers, they still need the ability to assess if something is truely the root cause.


• I care about what you found, not how you found it - As I mentioned before, Hunters seek the answer, but they remember the journey - especially if the journey is confusing and challenging. Hunters have a tendency towards telling you how they found an answer, not what the answer is and what you should do about it. Its obvious right - they went on a long confusing journey, they talked to 4 different departments and wrote a complex Python script to combine these three data sources and spent all night pulling it together in this fancy Power BI dashboard. That journey is front of mind.
  However, insight is the measurement of success for an analyst, not effort. Sometimes, the hunter analyst may need to be prodded into putting in a little more effort to make that insight crystal clear.


• Create the forum to be heard - One of the most disheartening things for a hunter is this common scenario. They find an answer. They see the answer right there in front of them every day. They tell people and no-one will listen. They say "but it's right there in the report - I have sent it to you every week for the last year".
  There is no quicker way to lose the engagement of a hunter than to send them on a hunt for answers and not listen when they get them.
  It's important that we as leaders create the time and space to absorb analysis from our analysts, and have them talk to us about what they are seeing. They benefit from hearing the questions that leaders ask, and leaders get the benefit of the insight that they see from being intimately familiar with our data.
  In designing a reporting and analytics framework, I avoid (like the plague) automated reports that get sent to an inbox, unless I know that there is a meeting of two or more people where the report is used or discussed. Report are for prompting action, not clogging inboxes. As an extension of that, hunter analysts are for prompting action, not generating reports and clogging inboxes.
  Given that, I prompt my hunters to reach out to the users of their analysis and discuss it. Talk! As in really talk - not in an instant message or email - and help the users understand what they are seeing.

---

The Builder

Remember the guy with the accent that I mentioned before - that built the workbooks that were like fine woodwork - he was a builder.

The builder is the one that takes the thing that is built in sticks from the Hunter, and builds it in bricks.

They are stronger technically and mathematically. Their value is in efficiency and reliability. They are the ones that make sure it runs first time, every time. They are the ones that build algorithms to run quicker, with fewer resources.

When I'm mentoring Builders, I think about the following:

• Sometimes you have to outrun the treadmill - As I mentioned, a good builder analyst strives for efficiency. They should be automating those manual processes so that the systems just work. What can happen is builder analysts might become blind to opportunities to streamline and automate, because they have become comfortable with their current workload. They can complete all of their allotted tasks in the allotted time, so I'm doing a good job. What this mindset fails to take into account is that there might be other things that could be done in that time.
  Leader asks "Do you have any free time?"
  They say "No, my tasks take all day - they are very complex and manual."
  As a leader, I look for opportunities to introduce creative destructive processes to nudge builders out of a sense of comfort. Making project backlogs really visible combined with effective daily stand up meetings is a great way to start that conversation.
  "What have you got on today? Again? Really? How long does that take you? What do we have to do to get that task off your plate?"


• Walk the pipes - Builders are usually introverts. They usually keep to themselves. They see the task of dealing with incoming issues as a challenge that they themselves need to solve. Whatever data falls out of the pipeline, they need to be competent enough to handle it. They write complex algorithms to deal with the fact that the data is bad.
  However, they are sometimes blind to opportunities to avoid these challenges altogether by looking upstream and changing the way things are done. By going and talking and collaborating with others for 5 minutes (which might be more uncomfortable to an introvert than staying back for four hours coding), they may avoid complexity and help create a better solution.
  As leaders, it's our job to help coach them into "walking the pipes". We might need to walk with them the first couple of time to see where the data comes from, and teach them how to negotiate and discuss and evaluate the best solution. We need to empower them to evaluate and design the best way to do it for the organisation, not just build the path of least resistance. Asking someone else to do something that you yourself could handle is not easy, and takes softer skills that you may need to coach them on.
• Is anyone actually using it? Builders might be proactive in building reports and data pipelines, but they are usually not as proactive at deconstructing things.
  Reporting and Analytics platforms are constantly evolving things. The information needs of today are not the same as they were three months ago, and will be different again in three months time. It takes time to maintain a solution that is fit for purpose, and I have seen countless solutions that have modules that were built for the business 5 years ago, but are now completely irrelevant.
  It is usually really obvious after a name change or a take over. The old organisational hierarchy sits there gathering dust. When a new starter joins, they have to be told "don't pick that one. That's the old one - the new one is over here."
  We need to coach builders to dedicate time to maintenance tasks like removing/archiving unused content. A solution that is unused might be full automated and require no manual intervention, but leaving it creates clutter. It may be technically amazing - it doesn't matter if no one needs it. When business users go looking for things that are useful, they need to search that little bit harder to find it. When new users start, they need a little more training. We need to give our builders time to cut the clutter in our Reporting and Analytics landscapes.
• Check their execution plans This probably needs its own post, but to help Builders build the most efficient solutions, one sure fire way to do it is to get into the detail of how their queries are evaluated by the system. Specific for SQL, this might mean getting a snapshot of the actual/expected execution plan / visual explain plan.
  These tools help us give specific feedback about what is happening in the background, and help give us insight into how we can make the solution more efficient.
  As Builders tend to be technical subject matter experts, we might grow to trust them to come up with the best solution. However if you can give them more specific feedback to get that efficiency, they will respect you for it. In order to optimise a query, it is much more effective to say "What is that full table scan doing there?" rather than settling for "This query is slow. Can we make it faster?".

---

The Unicorn

Last but not least.

A unicorn is one individual that can do it all.

They can code. They can communicate with impact. They are a math wizard. They understand intimately how business functions should operate and can manage change to implement it.

They are rare. They are usually very expensive and they are usually overloaded with work or in huge demand. If not, they have made the move from analyst to more senior positions, developed their own blockchain algorithm or are developing a cure for cancer while fighting for world peace.

I can't tell you how to develop unicorns, because I've never really found one that I could afford.

If I do find a unicorn, I'll be sure to write about it. For now, I will continue to operate the way that I know works i.e. by matching people with a passion for ananlytics to their individual strengths and growing them into more senior roles from those positions of strength.