Advice on Building a Data Analytics Team


If you are tasked with building a data analytics function in your business you will face a few challenges, the chief one initially is around engaging with the new job titles and skills within the data analytics arena. Your next major one in the current market is obtaining skilled permanent individuals due to their high demand, so pragmatic decisions need to be made either with regard to taking contract staff or making the employment package particularly compelling to entice contractors to permanent roles. Nothing new here when specialist skills are in short supply.

Assuming common understanding of the importance of general team building theory, including – personality mix, team dynamics, project management style, business engagement style – these are always key, instead I’ll focus on the specifics of a data analytics team.


The project requirements will drive the staff you need. Critically, don’t jump into a project too quickly. Define the end results you are trying to achieve. There is a danger especially from analytical type personalities, who will want to collect data and start analysing. This should be resisted! The project aim may be necessarily vague, e.g. ‘Find some business insights from our transactional and customer engagement data’ or something very specific, e.g. ‘For visitors to our website, build a clustering algorithm that will allow us to target specific products on a featured product list, based on their browsing profile’. From that place, you will be able to frame the number staff, types of skills and the resource utility shape through the project.


Some members of a data analytics team are quite new to traditional business intelligence teams. The part they play are quite familiar, but the visualisation and narration end of the team are new niches that really show recent perception change around business engagement.

  • Data architect – a person who designs a company’s data architecture, then possibly takes part in the creation, deployment and its ongoing management.
  • Data engineer – a person who works with the architect in implementing the architecture. Utilising appropriate SQL and/or no-SQL tools depending on the data size and complexity and the task at hand.
  • Data scientist – a person who focuses on the analytical side of data. Asking the right questions and finding answers to these questions. These people often will have a strong mathematics / statistics background.
  • Data visualiser – a person who interprets the data scientist’s results, presenting them in a meaningful way. Often these people will have more artistic backgrounds.
  • Data narrator – a person who engages with the key project stakeholders to draw out the meaning and through a series of steps showing the thinking and learning through various visualisations, bringing the stakeholders along a journey or narrative.

In a small team, the architect / engineer might be a combined role. Similarly, the scientist / visualiser / narrator could be rolled up into the same person. In a larger team these should be different people with clearly understood roles. The scientist being analytical, the visualiser being artistic and the narrator as the communicator. Often these are very different personality types.


The particular group of skills and personalities will develop their own culture, which will help or hinder the group’s effectiveness.

Bearing in mind the breadth of skill and personality, selection of individuals for their intellectual curiosity and adaptability is important. Being a great technician is one thing, but having a flair, the ‘je ne sais quoi’ can be far more important.


There is a preconception is that since a data analytics team sits within IT, that the members need to have a computer science degree. This is not the case, and you will find that members from different backgrounds can bring problem solving techniques and ways of thinking that enhance the ability of a team with a ‘straight’ computer science background.

Some people believe that specific industry knowledge for a project is critical. We would usually take on engineer and scientist staff on the basis as ‘good fit for our team’ and depth of technical knowledge, over specific industry understanding. I could probably teach a data scientist all they needed to know about customer marketing or website PPC data, but if they didn’t work well as part of our team and didn’t have the technical depth, then they wouldn’t be able to pull their weight.

At the visualisation/narrative end of the team, the industry knowledge becomes more worthwhile, since it can decrease the interesting, but fruitless directions of visualisation.


Since your data analytics team is quite diverse and probably will have people from disciplines of IT, mathematics and the arts, it is important to ensure that all aspects of the team are perceived as being important.

One danger with the more creative types (visualisation, narration) is that there is often never a ‘right answer’, so there can be potentially a never ending set of analyses.

If you build a star team, to keep them, you need to keep them interested in the work, so if at all possible, try to allow some form of rotation around projects. This is much easier in a consultancy, where multiple clients/verticals run in parallel.


Data analytics is the flavour of this decade with industry clamouring to engage with the principles and technologies and universities instead of offering business intelligence courses, now offer studies in data science. It is likely that, in the same way that business intelligence was the ‘must have’ for business in 1990-2010 and has been wrapped up into data analytics, the same will happen with data analytics having a life for another 10 years, then being incorporated into the next big thing.

What will that next big thing be?

Latest from this author