Peer reviewed by Kat Holmes – Data Director ITV
As businesses recognize the decisive power of data to achieve business goals, most are hoping to put data in the driver's seat of their business and product strategies. This entails putting together a strong data team which can effectively propagate its insights across different areas of the business. Unfortunately, this is no easy task.
To be truly data driven, companies need to build three capabilities: data strategy, data governance and data analytics.
Strategy: Data strategy is your organization's roadmap for using data to achieve its goals. It requires a clear understanding of the data needs inherent to the business strategy. Why are you collecting data? Are you trying to make money, save money, manage risk, deliver exceptional customer experience, all the above?
Governance: Data governance is a collection of processes, roles, policies, standards, and metrics that ensure the efficient use of information in enabling your organization to achieve its goals. A well-crafted data governance strategy ensures that data in your company is trusted, accurate and available.
Analytics: The term data analytics refers to the process of analyzing raw data to draw conclusions about the information they contain. Typically, those involved with data analytics in an organization are data engineers, data analysts and data scientists.
Ultimately, your ability to leverage data will depend on these three pillars. If you’re reading this and realizing that your organization possesses none of these, don’t worry. That’s why we’re here. A good place to start is to build a strong analytics team, one that is closely tied with the strategic goals of your business. It is the first pillar of your data organization, and the focus of the article.
When building a data analytics team, heads of data typically grapple with the following questions:
They rightly do so; having a strong data team is not a luxury anymore, but essential to the very survival of a company today.
Let's start with the basics though.
Before building a data team, it's important that you realize where you are in your "data journey", because this will directly affect the structure of your team. This part is thus dedicated to a simplified data maturity assessment. Beware, company size and data maturity are two different things. Your organization can be large but immature on a data level.
Data maturity is the journey towards seeing tangible value from your data assets. We propose a simple framework of data maturity assessment, in which you measure your ability to understand your past, know your present and predict your future. What do I mean by this?
Well, in most companies each department has its own set of KPIs that support the execution of the corporate strategy. It’s not enough just to define them, they must also be clearly tracked, and you must also have the ability to predict future outcomes against these KPIs. This ability rests on a clear knowledge of your present, which, in turn, builds on a strong understanding of the past. Do this, and you have found a simple way to assess your data maturity. For example, if you're unable to identify the revenue drivers for your company (your past), it means you need to work on your data maturity by bringing visibility to your business before you seek to predict future outcomes. We don't recommend skipping steps. It's like Maslow's hierarchy of needs, but for data.
Let's look at a couple of practical examples:
Marketing ROI. Define your ROI, across multiple channels, by using an identified attribution model. Then understand its evolution in the previous 12 months, and especially its drivers (identify performing channels, time of the year, product, ....). Then track on a daily/weekly/monthly basis its evolution thanks to a reporting tool you trust (present). Forecast your marketing budget based on these predictive models (future).
Customer Satisfaction. Define your customer satisfaction measure. Is it NPS, CSAT? Everyone in your company should share a common understanding of how it is computed. As with our previous example, compute its evolution in the previous 12 months, find its drivers (past). Then track daily the satisfaction of your customers with trusted dashboards. Identify action to take from today to increase it. Your understanding of the past and the present state of customers satisfaction will allow to predict churn efficiently (future)
Understanding your past and present is commonly referred to as performing descriptive analytics. Descriptive analytics helps an organization understand its performance by providing context to help key stakeholders interpret information. This context is usually in the form of data visualization, including graphs, dashboards, reports and charts. When you are analysing data to forecast the future, you’re engaging in predictive analytics. The idea with predictive analytics is to take historical data, feed it into a machine learning model that considers key patterns. Apply this model to current data, and hope that it will forecast the future. We’ll use the terms of descriptive and predictive analytics throughout the article to refer to understanding the past, present or predicting the future.
If you realize that your organization is not fully mature (ie. you don't have a clear understanding of your past and present), here are our recommendations for what should be the next steps of your data team.
A data analytics team is usually composed of four core functions, which are detailed below.
Different companies will build data teams of different sizes, no one size fits all. We have studied the data team's structure of 300+ companies, with a 300-1000 employee range and derived the following insights:
There is no perfect structure for an analytics team, and your structure is likely to change many times. If your data team structure hasn’t changed for the past 2 years, then it’s likely to be a sub-optimal structure. Why? Because the data needs of your company are evolving rapidly, calling for an adaptation of your data team’s structure. Also keep in mind that the more static your organization, the harder the next change will be. For this reason, we don't prescribe a given structure, but rather present the most common models and how they can be suited to different types of businesses.
The very first step to take when structuring your data team is to find the data people that already exist in your organization. They might not be just the people with the term "data" in their title, but they could be any employee who's not afraid of data analysis or has SQL skills already, such as business analysts/ ops analysts. If you don’t take the time to locate pre-existing data people carefully, you are likely to end up with an unplanned data team structure, unlikely to fit your business needs.
The centralized model is the most straightforward structure to implement, and it is usually the first step for companies who aim to be data driven. There are, however, a few drawbacks to this model, which are referenced below. This structure usually leads to a centralized data "platform", where the data team has access to all the data, and services the whole organization in a variety of projects. All data engineers, analysts and scientists within this team are managed directly by the head of data. With this structure, the data team is reporting in a dotted line to data stakeholders based in business units, in a consultant/client-type relationship.
This flexible model is adaptable to the continuously evolving needs of a growing business. If you're at the beginning of your data journey, that is, you still struggle to have a clear vision of your past and present, this is the structure we recommend. The data team's first projects will seek to bring visibility to the business, ensuring all departments in your organization have KPIs and dashboards they can trust. This kind of structure is particularly good for analytics where reusability and data governance are important.
✅ The data team can help with other teams' projects while working on its own agenda.
✅ The team can prioritise projects across the company.
✅ There are more opportunities for talent and skillset development in a centralized team. In fact, the data team works on a broader variety of projects, and data engineers, scientists and analysts can benefit from their peers's insights.
✅ The head of data has a centralized view of the company's strategy and can assign data people to projects that are the most suited to their capabilities.
✅ Encourages career growth, as data engineers, scientists and have clear perspectives of seniority roles.
❌ High chance of disconnect between the data analytics team and other business units. In this model, data engineers and data scientists are not immersed in the day-to-day activities of other teams, making it difficult for them to identify the most relevant problems to tackle.
❌ Risk for the analytics group to be reduced to a "support" function, with other departments not taking their responsibilities.
❌ As the data team serves the rest of the business, other business units might feel like their needs are not properly addressed, or that the planning process is too bureaucratic and slow.
In a decentralized model, each department hires its "own" data people, with a centralized data platform. In this model, data analysts and scientists focus on the problems faced by their specific business unit, with little interaction with data people from other areas of the company. With this structure, data analysts report directly to the head of their respective business unit.
✅ Embedded teams of data people are agile and responsive, because they are dedicated to their respective business functions and have good domain knowledge.
✅ Product managers can assign data tasks to the people most qualified to work on them.
✅ Business data teams don’t have to fight for resources to build their data project because the resources sit in the teams.
❌ Lack of source of truth, duplication of data content
❌ Data people end up working on redundant issues due to a lack of communication between different teams.
❌ The creation of silos leads to productivity erosion since data people can't draw on their colleagues’ expertise as they do in the centralized model.
❌ This model makes it harder to optimally staff data people on different projects.
❌ Business managers, usually lacking technical backgrounds, will find it hard to manage data people and understand the quality of their work.
A federated model is most suited to companies that have reached data maturity, have a clear data strategy and engage in predictive analytics.
In the Centre of Excellence model (COE), data people are embedded in business units, but a centralized group that provides leadership, support and training remains. If data analysts and scientists are deployed across business departments, you would still have a data leader (or a core of data leaders according to company size) who prioritizes and supervises data projects. This ensures that the most beneficial data projects are tackled first.
This strategy is most suited to larger, enterprise-scale companies with a clear data roadmap. The centre of excellence model entails a larger data team, as you need data scientists both in the COE and in the different business branches. If you are a small or medium company, your needs might not require a data team of this size.
This approach retains the advantages of both the centralized and the embedded model. It is a more balanced structure in which the data team's actions are coordinated, but also keeps the data experts embedded in business units.
Again, it's extremely important that you know who your data people are. When building a centralized team at the beginning of your data journey, make sure you don't have business analysts/ops embedded in other departments. Otherwise, you will end up with an unwanted mixed model, creating complete chaos in your organization. When creating a COE, you need to ensure it's wanted and planned.
✅ The Centre of Excellence model provides the advantages of both the centralized and the embedded models.
It still presents some drawbacks, though:
❌ This model requires an additional layer of coordination and communication needed to ensure alignment between COEand business units.
❌ Not fit for purpose for small – medium sized organizations, so these companies can then hook it to the benefits that can come with this hub and spoke model.
Building a strong analytics team is a key pillar you need to build if your company is to become data-driven. The extent to which you will extract business value from data ultimately depends on the strength of this team, and how symbiotic it is with the rest of your business. There is no made-to-order advice for the size, composition and structure of your data team. That's why you need to understand the data maturity level of your organization, so that you can build a data team suited to your business' needs and aligned with your business strategy.
We write about all the processes involved when leveraging data: from the modern data stack, to data teams composition, to data governance. Our blog covers the technical and the less technical aspects of creating tangible value from data.
At Castor, we are building a data documentation tool for the Notion, Figma, Slack generation. Or data-wise for the Fivetran, Looker, Snowflake, DBT aficionados. We designed our catalog to be easy to use, delightful and friendly.
Here's a quick preview:
Want to test it out with your own data? Sign up and we will get you started.