We’re introducing Stakeholders so data teams can empower domain experts to take ownership of data design.

People generating the data they need isn’t a likelihood. It’s an inevitability. It’s up to data leaders to provide a system that lets domain experts fend for themselves without compromising data quality. We went deep on this problem in our recent post on the risk of domain ownership (and how to mitigate it). 

To help you get there, we’re introducing Stakeholders. Together with Guardrails, Stakeholders will enable federated data teams to delegate data design to the people with the most expertise in their area of focus, while still shipping great, high quality data.

Why we’re launching this: Read up on The risk of domain ownership (and how to mitigate it)

What is a domain?

A domain is a team dedicated to a certain function. It could be a product area (Search, Checkout, etc), an entire app for specific personas (Drivers, Riders, etc) or a business function independent of the product (Marketing, Sales, Finance, etc.). 

Domains have different data needs and they need to be able to influence what data they get access to. But they have different access to the ability to generate the data they need. For instance: the finance team will need the product team to generate events related to the user experience so they can measure retention to predict financial outcomes. 

Hence domains are often dependent on other domains for the data they need.

The problem with central governance

Many organizations have instated a centralized data team to oversee data governance across various domains. This central team is responsible for ensuring that different departments have the data they need, along with maintaining the data infrastructure of the company. 

The problem with this model is that it constricts data design to a handful of data experts, leading to painful review cycles, human bottlenecks, and delays to analytics. We need ways for domain experts to take ownership of their data, so they can move fast without requiring input from the central data team on every single change to analytics. As our friend Giorgio at Boozt put it in a conversation with his CTO:

- Giorgio: "what would you think if a small team dictated all of the lines of code that your other countless engineering teams then have to write?"
- CTO: "that would be insane"
- Giorgio: "exactly"
‍
Giorgio Terreni – Senior Data Analytics Specialist at Boozt.com when making the case for a federated tracking governance instead of a centrally managed one.

Delegate data design to domain experts at no compromise to quality

You can now segment your Avo tracking plan by areas of ownership and accountability, by connecting subsets of the events of the tracking plan with the users or groups of users that work with those events.

This empowers each domain to take charge of their data, by giving each domain team a clear overview of the events they are leveraging.

It’s not just about delegation, it’s about shifting ownership of data to the right people. It’s no longer a matter of saying, “Hey, you wanted this on the tracking plan, here you go.” Now it’s “You own this event.” You may not be the engineer, but you’re responsible for ensuring the event has the properties you need. With ownership, they can focus on what matters, which in turn makes them more data-driven and interested in the data.
‍
Coty Pastene – Data Lead and Head of Strategy at Fender

Stakeholder observability: A new level of focus with stakeholder-specific alerts and views

By breaking down your organization's tracking plan by stakeholders, each stakeholder will be able to focus on just the data relevant to them, without being overwhelmed by everything the entire company is measuring. 

Each stakeholder can enter a view of their tracking plan. For data consumers, it’s clear what data is available for analysis, what to build on and who to collaborate with when tracking is needed for a new feature release.

Within your Stakeholder-specific tracking plan, you can also see which data structures are shared with other domains, facilitating collaboration between teams. 

You will now have Stakeholder-specific alerts, observability and overview of data inconsistencies, making it much easier to find and fix data issues for events your stakeholders rely on.

Impacted Stakeholders: Understand how changes impact others (and how to get around it)

Users will see impacted stakeholders so they can avoid unintentionally impacting company-wide data.

When users make changes to events or properties that are leveraged across multiple domains, they will be made aware of how those changes might affect other domains. By having this visibility, stakeholders can iterate on the tracking plan with more confidence, knowing that breaking changes won’t fly under the radar.

In some cases, there may be a legitimate need to make changes that impact multiple teams (e.g when rolling out a new property on an event that should be tracked in multiple areas of the product). But sometimes changes are specific to a specific feature or product area. By calling this out, the user is able to minimize the way changes might impact others. 

Stakeholder-specific required reviews: Ensure reviews from impacted stakeholders

You will have stakeholder-specific feedback reviews where Avo will pull in the impacted domain owners for review.

In cases where a cross-domain change is required, we plan to make it as smooth as possible for stakeholders to coordinate on those changes. With stakeholder-specific required reviews, relevant stakeholders will be automatically brought in for review of suggested changes, when they impact their domain.

More focused reviews

We know it’s incredibly painful and labor intensive to keep up with reviewing extensive analytics changes that require you to get in the mindset of deeply understanding a bunch of different domains. That’s why we’re bringing stakeholder-focused reviews.

Stakeholders will only be required to review changes that impact their particular domain, rather than review all new iterations in the branch. This will alleviate the burden for federated data teams, who won’t have to contend with big batches of unreviewed changes. 

Say goodbye to constant back-and-forth and accelerate tracking releases with a review process that moves as fast as you do.

Join the Beta and help shape Stakeholders as the key to data mesh for event-based data

We’re excited to introduce Stakeholders, Stakeholder observability, and Stakeholder-specific reviews to your workspace. Stakeholders will be rolling out to your Avo workspace in the next couple of weeks, with review workflows coming out later this year.  

If you’re keen to get your hands on these new capabilities and help us shape the future of domain-driven data design in Avo, sign up for beta access below.

Want Stakeholders added to your workspace? Request Stakeholders beta access ->

New to Avo and want to learn more? Book a demo ->

‍

—

Special thank you to Elmira Gatina, Coty Pastene, Cathy Wong, Giorgio Terreni, and Ursula Llaveria for their great insights and valuable contributions to this post.