Applying team topologies to data product teams and platforms

Disclaimers:

• These observations and suggestions are personal observations and do not represent my current or previous employers. Any resemblance is purely coincidental.

In my last blog, I recapped how I witnessed the data & analytics team and behaviors have evolved over the last two decades and essentially how the Conways’ law has come into effect that created the boundaries and the disconnected data lakes or the centralized data warehouses resulting in the copies of data floating around every infrastructure layer in the company.

In my humble opinion enterprises can reap the value from data by digging deep into the people-process-technology triangle:

Figure 1 — People, Process and Technology — PPT triangle of data

This is one of the reasons why I like the paradigm shift that Data Mesh introduces in the shape of the 4 principles or as I lovingly call them “Mind, Body, Heart & Soul”

Figure 2: 4 principles of data mesh — “Mind, Body, Heart and Soul”

Don’t worry I am not going to explain the principles. You can read all about them from the articles linked in the reference section below :)

In the last 5 years, I started my journey of becoming a product leader and started to learn about the concept of product teams and have been fortunate enough to have been taught by the very best, Marty Cagan in his “Empowered Workshops”. During this continuous learning journey, I have been introduced to “team topologies” by Matthew Skelton and Manuel Pais as well. I think the concept of the empowered product teams, 4 types of teams in team topologies can also be applied to the 4 principles of data mesh and that’s what I wanted to share in this article.

Figure 3: Team topologies concept applied to data mesh

Stream Aligned Teams & Data Domains and Data as a Product

Let’s start with the stream align teams and the first two principles of data mesh: Domain Orientation and treating data as a product. Instead of the traditional division of IT and business and having a series of handovers between one team to another, under the umbrella of data domains (which is not necessarily the organization structure or department in a company), cross-functional data product teams can be formed. These are good examples of stream-aligned teams as described in Team Topologies. I love to describe these teams as the “product trio” following the continuous discovery teachings from Teressa Torres.

Figure 4: The product trio engaging the end-user

In real life, when we double-click on this trio, more often it is more than three people. Sometimes, this is also called the “two-pizza” size teams. But If you are like me, it will be just a two-person team as I usually end up eating the entire Pizza. Jokes apart, I always encourage and practice setting up the data product team as follows:

Figure 5: Data product team composition

It follows the “pattern” of the product trio but has specific roles, which are important in terms of data product teams. Depending on what this product team is trying to achieve, this can even include roles such as data scientists and UX developers. Sometimes, even a specialized UX designer is a good addition to the team, especially at the beginning of the journey which can later be off-boarded or shared across the domain. Having said that, the responsibility of applying these human-centered design practices is not on this one person’s job. In the above example, UX can be a front-end through which the end users of this product will engage with the data. It can be a dashboard or a report or if no such interface is desired it can be an API or a ODBC/JDBC connection to the underlying data — again depends on the boundaries the data product team is defining.

Depending on the dynamics and maturity of the organization, these roles and people can come from IT & business and from different functions. Hence, the team composition can look something like this:

Figure 6: Data product team composition in IT, Business, and cross-functional setting

Here is the legend of the shapes and colors and background to explain the various options of team composition.

Figure 7: Legend to the team composition figures (2 & 3)

Irrespective of whether someone is from IT or business, internal or an external contractor (we need to accommodate the reality of working with contractors too, considering the position a company might have on what kind of talent is needed internally and what can be outsourced, etc), I cannot emphasize enough that the mindset of these individuals is what set apart a “feature” team who is taking orders or waiting for requirement specifications and following some kind of “agile theatre” and the empowered product team of missionaries. This is a critical aspect of having the right team that treats data as a product and the key to the success of the decentralized domain orientation. For instance:

• The teams have the right skills to handle the various data modalities introduced by the source systems.
• If they don’t know a technology or a technique they go and learn it. (Heck… Google it or ask ChatGPT) — but they are not waiting helplessly for someone else to handhold them.
• They talk to their end-users/customers. They sit with them (even though it is not in person), they understand the business context and they understand the WHY. They understand the problem space and the opportunities.
• There is a passion to provide a delightful end-user experience, it is all about putting yourself in end-user shoes
• They don’t know everything from the beginning but they apply the continuous discovery practices and work through the possible opportunities and frequently and constantly test them with their end users
• They are not hiding behind the ceremonies and policies and procedures. By all means, the teams have to follow the necessary data compliance necessities but those are not show stoppers

The list goes on, but coming back to the team topologies and data mesh, these stream-aligned data product teams are focused on the business outcomes and use various services from the platform teams. Historically a typical data initiative starts by building technical features from the ground up and in the first year of that initiative, only those back-end technical features come to see the light of the day and when one year down the road, there is no business impact, the management wonders what value this initiative has delivered and many times another new initiative is born while the old one is still going on. Sounds familiar?

However, if the platform team, which is another important team type in team topology, is focused on creating that developer experience for the stream-aligned data product teams, organizations can witness the magic of platforms and speed to value. In this new paradigm, these data product teams are consuming various services from the platforms and one can see the team interaction of “X-as-a-service” in terms of team topologies. But before I talk about platform teams and platforms (most likely in a follow-up article), there is an important aspect of enabling teams, which is also critical for organizations who are embarking on the journey of data mesh and value creation.

Enabling Teams is a powerful construct in team topologies and in my experience, it is applicable in multiple places when it comes to implementing data mesh. Here are a few examples:

Onboarding Teams:

• Enabling teams take the business and IT organizations through the journey of data mesh implementation from exploration. Eventually bringing them together behind a common goal, exploring the use cases that will have the biggest impact and facilitate the inception of the first data product team within that domain.
• These teams play a vital role in aligning the vast organization through a common language and consistent messages.
• A structured methodology, such as using the double-diamond design thinking approach to help a domain through its data mesh journey can be followed.
• Since these teams are engaging multiple domains and functions, they are not only facilitating the stream-aligned teams but also bringing back key insights from such engagements back to the platform teams

Governance Teams:

• Similarly, Enabling Teams construct is also applicable for the domain governance bodies, which are there to deep dive within the domain to facilitate alignment of various data product teams within the domain.
• Caution: Depending on the size of the organization and the nature of the domain and business, multiple teams might be working on similar topics and hence visibility & transparency from the very beginning can avoid this duplication of work and the data

The Federated Governance Body across the domains is also a great example of applying the Enabling Team construct, there this body is facilitated and encourages the data sharing and application of common standards and reusability of the “X-as-a-Service” from the platform team. This way, such governance bodies can play the role of enabler and not the traditional bureaucratic nature that we have come to associate with the word “governance”

Figure 8: Stream-aligned teams in domains collaborating with each other as the enabling team facilitates the onboarding and governance

In order for such decentralized teams to succeed in achieving their business outcomes and to build some of the governance policies as part of the automation, the platforms team plays a crucial role and thus this 3rd principle of data mesh and the team concept of platforms is so vital and forms the backbone of the data mesh implementation. I will cover especially this principle, platforms, and the platform teams in the next blog… stay tuned

References:

• Link to my previous blog
• Data mesh article and the book
• Team topologies website
• SVPG — Missionaries vs Mercenaries
• Continuous Discovery Habits