How would one take on the task of leading a transition to become a data-driven company? Can you change your organisation into a structure similar to Google? To Facebook? To Tesla?
We see more and more companies initiating the transition to data-driven organization models, but many such initiatives have failed. In this article, I will dive into the characteristics, strengths, and weaknesses of several of these models.
There are 3 crucial high-level steps to perform a sound company structure transformation:
- Identify your current situation;
- Determine your targeted structure model;
- Determine which intermediary structure will allow you to reach your target.
I will talk a bit more about step 3 in another article to allow us to focus here on identifying your organization’s approach to data today and determining what success could look like for your company.
Decentralized Model
This is the least coordinated model where analytics efforts are used sporadically across the organization, and resources are allocated within each group’s function. This often happens in companies where data science expertise has appeared organically. Business units, like product teams or functional units, had recognized their internal need for analytics and started hiring data scientists to meet this demand. Sometimes a data scientist may be the only person in a cross-functional product team with data analysis expertise.
The decentralized model works best for companies with no intention of transitioning to be a data-driven company. This model may also be applied to the early stages of data science activities for demo projects' short-term progress that leverage advanced analytics.
The drawbacks of the model are the following:
- There is a lack of analytics standardization, e.g. multiple programming languages are being used for analytics.
- There is a data accessibility issue. Without a unified data source, there will be many inefficiencies in scaling solutions throughout the company.
- There is also a lack of visibility to the Data Science efforts done outside the business functions with a risk of duplicating efforts.
- The hiring process can be an issue as there is no standardization of the company's interview process for data scientists, leading to varying expertise levels within the organization.
- Such a model would also lead to an unclear career path for Data Scientists. This may harm the company's attractiveness for such profiles and lead to higher turnover.
- A disjointed data scientist organization will cause a gap in the mentorship process, resulting in lower quality standards and underestimated best practices. Without a clear structure, data scientists may find themselves isolated in an organization. This is likely to lead to no improvements in best practices, which reduces data quality and product effectiveness overall.
Functional Model
In this model, most analytics specialists work in one functional department where analytics is most relevant such as marketing or supply chain. This option also entails little to no coordination, and expertise isn’t used strategically enterprise-wide.
The functional approach is best suited for organizations that are just starting their analytics roadmap. They do not need to analyze data from every single perspective. Subsequently, there are not so many analytical processes to create a separate and centralized data science team for the whole organization.
The drawbacks of the model are the following:
- Analytics focused on one function may lead to a lack of consideration of the global company’s needs and pain points. Such unawareness results in analytics isolation and solution irrelevancy to the context of executive leadership.
- The lack of a central data manager may negatively impact the company's general data roadmap, leading to potentially wasted efforts in justifying all projects and a lack of synergy between projects.
Consulting Model
In this structure, analytic people work together as one group, but their role within an organization is centred around consulting, meaning that different departments can “hire” them for specific tasks. This, of course, means that there’s limited advanced resource allocation — either a specialist is available or not.
The consultancy model is best suitable for SMB (Small & Medium Businesses) with sporadic and small- to medium-scale data science tasks. As all Data Science (DS) team members submit and report to one DS team manager, managing such a team becomes easier and more cost-effective for a company.
The drawbacks of the model are the following:
- Poor data quality can become a fundamental flaw in the model. As data scientists have to work with different units sporadically, they can’t adhere to their best practices for every task, they have to sacrifice quality to business needs that demand quick solutions.
- As data scientists are not fully involved in product building and decision-making, they have little to no interest in the outcome and fall into the low-motivation trap.
- A serious drawback of a consulting model is uncertainty. Deadlines are not clear as data scientists are not clearly familiar with data sources and the context of their appearance. Long-term and complex projects are hardly accessible because sometimes specialists work for years over the same problems to achieve great results.
- The prioritization method is also unclear. It’s still hard to identify how a data science manager prioritizes and allocates data scientists' tasks and which objectives to favour first.
Centralized Model
This structure finally allows the use of analytics in strategic tasks — one data science team serves the whole organization in various projects. Not only does it provide a DS team with long-term funding and better resource management, but it also encourages career growth. The only pitfall here is the danger of transforming an analytics function into a supporting one.
One of the best use cases for creating a centralized team is when the demand for analytics resources is rapidly increasing, requiring the urgent allocation of these resources. Introducing a centralized approach, a company indicates that it considers data a strategic concept and is ready to build an analytics department of equal relevance to sales or marketing teams.
The drawbacks of the model are the following:
- There’s a high chance of becoming isolated and facing the disconnect between a data analytics team and business lines. As the data analytics team doesn’t participate in the day to day activities of every business unit, they might not be closely familiar with the latter’s needs and pains. This may lead to the narrow relevance of recommendations that can be left unused and ignored.
- This leads to challenges in meaningful cooperation with a product team. Once the analytics group has found a way to tackle a problem, it suggests a solution to a product team. The biggest problem is that this solution may not fit into a product roadmap, potentially generating conflict. The only way out is to create a team that would assess, design, and implement the suggested solution. This alternative, however, takes much effort, time, and money.
Center of Excellence (CoE) Model
This option will still keep the centralized approach with a single coordination centre and allocate data scientists to different units in the organization. This is the most balanced structure — analytics activities are highly coordinated but won’t remove experts from business units.
Due to its well-balanced interactions, the approach is being increasingly adopted, especially in enterprise-scale organizations. It works best for companies with a corporate strategy and a thoroughly developed data roadmap.
The drawbacks of the model are the following:
- While this approach is balanced, there’s no single centralized group that would focus on enterprise-level problems. Each analytical group would be solving problems inside their units.
- Another drawback is that there’s no innovation unit, a group of specialists focusing on state-of-the-art solutions and long-term data initiatives rather than day-to-day needs.
Federated Model
This model can be seen as the evolution of the CoE model to compensate for its drawbacks. In addition to the distributed data scientists as in the CoE model, this model would add a SWAT team of sorts. This group would be able to focus on complex cross-functional tasks and further data science innovations.
The federated model is best suited to companies where analytics processes and tasks have a systemic nature and need day-to-day updates. This approach can serve both enterprise-scale objectives like enterprise dashboard design and function-tailored analytics with different types of modelling.
The drawbacks of the model are the following:
- Expenses for talent acquisition and retention. As this model suggests a separate specialist for each product team and central data management, this may increase costs. Thus, the approach in its pure form isn’t the best choice for companies in their earliest analytics adoption stages.
- Cross-functionality may create a conflict environment. It can lack a power parity between all team lead positions and cause late deliveries or questionable results due to constant conflicts between unit team leads and CoE management.
Conclusion
This article is not an exhaustive list of organisational models which can be applied. It instead focuses on those who can support a company during a transition to a data-driven approach.
It may make sense to try to focus on the Federated Model as an end goal for most companies, as this model has the most valuable and efficient potential. As this model is also the one that will have the highest impact on the costs of a company, it may make sense to identify an intermediary structure.
Having worked for companies with varying data maturity levels, I have seen that the best approach was to identify a resource (internal or external) with extensive experience in a multitude of AI business applications. This person should be given access to all the processes of the company and top management exposure. This person would then determine a Data Development Roadmap; depending on this roadmap, selecting the perfect organisation model would come naturally.
