#102 Share Data by Default and Other Stories/Advice from Leboncoin's Data Mesh Journey So Far - Interview w/ Stéphanie Bergamo and Simon Maurin

Data Mesh Radio - A podcast by Data as a Product Podcast Network - Mondays

Categories:

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 hereEpisode 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 hereStéphanie BergamoLinkedIn: https://www.linkedin.com/in/st%C3%A9phanie-baltus/Twitter: @steph_baltus / https://twitter.com/steph_baltusSimon MaurinLinkedIn: https://www.linkedin.com/in/simon-maurin-369471b8/Twitter: @MaurinSimon / https://twitter.com/MaurinSimonIn this episode, Scott interviewed Stéphanie Bergamo and Simon Maurin of Leboncoin. Stéphanie is a Lead Data Engineer and Simon is a Lead Architect at Leboncoin. From here on, S&S will refer to Stéphanie and Simon.Some key takeaways/thoughts from Stéphanie and Simon's point of view:"Bet on curious people", "just have people talk to each other", and "lower the cognitive costs of using the tooling" - if you can do that, you'll raise your chance of success with your data mesh implementation.Leboncoin requires teams to share information on the enterprise service bus that might not be directly useful to the originating domain on the operational plane. They are using a similar approach with data for data mesh - sharing information that might not be useful directly to the originating domain by default.Leboncoin presses teams to get data requests to other teams early so they can prioritize it. There isn't an expectation of producing new data very quickly after a new request, which is probably a healthy approach to data work/collaboration.Embedding a data engineer into a domain doesn't make everything easy, it's not magic. Software engineers will still need a lot of training and help to really understand data engineering practices. Tooling and frameworks can only go so far. Be prepared for friction.Similarly, getting data engineers to realize that data engineering is just software engineering but for data - and to actually treat it as such - might be even harder.Software engineers generally don't know how to write good tests relative to data. Neither do data engineers. But testing is...