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. Alexandra's LinkedIn: https://www.linkedin.com/in/dralexdiem/ In this episode, Scott interviewed Alexandra Diem, PhD, Head of Cloud Analytics and MLOps at Norwegian insurance company Gjensidige. Gjensidige's approach closely aligns with data mesh but they are starting with a focus on consumer-aligned data products as they have a well-functioning data warehouse and are not looking to replace what isn't broken. Some key takeaways/thoughts from Alexandra's point of view: Advice to past data mesh self: stop talking to people about data mesh, talk to the changes in the way of working. It can be very tiresome to try to explain data mesh instead of those changes. Data mesh isn't the point.There aren't really any reasons we can't apply many software engineering best practices to data, it's simply we haven't done it broadly in the data world.There is a push and pull between software best practices and data understanding. Consider which you see as more important and when. Do you bring data understanding to software engineers or software best practices to those with data understanding.When you leverage pair programming between enablement software engineers and data analysts that understand the domain, the software engineers learn more about data and the domain and the analysts learn good software engineering/product practices. It's a win-win.The people you enable to do work in a data mesh way should serve as ambassadors of your ways of working, especially within the domain. Both helping others learn and as champions. That provides organizational scale. You can't individually enable every person in a large company."Too many cooks spoil the broth." Think about having that 'two pizza team' kind of approach so you have concentrated understanding by those involved in creating data products who then can again help others learn. This is good for those in the domain and also for an enablement team bringing learnings back to a platform team.Having a team with intimate knowledge of what data products/data product features have...