The Lack of Responsibility in Data Mashing

Sign up for Data Mesh Understanding's free roundtable and introduction programs here: https://landing.datameshunderstanding.com/

Please Rate and Review us on your podcast app of choice!

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

Episode list and links to all available episode transcripts here.

Provided as a free resource by Data Mesh Understanding / Scott Hirleman. Get in touch with Scott on LinkedIn if you want to chat data mesh.

Transcript for this episode (link) provided by Starburst. See their Data Mesh Summit recordings here and their great data mesh resource center here. You can download their Data Mesh for Dummies e-book (info gated) here.

Tina's LinkedIn: https://www.linkedin.com/in/christina-albrecht-69a6833a/

In this episode, Scott interviewed Tina Albrecht, Lead Coach for Data-Driven Transformation at Exxeta.

Some key takeaways/thoughts from Tina's point of view:

1. Always start from your value chain - how do you actually generate value from data work? Any process or other tool you attempt to leverage that isn't focused on improving your data value chains will likely be ineffective in generating value. And why do data work if not to generate value?
2. Your two most likely reasons you are losing value in your value chain are lack of clear ownership/responsibility and bottlenecks. Look to regularly assess both.
3. When measuring if things are good enough, generally the DORA KPIs are good measures of data process maturity. But also look at two aspects: A) how happy are people (from customers, decision takers up to the team) with the current process. Satisfaction is a great measuring stick because it is highly correlated to effectiveness. And B) how much effectiveness is lost to bottlenecks and constraints.
4. The two ways most data mesh implementations seem to be going wrong are a misinterpretation of Team Topologies and lack of teams owning responsibilities. On the first, there are often breakdowns in how teams collaborate together and on the second, we need the platform team to own enabling domains but the domains keep trying to push work back to the central platform team.
5. It's important to regularly assess if aspects of your data transformation are good enough for now. But it's also very important - and easy to lose sight of - how are your teams feeling during the transformation. If you significantly improve capabilities but everyone is miserable, will they leverage those new capabilities? Scott note: interesting perspective and it factors into the rate of transformative change: constant seismic shifts are probably not great for morale.
6. In data mesh, you should consider rotating your data engineers between domains so you can have a larger group of data capable people that truly understand domain challenges. Scott note: we have to still make sure we give embedded data engineers a career trajectory or they will leave.
7. Many domains will truly not understand what data ownership really entails. Work with them and embed highly data fluent people that can raise the domain's capability and understanding of data ownership.
8. !Controversial!: Just having a simply community or guild for your data engineers and having them become part of the domain is not enough. There should be a central organizational home for data engineers and you should embed them into domains but the central team should handle their career trajectory.
9. Team Topologies is very helpful in data mesh but if you don't understand your actual value chain, it won't work well. You need to start from how you generate value.
10. When considering if data mesh is right for an organization, if the organization doesn't have a clear vision of what would be better if they had better data capabilities, that's a major red flag. Do they understand how data can drive value for the organization specifically? Would data mesh align to their business strategy?
11. Clarity - getting deep into how things actually interconnect - is crucial to doing a large scale transformation like data mesh right. Too often, things are left up to vague interpretation and balls get dropped. Drive to specifics.
12. ?Controversial?: Overcommunicate. Set literal mandatory information exchange mechanisms - e.g. at the person-to-person level in workshops - between domains. Get explicit that domains need to be regularly exchanging information, not just the 1s and 0s of data. Scott note: this is an emerging pattern from teams who have cleaned up problem data mesh implementations. It seems like it really works.
13. ?Controversial?: When trying to change your data processes, confusion is actually a positive sign. It indicates people are listening and trying to figure it out. If everyone thinks they understand all the changes without any confusion, they probably have wrong implicit assumptions. Scott note: human communication is silly sometimes but this is an excellent point.
14. While it can be hard to exactly measure the value of data, you should always be asking what is the purpose of the data or data work. What value does this provide, why are we doing this work?

Tina started with some of the big questions you will need to consistently ask yourself in a data transformation: is this good enough? Is this good enough for now? What is changing and how is it changing? What are the milestones we want to hit and, looking back, that we have hit? And often overlooked: how is/was the team feeling during the transformation? Those questions can help you narrow in on how well your transformation is going - and let's face it, data transformation doesn't stop. A good three layer system to think about when breaking this conversation down is: the surface layer of what happened in the past and where things are now; one layer deeper is where could they go if they had stronger data capabilities; and the bottom layer being okay, but how can we get there?

When actually measuring whether a current solution is "good enough", Tina recommends two measures or questions to consider. The first is: how happy are people with the current process? Happiness is a decent measure of effectiveness. If people are happy, working hard to improve the process probably doesn't make financial sense, the return isn't there. The other aspect is to think about how much effectiveness of the process is lost to constraints and bottlenecks. This analysis will give you a good insight into the process and provide the perspective on if it is currently good enough.

Tina talked about two ways most data mesh implementations seem to be going wrong. The first is how teams are interacting with each other: the team and domain setup. There are often breakdowns in how teams collaborate together so things that should be explicitly owned and bridged between the teams just keep getting dropped. The other is data ownership where domains won't take data ownership and/or don't understand data ownership. We need the platform team to own enabling domains to leverage the platform but the domains keep trying to push work back to the central platform team or not owning data well enough so the central team has to step in to help. If that happens, the platform team can't get the necessary platform work done to do data mesh and they become that centralized bottleneck again.

In data mesh, Tina believes there is still a lack of understanding by domains of what data ownership means, what they are actually supposed to be responsible for. You can help domains better understand data ownership by making sure they have necessary embedded data engineering talent within the domain to actually be capable of owning data as more domain members learn how to own data. And you need strong governance capabilities to help teams understand how to interoperate data between domains easily.

Tina talked about with one client, they are rotating embedded data engineers between domains - and the central platform team - so the domains become more data capable and you have a wider knowledge base about data across the organization as the data engineers share that knowledge with each other and the organization. And just having a simple community or guild for the data engineers wasn't enough, they needed to go with the embedded model instead. That central hub and a central team managing the data engineers' careers has been very important to keeping people happy.

Similarly, Tina talked about how while Team Topologies is a great tool for organizing your teams in data mesh, it's only a tool. If you don't understand your value chain, if you don't really focus on how you create value via data, it won't save your data mesh implementation. Start from value first.

Is data mesh right for your organization? When Tina is assessing that question for clients, a great starting question is simply what changes, what value would come from doing data mesh? If there isn't a clear vision as to what would be better and how that would drive clear value - and a large amount of value too, data mesh is not a light undertaking - then will data mesh really align with the business strategy and drive value? Scott note: I think these questions are REALLY crucial to answer. If you don't know what will change if you do this well and how that ties to business value, you shouldn't do it :)

For Tina, in general in data work, there are two big areas where value is blocked or lost along the value chain. As she mentioned earlier, lack of clear ownership and responsibility is a big one. People understand how value is generated but it's unclear who owns what and so major needs along the value chain aren't met - basically, no one thinks they own crucial aspects and so they don't get done. The other is again simply bottlenecks - where are things blocked or where are dots not connected? Once you identify issues in either aspect, you should have your areas to target for change to drive more value related to those specific processes.

A key aspect of transformation for Tina is deep clarity. There are so many things that are changing, who owns what and what outcomes do they own? What is actually being done and why? There needs to be strong governance leadership that lays out many aspects rather than leaving things to chance. It doesn't have to be heavy-handed governance but ensuring things will work together - and that someone _owns_ making them work together well - is the best way to ensure a successful data transformation, data mesh or otherwise. And you have to stay on top of things, it's not a one-and-done kind of transformation.

Intentionality around communication is also crucial to successful data transformation for Tina. Overcommunication is a virtue. Data isn't about the 1s and 0s, it's about sharing information. So you need to be explicit in setting expectations and creating mechanisms for people to exchange information, especially across domains. Have regularly scheduled workshops to actually get people exchanging crucial context - it's like a good relationship, you need to continue to work on your communication. Many think about that information exchange at the actual 1s and 0s level but we need people to exchange information with each other constantly too. Otherwise there are too many incorrect implicit assumptions and again, balls get dropped and value is needlessly lost.

Tina made a somewhat comical but very true point: when you are doing a large-scale change to how you do data work, if there isn't anyone saying they are confused, it's probably a bad sign. Because large-scale change is difficult and inherently change will be at least a bit confusing for most so if no one is speaking up, they probably have some bad implicit assumptions you need to address but you don't know what they are. At least with confusion, you can drill into where they don't get it. Lean into confusion because it creates the perfect situation to actually exchange context and drive people to the same page.

While it is incredibly difficult to provide an exact value of data and data work - it will be valued differently by different people - Tina still asks people what is the purpose of doing the work. Why do we care about this data? That will tell us the general value of it if not a specific dollar figure.

Data Mesh Radio is hosted by Scott Hirleman. If you want to connect with Scott, reach out to him on LinkedIn: https://www.linkedin.com/in/scotthirleman/

If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

All music used this episode was found on PixaBay and was created by (including slight edits by Scott Hirleman): Lesfm, MondayHopes, SergeQuadrado, ItsWatR, Lexin_Music, and/or nevesf