Data Mesh Radio

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 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.

Amy's LinkedIn: https://www.linkedin.com/in/amy-tang-edwards/

In this episode, Scott interviewed Amy Edwards, Formerly Director of Analytics and Product at Vista. To be clear, she was only representing her own views on the episode.

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

1. A potential Northstar metric for how data driven you are: how often are people getting, interpreting, and actioning on the data themselves versus waiting for an analyst to tell them? Hard to measure but it's where you want to head, where more and more people are making the effort to interact with data.
2. If you want a data product/use case to succeed, the absolute most important thing is an engaged consumer stakeholder - someone who really, really wants the data for a use case and how they want it. If someone isn't leaning in, consider not building something for them. Scott note: this sounds controversial but it is reinforced in almost every data mesh conversation I have.
3. Similarly, if you are building a data product, you should make sure you are very aligned with your stakeholder. Don't be a request dumping ground, build iteratively together.
4. To understand your progress towards being data driven, you need to actually measure things to track changes over time, your progress. You almost certainly will not find the perfect aspects to measure at first and what you measure will evolve. But it starts with measuring something.
5. There's nothing wrong with starting with a using a success metric that you know isn't going to be something you focus on when a data product matures. As products go through phases, so too should your measurement. So start with number of users as a key early data product success metric - it's easy and somewhat correlated to value driven.
6. ?Controversial?: The adoption curve to not just data mesh but each incremental data product is steeper than you expect. Try to get more people using each data product more so incremental use cases emerge. That will mean you need to do more hand-holding than you likely expect.
7. ?Controversial?: Because that adoption curve is hard, especially across data products, your data team or data product owners might need to do more connective tissue work with other data products to enable people to more easily consume across domains. Always look to drive more and deeper engagement to create a more data-driven culture.
8. ?Controversial?: When thinking about interconnectivity between data products, do you have the consumers create their own bridges or do you pull some of the data from one product into another? Will that create dupl...

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 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.

Paul's LinkedIn: https://www.linkedin.com/in/paul-cavacas-32a36158/

In this episode, Scott interviewed Paul Cavacas, Senior Manager of Data and Analytics at Ocean Spray.

Quick note before jumping in: Ocean Spray is just at the beginning of their journey - in their pre-implementation phase - and there hasn't been a lot of resistance yet internally. That might make a few people jealous 😅 but there's a lot of interesting things Paul is doing to ensure that they are ready to decentralize what makes sense to decentralize at the right time. There is a lot to be gained from not rushing in. Also, apologies that Scott's audio is a bit weird, he had yet to build his makeshift sound studio in the Netherlands.

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

1. As many have stated, asking the data team - especially one person - to become an expert on many different areas of the business just to complete data work for a project just won't scale. At best it creates incredibly concentrated tribal knowledge. Use this point to drive buy-in for decentralizing data ownership.
2. Having someone who really knows your internal IT application landscape well can really help in choosing which initial teams to start with for a data mesh implementation. That person already has good relationships and a deep understanding of your operational plane so you can pick good problem areas and partners.
3. Similarly, build your early buy-in momentum with people that are more likely to be excited to participate in a data mesh implementation. You don't need to convince the most difficult teams to participate at the start.
4. Central ownership isn't necessarily bad until things stop scaling. Having that central ownership means less flexibility and agility to react quickly to market changes or opportunities but also less cognitive load on teams. It's a trade-off.
5. Many of your domains really won't understand data ownership. Find ways to slowly transition them into understanding what ownership entails e.g. starting with documentation and SLOs. What data are they sharing and why does it matter? This isn't going to happen overnight.
6. If you aren't building overly complex data products, look to find people within the domain that are somewhat technically savvy - especially if they want to advance their careers - and start to prepare them for data ownership. Those might be your data product developers or data product managers. Scott note: Brian McMillan talked about a plan to do that in episode #26.
7. ?Controversial?: Even if you aren't looking to move fast with your data mesh implementation, lo...

Key Points:

• We need API-first technologies in data. Not just offering APIs but being able to integrate seamlessly with each other via API. We have that in software but it's been a long-time coming in data. If we want an actual modern data stack, we need to have tooling providers make a real change.
• Simple made easy: we need to make things simple for data product development and consumption. It's not simplistic but it removes unnecessary complexities.
• Overall, there is such a trend in data where people aren't building things that remove toil - there is this assumption of increasing complexity of use cases but so much of the work is not that complicated. We need to make it so most people can do most of the work relatively easily without making it overly simplistic - easier said than done of course.

Sponsored by NextData, Zhamak's company that is helping ease data product creation.

For more great content from Zhamak, check out her book on data mesh, a book she collaborated on, her LinkedIn, and her Twitter.

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

Data Mesh Radio 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.

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

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

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.

Stephen's LinkedIn: https://www.linkedin.com/in/galsworthy/

In this episode, Scott interviewed Stephen Galsworthy, former Head of Data at TomTom. Obviously, given he's no longer with the company, he was only representing his own views.

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

1. Just because the products you sell are made from data, that doesn't mean you necessarily have a good process for leveraging data to make your products better. You need to embed information collection into how you create products, how customers interact with your offerings.
2. The AI Flywheel: If you can get good information on product user experience, you can feed that into AI systems that generate incremental insights to improve your user experience even more. Hopefully, that generates more users which generate even more information to improve even further.
3. If data collection on usage is not part of your business model - for a number of reasons - it can be hard to convince customers and/or partners to enable that data collection. Even if it's simply to improve the user experience. Try to add it in to your product development as early as possible.
4. If your organization is data hesitant, look for existing success stories from data. Look for something that couldn't have happened without the data. And then share that success internally to drum up more interest.
5. ?Controversial?: Data should rarely be THE deciding factor. Data should be a touch point that can strongly inform or give clarity. Use it for giving clarity or measuring as you iterate. Help execs understand it's not magic and that it's not all right or wrong.
6. It's easy to trust data when it confirms your intuition. How do you use it when it doesn't? How much credence should you give the data?
7. ?Controversial?: High performing companies tend to be those that use data to help make adjustments to their product strategy, using it as a tight feedback loop. It's not as though the data decides but it constantly informs and confirms (but yes, not absolute confirmation).
8. Don't fall into the trap of collecting all the data you can. But do think about what you could do if you had additional data, what might that inform. Work ahead, you don't get past data the day you implement.
9. There is a big difference between producing data and producing data as a product. But if we don't incentivize and assist teams to produce data as a product, few will and then your data practices will remain fragile.
10. Data producers need to be able to understand who has taken a dependency on their data but it's too hard in general right now for them to understand. Better technology offerings here can help.