Your mission is to drive analytics adoption in your company and you have a handful of dedicated people to do it with. It’s a start, but it’s modest and you’re going to need to demonstrate some successes before you’ll be able to grow. You’ll need to get buy-in from the business and deliver results, but also spend enough time on core analytics strategy that your successes build leverage over time. Hiring the right people for the job is fundamental,  but how the analytics team is structured can be just as important in building a winning analytics function.

When it comes to structuring a specialty function, everyone will have their own idea how to do it and each company's own unique culture, size, and goals will drive the most appropriate approach. I wanted to share some of my thoughts on what it’s like to work in a team that follows one of the three most commonly talked about models: the centralized model, the decentralized model, and the hub and spoke model.

Centralized team

In this model, there is a single team that manages analytics requests for the department and they internally disseminate that request to the team members best equipped to handle them. 

Pros

• This tends to work well where the team is offshore and is common where there is little integration between the department and the analytics team.

• The analytics team works more closely together and it's easier to perform knowledge sharing sessions and share resources.

• Analytics managers can determine the workload of the team and split time between supporting the business and investing in more foundational initiatives.

Cons

• The downside of this approach is that it is often hard for the analytics team to really understand the businesses they support and to identify new analytics use cases. As such, teams are more likely to end up working on lower value propositions and pieces of work that the business is less passionate about completing themselves. The business often sees this type of team as an outsourced resource and to compensate, management may put in place bureaucratic processes to request analytics resource. This will undoubtedly define the relationship that the team has with its stakeholders.

Fully decentralized

In the fully decentralized model, the analytics team members sit with the business teams rather than in the analytics team itself. They form part of the business teams and work on their projects and priorities.

Pros

• Analytics team members learn first hand about the businesses they support and build stronger relationships with their stakeholders. This insight is key to ensuring that the analytics teams are focussed on the right priorities and understand the business well enough to build quality solutions

Cons

• You will need to have enough analytics team members to distribute to the different businesses.

• You will need team members who are clear on their role in the team and the support of business management to ensure that team members continue to focus on value-adding analytics problems. I've seen a number of cases where, over time, members of the analytics team find themselves either roped into other team initiatives or performing questionable 'analytics' work because the rest of the team don't want to do it. As a result, the valuable analytics work that could be achieved grinds to a halt.

• It can be hard to allocate resources to more foundational initiatives that would benefit multiple teams but are not directly tied to a particular business, for instance providing a database environment for analytics.

• It can be harder to form a cohesive analytics strategy and to leverage shared experience to solve analytics problems faster. In this setup, frequent knowledge sharing sessions and shared resources are important to make sure that the team continues to build on each other's successes.

Hub and spoke

The hub and spoke model combines the previous approaches by having one centralized team that focuses on core analytics priorities while also having a team that is aligned to each of the business areas supported. The two teams can have divergent skill sets to help best accomplish their own goals. I’ve found that the core team is most effective when it houses a developer skillset with a few data scientists thrown in, while the business aligned teams work well with a balance of analytics and business background.

Pros

• The Central team is able to focus on Core analytics priorities that would benefit multiple teams but are not directly tied to a particular business, for instance providing a database environment for analytics.

• Analytics team members learn first hand about the businesses they support and build stronger relationships with their stakeholders. This insight is key to ensuring that the analytics teams are focussed on the right priorities and understand the business well enough to build quality solutions

Cons

• You will need enough team members to support having both a core and business aligned team

• You will still need team members who are clear on their role in the team and the support of business management to ensure that team members continue to focus on value-adding analytics problems and not other business initiatives.

• You will also need to invest time in keeping the whole team aligned and ensuring that the best ideas are shared across both the core and business aligned teams so that they can be executed where it makes the most sense

Getting the most out of your data analytics team will be a different challenge in each organization and the short and longer term objectives of the team will be key in determining how best to structure things.

As always, I’d love to hear your thoughts and the experiences you’ve had structuring analytics teams. Have you opted for a different model altogether? What made you choose a particular structure for your team? What decisions were key in getting you there?

Leave a comment below or send me a message @eageranalyst