Register now for - "Data Sharing and Marketplaces: The New Frontier in Data- Thursday, December 15, 11 a.m. Eastern Time.

An Operating Model for Data & Analytics Part III: Team Composition and Dynamics

ABSTRACT: There are many models for bridging business and technical teams, but each requires careful consideration of team composition and company culture.

This is the third article in a multi-part series on data & analytics operating models. 

In the last article, I defined knowledge flows between blue (enterprise), purple (hybrid), and red (business) teams. These flows of information facilitate a federated operational model that delivers the benefits of both centralization (i.e., efficiency and standards) and decentralization (i.e., agility and flexibility) without any downsides. I also outlined six types of purple teams that build effective local solutions while adhering to enterprise standards and best practices.

In this article, I will drill into the composition and dynamics of blue and purple teams. Although there is no right way to organize teams, there are guiding principles that data leaders should follow to ensure proper alignment of data & analytics resources throughout an enterprise. Many data leaders discover that they need to implement multiple federated models to align development and deliver high levels of customer satisfaction.


Many data leaders … implement multiple federated models to align development and deliver high levels of customer satisfaction.


Blue Team Composition 

As I mentioned in the first article, the enterprise data & analytics team is responsible for managing shared data across the organization and delivering strategic or enterprise solutions. It is also a repository of technical experts who train and coach purple teams, establish standards, and help purple teams build technical solutions. As such, an enterprise data & analytics team is comprised of many departments and roles. (See figure 1.)

Figure 1. Composition of an Enterprise Data & Analytics Team

No two blue teams are organized in the same way. However, every data & analytics team needs to support the functions and roles defined above. In small or mid-size companies, some functions are rolled together, such as data architecture and data engineering or business intelligence and analytics. Likewise, a single individual might handle several roles. For instance, a data engineer might handle quality assurance, API development, and dataops monitoring.

At first blush, the enterprise data team is large, perhaps larger than most CEOs and CFOs would like. And the diagram doesn’t include optional departments, such as data governance, master data management, data innovation, and data security, which sometimes report to other areas of the business. It helps to remind business leaders that in a federated operating model many enterprise developers reside in or work exclusively for individual business domains, not a chief data officer intent on empire-building.

Analytics Team. There is always debate about whether data analysts and data scientists should reside centrally or in the business units. It can work either way, as long as there is a central analytics team that establishes best practices and standards and oversees individuals no matter where they’re located. In general, however, data scientists do better centrally, where it’s easier for them to share knowledge, receive training, and rotate domains. Most are academically trained and seek a collaborative environment in which to work. Conversely, data analysts do better in business units where they become steeped in business requirements, processes, and data and can work proactively to solve problems. The key is to federate the roles. If data scientists are centralized, they need to be assigned to a business unit for a minimum of two years; if data analysts are embedded, they need to be coached and managed by an enterprise director of analytics.


The key is to federate the roles.


Data Platform Team. In the last article, we discussed the importance of a data platform to simplify and accelerate the development of data solutions by purple teams. Given the importance of a data platform to federated development, it’s critical that organizations establish a team dedicated to continually improving the enterprise data platform to foster greater levels of self-service. Members of the data platform team should work exclusively on the data platform; they should not be assigned to business projects to help the enterprise team deal with a persistent backlog or a sudden crush of requests. Such a move would delay self-service improvements designed to eliminate the data bottleneck.


it’s critical that organizations establish a team that is dedicated to continually improving the enterprise data platform to foster greater levels of self-service.


Program Services. One department that most data leaders overlook is the program services team. This team’s mission is to coordinate, educate, and align development resources across the enterprise. It does this by overseeing purple teams, ensuring that each has sufficient resources, receives proper training, and builds data products and solutions that adhere to enterprise standards.

The team consists of program managers who oversee the purple teams and their relationships with business customers; one or two managers who help hire, evaluate, and manage embedded data analysts and data scientists; a coordinator who leads the data literacy program and communities of practice, and scrum masters and project managers who facilitate project work. Unfortunately, most organizations don’t have a program services department, which makes it almost impossible for a federated operating model to work effectively.


Most organizations don’t have a program services department, which makes it almost impossible for a federated operating model to work effectively.


Purple Team Configuration

There are six ways to construct a purple team. If your organization leans toward a centralized model, then consider using tiger teams, an analytics center of excellence (CoE), or aligned business analysts. If it leans towards a decentralized approach, use data domain teams, embedded data analysts, or spanners. (If you have another model, I’d love to hear about it!)


Federated (purple team) models are not exclusive; they usually coexist.


Multiple models. Most companies need to support multiple models to meet varying business needs. For instance, most companies have embedded data analysts no matter what models they’re using. Business units operate more efficiently with one or more data analysts at hand. Many also employ multiple centralized models at the same time (i.e., tiger teams plus an analytics CoE). The same is true for decentralized models: companies with data domain teams also usually have embedded analysts and spanners. Federated (purple team) models are not exclusive; they usually coexist.

Centralized Purple Models 

1.Tiger Teams. Also known as SWAT teams, tiger teams are small, cross-functional, cross-trained teams of technical specialists who are permanently assigned to a high-demand business domain and are backed up by a shared services center to fill in technical gaps where needed. (See figure 2.)

Figure 2. Tiger Team Composition

Tiger teams are usually comprised of three members of the enterprise data & analytics team who work full-time on the team and are cross-trained in each other’s area of expertise. Most teams have a data engineer, a BI developer, and a business or technical analyst. Each team works exclusively with a single domain. If the domain requires machine learning models, the team might have a full-time data scientist instead of a BI developer. The teams are supported by a shared services team consisting of data modelers, MLOps developers, and other specialists whose expertise is needed for a part of the project.


It's best if tiger developers spend one or two years in a business domain and then rotate to another domain.


It's best if tiger developers spend one or two years in a business domain and then rotate to another domain. Some may choose to stay in the domain to run data development permanently as part of a data domain team (see below) or assume a business role in the domain, such as product manager. In either case, tiger team members become valuable corporate citizens who develop a great understanding of how to apply technology to address business needs.

2. Analytics Centers of Excellence. Many companies have central teams of data analysts and data scientists who undertake analytics projects requested by business domains or departments. If the center assigns analysts and scientists to specific business domains or functional areas for extended periods, this model works well. If they are generalists responding to any request that comes in regardless of domain, it doesn’t. In the former case, data analysts and data scientists build solutions quickly and effectively and often proactively suggest solutions before the business asks for them. In the latter case, analysts function more as a shared service, which rarely provides high levels of business value or satisfaction.

An analytics center of excellence needs a strong analytics leader who meets regularly with business leaders to understand their strategy and goals and review projects that support those aims. The leader also works closely with data analysts and scientists, training them how to communicate with business managers, frame projects, and present results in a language that business leaders understand. The analytics leader also promotes sharing and collaboration among data analysts and data scientists so they continuously expand their knowledge and skills and become better partners with the business.

3. Aligned Business Analysts. A third way to federate development using centralized resources is to create a team of aligned business analysts. These individuals are intermediaries between business and IT resources who capture business requirements and translate them into technical specifications for a centralized team of developers to build. Although they report centrally, they are assigned to a business domain for a two-year rotation where they attend strategic, tactical, and technical meetings and gain intimate knowledge of the business, players, and processes. The best business analysts work strategically with business leaders in their domain and proactively suggest or prototype technical solutions. They are senior relationship managers, not entry-level people or order-takers.


The best business analysts work strategically with business leaders and proactively suggest or prototype technical solutions; they are not order-takers.


Although many data & analytics leaders profusely extol the benefits of good business analysts, there are limitations to this approach. First, business analysts are translators between business requirements and technical specifications, and something always gets lost in translation. Their existence also means developers are a step removed from the businesspeople they support. Without that direct domain knowledge, developers often don’t optimize solutions or accelerate delivery. And if a business analyst leaves, the domain’s connection to IT is cut, leaving them stranded without adequate support. A better approach is to create a tiger team that includes a business analyst (see option #1 above.)

Decentralized Purple Models

1. Data Domain Teams. The data mesh methodology has popularized the notion of data domain teams. These are teams of business-savvy technologists (or technically-savvy business users) who reside permanently in the business and build data solutions for the business unit. Domain teams are the flip side of tiger teams. Domain teams report to business unit heads, while tiger teams report to chief data officers who run the enterprise data & analytics team. Domain teams have total autonomy to build data products as they see fit, as long as they leverage a common data platform, adhere to enterprise data standards for creating and publishing data products, and apply global data governance rules.

The danger with data domain teams is that they turn into data silos. This happens if the data domains are given too much autonomy or the enterprise team fails to establish standards and best practices, educate domain teams about them, or enforce the standards. To succeed, data domain teams require a strong, enterprise data team that supports, trains, and coordinates data domain teams and provides a centralized data platform for them to use.

2. Embedded Data Analysts. Most executives don’t realize that their companies spend millions of dollars annually on data analysts. Department heads and business unit leaders hire data analysts to run custom analyses and build custom reports for them without going through central IT. The number of embedded data analysts is inversely proportional to the effectiveness of the enterprise data team. The more frustrated business leaders become with the enterprise data team, the more data analysts they hire. The danger with embedded data analysts, like data domain teams, is that they build solutions willy-nilly without standards. The result is a proliferation of spreadmarts and fragmented data.


The number of embedded data analysts is inversely proportional to the effectiveness of the enterprise data team.


Embedded data analysts can be a tremendous resource. They are technical generalists and domain experts. This means they can build data products that business leaders love quickly and effectively. To fully harness the potential of this group, the enterprise data team needs to establish a program services department (see above) and hire one or more analyst managers to hire, train, evaluate, and manage embedded data analysts. Although the data analysts reside in the business and report to department heads, they are coached and managed by experienced analytics managers on the enterprise data team.

3. Spanners. The term “spanners” was coined by Eric Colson, former head of algorithms at Netflix and StitchFix. Spanners are embedded data analysts on steroids. They have all the skills and software licenses to build a data solution from start to finish. They know how to gather requirements, model data, build pipelines, run tests, create reports, and build machine learning models. Since they reside in the business, they also have deep domain knowledge and can build effective data solutions quickly.

Like embedded data analysts, spanners need to be schooled in enterprise standards and processes, so they know how to build data-conforming solutions. As you can imagine, spanners are rare but worth their weight in gold. They cost twice as much as a regular data analyst or data developer but are ten times more productive. Nonetheless, spanners, like embedded analysts and domain teams, need to be supported with blue-to-purple knowledge flows.


Spanners are rare but worth their weight in gold.  


Conclusion

It pays to think carefully about the composition of your blue (enterprise) and purple (hybrid) data teams. If your company has a more centralized organizational structure, it should consider tiger teams, scrum teams, and centers of excellence to bridge business and IT boundaries and deliver effective data solutions quickly. If it leans toward a decentralized model, it should consider implementing domain teams with embedded data analysts, data scientists, and spanners that are centrally supported by a strong program services department.

Since most organizations are not entirely centralized or decentralized, data leaders will likely need to embrace all federated operating models described above. The choice of models depends on the nature of the business domains and departments. For example, some domains, such as customer journey, customer experience, and risk management have their own data & analytics talent and tools and will benefit more from a decentralized approach. Others, such as human resources, legal, and operations, that don’t have strong technical expertise, will benefit from more centralized approaches.

In the next article in this series, I will examine the composition of red teams and how they interact with the purple and blue teams.

Wayne Eckerson

Wayne Eckerson is an internationally recognized thought leader in the business intelligence and analytics field. He is a sought-after consultant and noted speaker who thinks critically, writes clearly and presents...

More About Wayne Eckerson