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

Get involved with Data Mesh Understanding's free community roundtables and introductions: https://landing.datameshunderstanding.com/

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. Get in touch with Scott on LinkedIn.

Transcript for this episode (link) provided by Starburst. You can download their Data Products for Dummies e-book (info-gated) here and their Data Mesh for Dummies e-book (info gated) here.

Mandeep's LinkedIn: https://www.linkedin.com/in/kaurmandeep80/

In this episode, Scott interviewed Mandeep Kaur, Enterprise Information Architect at Nordea Asset Management. To be clear, she was only representing her own views on the episode.

Nordea has been on their data mesh journey for a while and Mandeep has been trying to figure out best practices for the hundreds - thousands - of micro decisions in a journey. So how do we get comfortable with making so many calls?

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

"1) don't overthink it; 2) bring value out as soon as possible; [and] 3) evolution before completion."
The micro decisions in data mesh do matter, give them some thought. But it's important to simply get some perspective from the people who should know best and move forward. That can be from people inside or outside your organization but think about the blast radius of getting something wrong before you fix it. Most times it's smaller than you'd expect.
Your first question when considering data mesh: what value am I trying to get out of it? Think about what are the target value propositions and what does it do for the business if this is successful. If you don't have good answers, should you do data mesh?
The answers to the 'what value' question of your own mesh journey above should drive your strategy, where you should focus early and what will measure your success. And every organization will have different answers.
?Controversial?: There's a LOT of overthinking in most data mesh implementations 😅 come back to your anchoring points around ownership/accountability, product thinking, value proposition, etc. What's important? You can try something and see if it works and change it if it doesn't, don't get caught in analysis paralysis.
Relatedly, always focus on the value proposition. If you are delivering value, you can improve the other aspects as you move along and learn to do aspects of your journey better.
There's a major challenge in abstract communication, especially about something like data mesh: those doing the abstracting have so much more time and specific research that there will always be logic leaps and things that only map to their own mental model.
Get specific in your data mesh examples and anecdotes while providing abstractions. And be prepared to dive deeper in 1:1 conversations when it makes sense.
The internal communication of something like data mesh shouldn't only fall on the data team. Find/create your ambassadors/champions. They can communicate concepts and aspects well in the language of the business and have mental models closer to their peers.
?Controversial?: As the data team, our role is best served guiding people to the right ways to answer their own questions rather than answering things for them. That's part of data mesh but it's a good practice outside it too.
With data mesh, you will probably feel it's about 'getting it right'. It's as much about learning how to 'get it right' as it is about actually getting it right. That's product thinking for you.
When making your decisions, it's all about trade-offs. Think about what you aren't willing to trade-off. That will guide you more and more to your crucial decisions. Nothing is perfect and nothing is 100% sure.
When making your data mesh journey plan, you must take into account your competency gaps - either to fill them before your journey or how you will compensate for them and fill them as you go along. Scott note: ignore your competency gaps at your own - significant? - risk.
Set milestones for your data mesh journey so you can measure your success to some degree. It also makes you feel better about the progress you've made. Celebrate the success even if there is far to go!
We need to make business users understand data and technology are there to enable them to be better. Too many still see them as a threat.
?Controversial?: Something like data mesh might be seen as threatening to some data consumers by reducing their control and their value creation. Previously, many consumers were in charge of getting access to the data and doing the analysis but that is often pushed to the producer in data mesh. Scott note: this was a really interesting point that hasn't come up before
A product is only a product if it's providing value. Ingrain this into people doing data work.
Really drive to a common understanding of terms like a data product or data as a product. It's very easy for many people across the organization to interpret/understand them differently making communication extra challenging.
Product thinking isn't only focusing on the end product but the supply chain and component parts. That's even more important when that is relating to data; the inputs all matter and the reliability/sustainability of the inputs matter.
Transformation journeys are often quite disjointed at the start. You have to align people to start the transformation and people aren't moving together. There is a disjointed phase before the planning phase 😅 That's normal and to be expected.
If you focus on the target instead of the journey to get to the target, you're as likely to make things worse. You can't simply jump to the end target state, you have to learn how to get there and improve along the way. This is especially true with data mesh.

Mandeep started by discussing one of the key challenges in talking about data mesh: there are so many areas to cover that we often discuss things abstractly. Those abstractions are based on a significant amount of research, discussions, and related work that create a mental model. When we communicate those abstractions, it's hard to communicate the mental model as well. The listeners just aren't as deep into it so much of it goes over their (our) heads. So, we need to get far more specific with anecdotes and examples. We also can't forget the value of 1:1 conversations to drive to deeper understanding. That might not always be the most scalable but it is the best way to prevent misunderstandings. Basically, communication around data mesh is hard! Go talk to people. Scott note: Data Mesh Understanding exists for this reason…

When looking at how to get specific internally with data mesh communication, Mandeep is always on the lookout for her ambassadors or champions. Within a domain, they have strong domain knowledge to connect what you are trying to achieve with data mesh to what the domain is specifically focused on. And they can obviously communicate well in the language of the domain. Connecting the changes data mesh brings to real world problems helps people understand the what and the why.

There is a lot of risk of analysis paralysis in any data mesh implementation according to Mandeep. There are hundreds of 'micro decisions' but if you focus on the core aspects of what you're trying to do, that should guide you to the ones that matter the most. A bit of don't sweat the small stuff. Always come back to the value proposition because you can change things as you learn more. That's not to say be sloppy or careless, there are important aspects like using the right architecture, having strong ownership/accountability, product thinking, etc. But data mesh is as much about learning to get it right as getting it right. And always return to your trade-offs. What aren't you willing to trade-off and why? Once you answer that, more and more solutions become tenable and you can weigh the pros and cons.

Mandeep started to dig into the crucial first question to a data mesh implementation: what is the value you hope to get out of it? And there are different answers for each organization. Those answers will start to inform where you should focus and when in your mesh journey. That will help you set your plan because "a target without a plan is just a dream". And when you form your data mesh plan, think about what you have to adapt to your organization and why. This is not a copy/paste approach! You almost certainly will have competency gaps so how do you plan to fill those gaps and make progress while doing that? Or do you have to fill those gaps before starting the journey because they are journey blockers? Really consider the journey, not only the target outcome. Relatedly, set some milestones for your journey to help you measure your progress and celebrate the progress you've made. They might not be the best success measures once you're further along in your journey but that's okay, you can adjust. That's product thinking.

Mandeep wanted to stress three quick points: "1) don't overthink it. 2) bring value out as soon as possible. 3) evolution before completion."

Many business users still see technology as a threat rather than an enabler in Mandeep's view. They aren't even thinking about data yet, they are still on just tech 😅So there is a lot of work in communication to get them to see data as a major innovation enabler, something to drive their part of the business to new heights.

Another interesting aspect Mandeep talked about was that self-serve might actually be seen as threatening to data consumers. Previously, they controlled - to some degree - their own ability to get access to data but now, it's on the producing team and consumers only get what producers are willing to share. The consumers created the business value by doing the analysis and transformation and now that is pushed much more onto the data producers. Will consumers feel their power and importance is diminished? If the value of data work is attributed to the producers, will data fluent consumers still lean in to leveraging data as much as they did previously?

Mandeep returned to product thinking and her view that a product is only a product if it's providing value. You start from the value you are trying to deliver and work backwards. Build your KPIs around actually delivering value instead of simply creating data products with the hope they create value.

When thinking about data as a product, Mandeep encourages everyone to have conversations about it in their organization and what it will actually mean and look like in their specific organization. Because it's easy to assume everyone is on the same page when they really aren't. And that confusion will bite you in the end with more friction than clearing it up early.

Mandeep believes that in a transformation journey, it almost always starts as somewhat disjointed - a disruptive phase before the planning phase. Part of going on a journey is preparing for that journey. Once people are aligned, that is when you can really start all heading forward. You need pioneers or leaders, those front runners to show people it's safe. But it will still take some time before that alignment. Don't get concerned when that happens even if it feels like everyone should align after the first presentation 😅

Learn more about Data Mesh Understanding: https://datameshunderstanding.com/about

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

201 | Always Be Ready To Hire