Data Mesh Radio

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 here. You can download their Data Mesh for Dummies e-book (info gated) here.Salim's LinkedIn: https://www.linkedin.com/in/salim-syed-11981521/Capital One Software: https://www.capitalone.com/software/Capital One Slingshot: https://www.capitalone.com/software/solutions/Capital One blog post on their use of Snowflake for data mesh: https://www.capitalone.com/software/blog/operationalizing-data-mesh/In this episode, Scott interviewed Salim Syed, VP of Engineering at Capital One Software.Some key takeaways/thoughts from Salim's point of view:!Contrarian!: "Data mesh works with central policy, central tooling, but federated ownership." Work to federate your infrastructure ownership, not just data ownership.No matter what size of domain or LoB, look to have the same responsibilities owned by each domain. They may fall under different people but the role they serve should look the same across the domains.Get your roles and responsibilities established first, then look to start tackling other challenges.Do your best to hide the data engineering complexity from your self-serve platform users. Help them do their job, not learn data engineering. Focus on creating a great experience for them in their workflows.Think about data risk from an opportunity standpoint: if you have strong risk controls, you can feel more comfortable giving more people wider access - you know what is allowed so you can potentially give them access to more data than if you didn't have tight controls.Doing federated anything right isn't about just giving people the tools/patterns/policies, you should focus on a usability layer. Should every team have to integrate and manage their data tools or should they be able to focus on doing what matters? What is their experience?Design your data platform to your personas - who's getting something done and how do they do their work? Also, always ensure your infrastructure and your governance are in sync. No one likes to manually update the data catalog or even worse when it drifts.Discoverable data doesn't have to mean everyone can access everything by default or that access is automatically granted. If people can find data and understand what the data is about plus then easily request access, that is enough. Also make granting access as painless and low risk as possible.Look at users' most common actions that cause major friction and focus on tackling those, whether they 'feel like part of a data platform' or not. For Capital One a few were reviewing/monitoring risk and supporting manual updates of production data.Cost controls are a crucial but often overlooked or ignored aspect of your governance - it's VERY easy to overspend in the cloud :)!Commercial Offering!: Capital One launched Capital One Software and its first product, Slingshot, after seeing how difficult it was to properly manage costs around data mesh, especially given the separation of storage and compute with Snowflake. Lines of business don't typically have cloud cost managers so they wanted to automate the controls and cost tracking/management/forecasting as much as possible.Don't make people in the business learn exactly how to tune to prevent or rectify cost inefficiencies. Again, back to experience, give them knobs and the right questions to assess their needs so they don't have to be an expert.Cloud bill surprises are so common, it's a meme. Build out tooling to help people forecast their cost and then track and alert against it. Slingshot helps Capital One teams forecast and control data costs. Don't wait until the end of the month to let someone know they went 50% over budget.?Contrarian?: Your central team will likely be reluctant to give up some authority, especially in deciding how infrastructure is deployed. Look to retrain central teams to build self-service capabilities that create the guardrails to give them comfort but still federate infrastructure ownership to the lines of business.Capital One is on its own data mesh journey and what they learned and built internally inspired them to build an offering called Slingshot. When asked about where he would tell others to start their own data mesh journey, Salim mentioned that we can't solve our data issues - whether data mesh or anything else - through just technology. At Capital One, they started on the organizational aspects, breaking into discrete lines of business (LoB) and then creating units of data responsibility with a hierarchy. However, the data hierarchy wasn't the same in each, they left it up to LoB to determine - a large domain having 3-4 and a small domain having 1.According to Salim, a big reason why they have so many people focused on risk is similar to what Sarita Bakst mentioned in episode 52: you want to give people as much access to data as you can while minimizing risk. So set yourself up to give people access when it's valuable / necessary for their job. There are even instances at Capital One where you need to complete training to get access to data. And they have active risk monitoring constantly in place as well to make sure they don't miss anything. Again, doing that gives you more piece of mind to leverage more data.When you start federating your data ownership, you can't only give people the tooling and the authority, that won't work well in Salim's view. So, in addition to all of that, you need to focus on a usability layer. Think about email - it's pretty easy to work with an email client but what if you had to put all the plumbing and add your headers and all that yourself. Just giving people tools, patterns, policies, etc. and expecting them to be able to handle it all isn't realistic, make it easy to leverage, think about their user experience.As an example, Salim talked about the process for creating a data product. Instead of interfacing directly with 6+ tools, there is a workflow with automated processes to make it a smooth process. As many past guests have noted, reducing friction to sharing data is a key element of driving value from data mesh. It's not just called a data platform, it's called a self-serve data platform for a reason :)Salim shared some advice other recent guests have touched on: really focus on the job to be done, who is doing it, and ensuring your infrastructure and governance stay in sync. Focus on the job to be done, whatever that job is, instead of the tools. Again, reduce friction. Focusing on the persona of who is doing the work is also crucial - Audun Fauchald Strand and Gøran Berntsen from NAV in episode 37 talked about building a great data platform no software engineer would want to use. Use product thinking, who is using it and how do they typically do their work? And lastly, ensuring your governance and infrastructure stay in sync - if there is an update to the data product, does that automatically update the data catalog? How do you prevent drift between systems or kludgy manual fixes?Data discovery done right is about a few things according to Salim. Ensure people can find relevant data easily is baseline but also get them to as much understanding as possible. Even sensitive data, what are the quality metrics, the general data shape, etc.? And make it easy to immediately request access when you find data you want to use which immediately triggers a request to the data owner with a business justification. And the relevant policies for that data product are automatically part of the approval process so the data owner doesn't have to remember the policies themselves. Again, reduce friction to getting the job done for all parties.Salim talked about a few things they overlooked at the start, one for personas and one that was causing a lot of friction. As mentioned earlier, at Capital One there are a number of risk managers but the early iterations of the platform didn't cater to their experience. Which meant access requests were delayed and risk monitoring was tougher to do. So make sure to consider all your personas that will be using your data mesh - ignore at your business value peril. The other aspect was how much manual effort was involved in patching production data so they addressed that as well.To be able to federate the actual infrastructure management to the domains, Salim and team knew they couldn't just hand over the tools. Again, the personas in the LoBs wouldn't have the expertise to manage the infrastructure. So they focused on exactly what Salim mentioned throughout: the experience. How could they empower the lines of business to own their data infrastructure without the domains having to manage their data infrastructure? So the team built out a platform with capabilities with experience at the core but with additional aspects like DBA best practices, guardrails, and cost management as part of the platform. Scott Note: from here forward, there will be some discussion of Capital One's Slingshot offering. This is not an endorsement of the product at all but it is interesting and germane to the conversation (read: Salim was not selling, only telling, which is a-okay on the podcast). Cloud cost is near and dear to my heart and it's important - whether you build or buy - to not overlook cost management.So, all these challenges of how they addressed their cloud cost management via their platform led them to believe there was a market for this type of solution per Salim. Capital One has a history of creating cloud cost tooling as they were the creators of Cloud Custodian (https://cloudcustodian.io/). Scott Note: unpredictable and/or high costs have been a major concern/pushback to data mesh since early 2021.One general issue with on-demand / cloud computing is cost inefficiencies. There is always a lot of waste and it's often actually more cost effective to ignore than chase it down unless you know where inefficiencies lie. So Salim and team found it useful to not try to automatically clean up cost inefficiencies - that pretty much never works - but to highlight them relatively quickly and offer potential recommendations and/or help. And they lowered their own Snowflake costs quite a bit in the process.The bigger benefit according to Salim was the team put proactive questions in place for when teams were provisioning their data infrastructure. Often, it can only take a few minutes to save a large percentage of money if only people know the knobs to turn. But you don't want everyone to have to be an expert - extract the information from them based on their needs and create a recommendation system. This is just yet more on the experience side - don't build cloud cost experts in every LoB, make it so they can make the right decisions as often as possible quickly and easily. You should also look to build in cost forecasting tools as part of your experience so people aren't hit with a surprise bill - the surprise Cloud bill is so common, it's a meme on Twitter.From what Salim is seeing, most companies - or more correctly, central data/platform teams - are pretty reluctant to federate ownership of the infrastructure to domains. He believes that is because of things the LoBs don't understand like cost controls and best practices but that if you allow the central team to set guardrails and best practices, they will be more willing to give up control. Remains to be seen.Salim finished with "in our experience, data mesh works with central policy, central tooling, but federated ownership."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 hereAll 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 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.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 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 here. You can download their Data Mesh for Dummies e-book (info gated) here.Amy's LinkedIn: https://www.linkedin.com/in/amy-raygada/In this episode, Scott interviewed Amy Raygada, Senior Director and Analytics Product Manager at Swiss Marketplace Group (SMG).Some key takeaways/thoughts from Amy's point of view:When signing up to do data mesh, you won't exactly know what you are signing up for - it will be different than your expectations in a number of ways so be prepared to be flexible. And it's a marathon, not a sprint. Have patience, you don't need to get it perfect on day one.It's crucial to have a data product owner, someone who can ask the uncomfortable questions and make sure you are actually treating your data as a product. It's easy to get lost in focusing on the technical but that's not what drives the business value.Look to start with a reasonable scope use case instead of a massive challenge. Make it so the teams can learn and iterate because you aren't solving the hardest challenges - yet.Consider starting with a single domain and with a key consumer being that same producing domain. As they learn more about owning data and see value from owning their data, they will be better able to serve other teams too.Spend the necessary time ideating and brain storming before beginning your journey. You want everyone to be working together so a clear initial vision - at least for first steps - is key. But keep updating your prioritizations as you learn more.Data mesh requires major changes for organizations. People aren't good with very abrupt changes so look for the incremental changes where viable. It's okay to take a bit longer if you maintain people's happiness instead of trying to rush to the finish and burn everyone out.Domains need help getting to data capable, being able to own their own data. You can't just shove ownership on them, you have to onboard them, help them understand how to work with data. You will definitely need to "babysit" them as they learn and that's expected and okay.You will probably communicate more than you expect even though everyone tells you to expect this :) pair well and make sure people understand what is to be done and why it's crucial.It might be hard at first but a central data team should be focused on enabling domains to own their data. There might be some desire to do the work for them but then you end up with central data ownership again.Data contracts are relatively easy to understand conceptually and give a scope to what data owners must adhere to instead of something like "give me high quality data". And the data owners can set better boundaries/SLAs or push back on requirements more easily.When working with a domain, make sure they understand the reason you are asking them to take on new types of work - what's the outcome? Show them what happens when they break a data contract so they can understand the impact. And build a good relationship so you can use them as your internal success story too.Make schema contract validation - before deploying changes - as simple as possible so software engineers can check if changes will break data contracts. If yes and the change is necessary, then set a versioning strategy for that data product.If you set teams up to understand the why of data mesh first, then what changes for them, it leads to a much easier conversation. Talk about what is the current state and why that's not where you want to be.Leverage your first movers to be your advocates. Once you have one success story, pair with them to bring other people on board. The water is fine, jump in!If a producing domain - or stakeholders in the domain - is hesitant to engage on something like data mesh, work with them to show initial value. Once they see it has a benefit and isn't some monumental task - and that you are there to help - they are much more willing to participate.Look to cross bridges when you come to them. Obviously plan ahead but don't get too wrapped up in what might happen.Amy started by talking about something many other guests have probably felt but few have said: when signing up to do data mesh, you won't really know for sure what it will be. And that's okay, your journey will take you places you didn't expect and have hurdles and obstacles you can't see or predict. But that's all okay, you can learn and iterate along the way. Expect the unexpected.When Amy started interviewing at SMG, the team was not as familiar with data mesh. But for the past six months it's been a key part of her focus. She paired up with the head of data engineering and worked to brainstorm before moving forward - that pre-work lasted about 2-3 months. There was also a lot of other change happening in the general technology and data landscape at SMG - moving from on-prem to cloud, moving from monolith to microservices, moving off legacy technology, etc. - but that meant they were able to get everyone together for a 2 day workshop and really look at things from a fresh perspective. At the same point, people are not used to abrupt changes and with data mesh, there will be a LOT of changes - look to implement that over time, don't be in a rush.SMG decided to start with a single domain - leads - instead of multiple domains. The initial use cases were useful for the leads domain as well, especially by significantly improving data quality. As part of enabling that domain, Amy and team are working closely with them to teach how to handle data, what data ownership actually means.The leads domain was chosen because they had a significant need for help with data quality and had moved more to cloud and microservices than other domains. It was also a smaller, more manageable problem than say sales, which is in a major transition to Salesforce. They had three non-mesh data products that were impacted from poor leads data quality so there was a lot of downstream issues that they could address, a lot of incremental business value to drive by fixing the data quality issue. The other domains they considered were in big transitions so it would be harder to get where was necessary to drive value in a PoC with a lot more work and risk.Data contracts have been a key goal and key driver for Amy and team. The goal is to better define what you are trying to do with data, what do you as a data owner need to actually do and deliver and what can the data consumer expect. The driver aspect is that data owners have something more concrete so they are willing because they only have to deliver what they say they will. It gives a limited scope to their data work.A focus for Amy and team is to be the enablers only, building out the platform and teaching people how to own but not do/own as central data ownership was causing issues in the first place - it's what data mesh specifically moves us away from. The domain teams will certainly need "babysitting" but that is expected and can mean more information flowing to the platform team to make improvements too. Data ownership isn't a one or a zero, it's a process.Amy believes it's important to really pair with domains to share the logic with them behind data mesh - why are we doing this change - and not make it feel like you are changing their ways of working instead of adding new, value-add capabilities to the domain. This close relationship has allowed them to do a data contract demo where you can show the domain what happens when they make a change that will violate their contract. That way, they understand what happens to downstream consumers - possibly themselves - when they make a breaking change. And that the platform alerts them to a breaking change too so they have a better chance of preventing issues themselves.Similar to what Chris Riccomini mentioned in episode 51, Amy and team are implementing automated schema validation checking at the pull request level. This prevents breaking changes from going through with consumers being the first to know about an issue. It also kicks off a conversation about should this change be made and if so, how will they do versioning. And Amy knows this can overwhelm some people but the team she is working with understands the pain so they are eager to prevent that pain. They are also looking at data reviews - similar to architecture reviews - to assess if operational system changes will impact the data. Abhi Sivasailam in episode 9 mentioned they are doing a similar process.Amy believes - and Scott agrees - patience is crucial. Getting the first domain into a really good spot and then enabling them to share their story and their learnings will be crucial when they try to go to additional domains. Not being in a massive hurry means teams have the time and space to learn how to own data instead of piling a huge additional workload on top of an overburdened team. Educating the general company about what they are doing with data mesh has gone well. Amy created a Miro board using Barr Moses' old joke of data mess to data mesh. So they are working to explain the what and the why to everyone involved but in a simplified way. Talk about what changes - the new responsibilities and what those mean and drive. Talk about how you can bring everyone to the table and especially what benefits data mesh has for them. Really focus on the practical of what are they being asked to do and why.While many stakeholders in their initial domain were anxious to engage at first, now that there is proven value, according to Amy those hesitant stakeholders are much more willing to pair up. They are providing test cases to the data team so they can quickly validate value and iterate together. They are already seeing the benefit of the work with other stakeholders and it's getting those previously hesitant stakeholders excited to team up. So if you want buy-in, look to provide some value first and then show/prove that value. Yes, easier said than done.Quick tidbits:Make sure to team up with any domains that have had success so they can help you sell other domains on working with you. They can help educate and also show that you are actually providing the business value you claim.It's super easy to get bogged down by metrics. Push back on big metrics requests - why do you actually need this? As Alla Hale mentioned in episode 122: "What would having this unlock for you?" If it doesn't unlock value, why do it?Having prioritization meetings weekly keeps everyone on the same page, heading in the same direction.It's easy to get wrapped up in what might happen. Focus more on what's in front of you and what you are trying to do. Don't cross bridges before you come to them :) there are countless bridges in data mesh, focus more on the now.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 hereAll 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/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.What do we need to develop to provide a better experience for data product developers and consumers? How can we make it easy for consumers to move from discover to trust to lean to use? We still have a long long way to go with analytical APIs, they are basically only for sharing raw data at the moment - how can we better share the embedded information? And how can we give data product developers the ability to do the right thing by default where we optimize for ease of use and also for more generalist developers to use - instead of hyper-specialized tools experts? There have been two very separate universes of operational and analytical planes - how do we change that and leverage software engineering practices in analytics?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 hereData 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 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 here. You can download their Data Mesh for Dummies e-book (info gated) here.Alice's LinkedIn: https://www.linkedin.com/in/aliceparker/No Silver Bullet: Essence and Accident in Software Engineering by Fred Brooks: https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet.htmlIBM Research paper mentioned: https://dl.acm.org/doi/10.1145/3290605.3300356Microsoft Research paper mentioned: https://dl.acm.org/doi/10.1145/2884781.2884783In this episode, Scott interviewed Alice Parker, Data Engineer at DNB.Some key takeaways/thoughts from Alice's point of view:It's easy for people to confuse user experience (UX) and user interface (UI). But UX is far deeper than most understand. We need to design systems and experiences that make working with data - as a producer or a consumer - far easier and more delightful.People are very willing to talk about their challenges - show some empathy and give them the space to talk about what is holding them back and what they could do if you worked with them to address those challenges.Data consumers need three major things to work well with data: 1) domain expertise, 2) time, and 3) to be able to "converse" with their data.Ensure your data quanta - or really any aspect of your data mesh implementation - are documented for all your user personas. There may be different needs for each persona type. A data scientist probably doesn't need as detailed of explanation of lineage if they can see the transformations compared to a business analyst.As part of designing our UX, we need to focus on "how to help users achieve their goals effectively, efficiently, and with satisfaction, how you can minimize risks, and how you can enhance the maintenance of tasks to be completed effectively."To get UX right, you have to understand "the limitations of the humans using it." Because you have to design your experience and your risk tolerances around those limitations."Systems and technologies evolve incredibly quickly, but unfortunately, humans don't." Have empathy for that. The human brain’s processing power does not evolve at the same exponential rate as Moore’s Law, so take into account the limitations of cognitive load.It's easy to fall into the trap of building one-size-fits-all experiences. But in data mesh, especially as we raise people's data literacy, their data capabilities, we need to make sure we understand persona needs and desires so we can design for them.Interviews are crucial to understand what your personas actually need. Speak with them, reflect back their pain, understand what they are trying to accomplish, and then work to build something that addresses their needs without being tied to any one use case, domain, or person.Your user experience will change and - hopefully - improve. Communicate with your users what you are doing and why, bring them in to the conversation. It's important that they understand you don't have a magic wand but you do have a sympathetic ear :)Prioritization is key to delivering on an improving user experience in data mesh. There will always be a deluge of requests, figure out what are actual requirements instead of nice-to-haves and then assess your capability to deliver and the cost/benefit of delivering. Then communicate your prioritization.Alice started by talking about her recent Master's thesis which was studying human computer interaction, specifically around data mesh at DNB. And it's a huge topic. To start though, she emphasized the difference between user experience (UX) and user interface (UI). Your experience is impacted by much more than just the visual buttons you click - or knobs and levers you move if on a more industrial setup - so user experience is much deeper than many think. Zhamak has mentioned user experience - in multiple contexts - as a crucial factor in getting data mesh right. It's a rarely explored topic in data, especially designing your architecture to provide a better experience for data producers and consumers.According to Alice, there is even an ISO standard focused on experience. It's about "how to help users achieve their goals effectively, efficiently, and with satisfaction, how you can minimize risks, and how you can enhance the maintenance of tasks to be completed effectively." And breaking that down into each piece can be a pretty deep conversation. How do we ensure satisfaction of data users? What is risk when it comes to data? Risk of interpretation? Misuse? A crucial aspect of UX is understanding the capabilities and limitations of the people using it.As Alice noted, "systems and technologies evolve incredibly quickly, but unfortunately, humans don't." And we can't think of every person as being the same with the same needs and capabilities. Which unfortunately means, one size will not fit all when thinking about building your platforms for data mesh. We have to design to serve persona needs. And to actually understand persona needs, we need to speak with them.When listing out the different personas, just on the data consumer side Alice mentioned data analysts, data engineers, data scientists, data stewards, and business owners. On the producer side you have data engineers, data scientists, software engineers, and business owners. Then in kind of the in-between, other personas you have platform engineers, data governance people, etc. So you have to think about what each persona needs and then design for each persona. The personas even have different terminology, different ontologies they use. If only this were that easy :)What this all leads to is going and actually talking to your potential users to find their needs - which is what Alice did with interviewing data consumers for her Master's thesis. Similar to what Jen Tedrow mentioned in episode 98, you need to go and listen to their pain points and then abstract away the use cases to see what are the bigger needs. And you can do that in a very informal way too. But you can really only get that feedback through conversation and explicit effort. Scott Note: this is EXTREMELY true… the number of times I've asked for feedback and gotten crickets is… yeah…Alice noted it's important to let people know when their requirements won't be met, or won't be met on their timeline. That open communication will get them to trust you. It's okay to say no to a change to user experience, especially if you have good reason for it that you explicitly communicate to them. You can work with them to maybe find the quick wins that gets them additional value now. Prioritize what can be done now and explain why for your prioritizations.Documentation is one crucial aspect that has been lacking in data according to Alice. Yes, data mesh calls for data quanta to be well documented but we need to ask who are we actually documenting for? If you have 5 different consumer personas for your data product, is it documented so all of them can actually use it? And then how do we make it as easy as possible for data producers to actually create and update that documentation? Does documentation only have to be written? What are some low friction ways to share the context of what a data quantum is all about?It's crucial to think about incremental progress - and showing that incremental progress - on your user experience in Alice's experience. Every system everywhere will have frustrated users. Such is life. And you can't solve most challenges in a day. But look for ways to iterate towards a better UX and circle back and show people you are improving it - if that's data product creation cycle time, show them your prioritizations that sped up that cycle time and show them the improvements, show them you listened and reacted. They might still be grumpy but at least they have reasons to be less so. As other guests have noted, Alice has seen most people are very willing to share about their current challenges. If you go with the right attitude - to listen and empathize - you can learn a ton. People want to feel seen and heard. And it might help more with your prioritization than you'd expect. As Alla Hale said in episode 122: "what would having this unlock for you?"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 hereAll 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 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.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 hereEpisode 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.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 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 here. You can download their Data Mesh for Dummies e-book (info gated) here.Dacil's LinkedIn: https://www.linkedin.com/in/daciluhernandez/In this episode, Scott interviewed Dacil Hernandez, Director of Data and AI for Northwest Europe at Nagarro.Some key takeaways/thoughts from Dacil's point of view:At the end of the day, tech is the easy part in data. Creating value though data is the hard part. And why do data work if not to create value?It's incredibly easy and pretty common for IT and the business to get disconnected - or never be connected in the first place. Focus on creating and maintaining relationships with a steady flow of context between both sides.Dig into if your business partners actually understand what data ownership means, what it entails. They may be willing but not capable to own data at the start. Work with them to up their capabilities and understanding.Data ownership should not be treated like the "hot potato", being passed to "anyone other than me".Tell your business counterparts "I need your help to help you." You can unlock far more value through collaboration than waiting for requests.Your data strategy should give people FOMO - fear of missing out. Give them incentives that makes it feel like they can't miss out on the value you're creating.!Interesting Idea!: use gamification to find data quality issues. Don't make it a shameful thing, find it and get it remediated and celebrate the people who found it. Look to drive positive energy around your data.Talk to potential data consumers before creating a data quantum or anything in data. You won't know what you can offer that will be valuable to them until you know what they want. So have the conversation.Bad requirements and/or bad requests lead to bad results and data. Ask why someone wants work done - what are you trying to accomplish, let's focus on the outcome.It's easy to lose sight that optimizing to turnaround time doesn't typically optimize time to actual value and you create hard-to-support data assets.Dig into what data consumers are trying to achieve and why. Their idea of what they want may not be the most complete or best way to structure the data or insights. Again, have the conversation.When looking at data quality, tie your metrics and measurement to value. What aspects of data quality matter to that use case?Data trust is obviously crucial. Data quality issues will happen. When they do, remediate and put rules in place to prevent that same issue from happening again and show business partners that you fixed the cause. It was a data downtime incident, treat it like a software incident.To achieve actual sustainable change, you don't have to make big, sudden shift changes. You can and should break change into much smaller pieces.Centralized governance might not be your data bottleneck. Or even if it is, if you aren't mature enough to do federation and decentralization right, data mesh might put you in a worse spot. Really consider your challenges and maturity level.Dacil started out by calling herself a purple person, meaning not red or blue, not only technical or only business focused but a combination. As part of that, she echoed many past guests - the tech is the easy part, creating value is the hard bit. It's easy to lose focus on creating value and playing with the cool toys, building really amazing things. But do they create business value?It is crucial to have business counterparts as key partners, key stakeholders, in your data mesh journey according to Dacil. It is so easy for IT and the business side to get disconnected, for use cases and needs to change but the data getting shared doesn't change. And with everyone saying business first, we are still focusing on tech far too often. Dacil likened data practices to being a teenager - we keep hearing business first but don't listen, we do what we want :) And we need to really get crisp on what "business first" actually means.Dacil believes it's crucial to get out of the IT desk request -> data loop we've been stuck in for so long. The business needs to come to the table and we need to bring them to the table. If the business side isn't part of the conversations, you can't get them to understand what data ownership means. They may say they will take on the responsibility but they can't really grasp how to do it well. So we need to partner with them to get what we need and we need to work with them to improve their understanding and their capabilities around data ownership."I need your help to help you" is something core to Dacil's work with the business. Too often, IT is left to wait for requests instead of working together to get what people need. It can unlock a number of additional use cases too.When creating or improving a data strategy, Dacil recommends including incentives that mean people see/feel the need to participate. Leverage a fear of missing out or FOMO. Make sure people understand what will happen and the rules of engagement. Find the incentives to get them to participate by adding value back to them. Of course, easier said than done. Dacil mentioned an interesting idea a company is implementing: using gamification to find data quality issues. So instead of it being this really bad thing to discover data quality issues, the people who found the issue get rewards. So that also will drive better data consumer literacy and drive up trust - they are checking data for "does this make sense" instead of just consuming data and learning in the process. Where else could friendly competition/gamification work in data? Look to create friendly and positive energy around your data work and show how it contributes to company value too.For far too long we've had a vicious and costly cycle of bad requirements and requests leading to bad results and data according to Dacil. So, we need to ask far more questions - why do you really need this. As Alla Hale mentioned in her episode, not in a push back way. She said "what would having this unlock for you?" So take what they are looking for and why and repeat it back to make sure you are on as close to the same page as possible. And then keep communicating while you are building. Drive to that small prototype to make sure you are driving towards value together and aligning on expected outcome.There's a maturity level to differentiating between what people want and what they say they want in Dacil's experience. And it is also often hard to differentiate between what they say they want and what they are trying to achieve. Always dig into what are they trying to achieve or you will create lots of wasted work. Again, have the conversation.It's very easy to measure the wrong thing in data quality according to Dacil. She brought up an example where phone number was 100% complete for every record but most of them were not real numbers. So someone said they had perfect quality based on "there was something in the field" but it was unusable, wrong information. So when you look to data quality measurements, tie to value. What is actually valuable here? If it's operational data plane, that might be speed. If it's mailing address for sending out holiday cards to all your customers, accuracy is probably better than completeness. If a few clients don't get a card, that's probably better than sending out lots to fake addresses. In Dacil's experience, business is typically the first team to notice data quality issues. And that means their trust is broken. Trust is hard to build but much harder to rebuild. How can you be data driven if you don't trust your data? People need to understand that issues will come up but put the rules in place - and show the business - to prevent that same issue from happening again. It was a data downtime incident, treat it just like you would with a software incident.Other tidbits:Data ownership is often like a hot potato, no one wants to catch it. You can't throw that responsibility to the business and expect them to know how to handle it.Talk to potential data consumers before creating a data quantum or anything similar in data. You won't know what you can offer that will be valuable to them until you know what they want. So have the conversation, drill into what is of value and why, then collaborate together to drive to that value.It's easy to lose sight that optimizing to turnaround time doesn't typically optimize time to actual value and you create hard-to-support data assets.Break your changes into much smaller pieces. Big changes are more prone to failure and are harder. Make incremental, small-scale progress.Measure if centralization is actually your challenge before you look at implementing data mesh. If it's not, will data mesh be worth it for you?Really think if you are mature enough to really do federated governance and decentralized data ownership. Centralized governance is a bottleneck but that will likely be far better than chaos if you aren't ready.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 hereAll 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 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.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 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 here. You can download their Data Mesh for Dummies e-book (info gated) here.Alex's LinkedIn: https://www.linkedin.com/in/alex-bross-33853837/In this episode, Scott interviewed Alex Bross, VP of Data Engineering at Fifth Third Bank. To be clear, Alex was only representing his own views on the episode.Some key takeaways/thoughts from Alex's point of view:Start from empathy. Being able to empathize with someone will give you a far better chance of understanding their context. And analytics is really about understanding what the data shows with the applicable context.There are 3 main barriers to change: logic, credibility, and emotion. Don't skip any of them.Microservices can teach us a LOT about how to distribute data, especially from the people angle. When moving from the monolith with single branch development to API-driven microservices, how did people feel? How did we get them to the right place mentally and capability-wise? We should learn from that and leverage it for data mesh.Don't try to do all your disruption at once. And data mesh is a disruption to the status quo. The business has a cadence, look to fit to that as best as possible.When looking where to begin with something like data mesh, look at need and/or desire. Is there a team that is really struggling and needs change? Or is there a team very willing to try it out?It's very difficult to have positive change with a team that is already struggling. If you are going to work with them now, make sure to be there to help instead of demand change.Catalysts lower the amount of energy needed in a chemical equation. Be a catalyst for change - make it less difficult to change. Focus on that and many - most? - domains will welcome you with open arms.Business users are, by and large, much more digital and data literate than historically. With a moderate amount of upskilling, they're able to leverage low code / no code platforms for scalable/repeatable data consumption.If your data consumers can see the value data literacy can unlock for themselves - their careers - and their domains, they will likely be very hungry for training.Failure doesn't have to mean disaster in data any more. With fast feedback loops, you can quickly adjust. Make sure people understand that - perfect is the enemy of good/done.If you do a bootcamp, look for practical applications over theoretical - how can someone take this and apply it to their job, to their domain today? Actually doing something now - while training - makes it more tangible and likely to stick.That practical work can have a positive impact now. Set milestones for trainees around real contributions to real use cases as they learn and gain the skills and confidence to contribute back.From Allen Holub's Death of Agile: Training a team for 2 weeks slows them down for 2 weeks. Not training a team slows them down forever.Starting change discussions around handing over data ownership is a big potential friction point. If you can give people the capability to own their data and the desire to learn and use their new capabilities, the ownership conversation becomes far easier.It's easy to fall into the trap of trying to level up data literacy by hiring. If you want to upskill your people instead, look to the incentives of who might approve a data literacy program and align as best as you can.If you want to get a data bootcamp approved, write a business case for it. People invest in what makes business sense. Make your data bootcamp make more business sense.Alex started the conversation with an important message that often gets lost in data related discussions - let's start from empathy. Almost all people want to help each other and work together. Most will want share their context with each other so it's important to start from that. Being able to understand someone's context is crucial to sharing your own context with them.So when thinking about data mesh, Alex thinks it makes sense to look at microservices and how people felt and behaved and learned during that transition. How did we upskill people for DevOps? What were effective patterns and what were the not-so-effective ones? And as Zhamak has discussed with her approach to data mesh, we need to decontextualize those approaches and learnings from software development and DevOps and then recontextualize them for data. Easier said than done - and not that easily said - but still, we have a lot of good and well documented history to learn from.A focus on quarterly results is another aspect Alex feels is important to recognize - there is a real sense of urgency. But there is also a desire to not rock the boat too much - we can't do data mesh in a quarter. Combining those two aspects, we need to break data mesh work into more manageable and understandable pieces - those nice milestones. You can't do all the disruption at once as it will create chaos.When looking for a place to get started with data mesh, Alex recommends looking for domains that either are having real business pain and pretty urgently need to change or domains that are very willing to take on change. If a team is having lots of issues, you can quickly add value and alleviate pain. If they are very willing, it obviously makes things easier. And then of course take the stories of successful change and use them to entice other teams :) But, according to Alex, if a team is having issues with change, you should look to what's blocking them. It's easy to try to throw additional change at them but that's just more burden when they are already struggling, already underwater. Go in with empathy to help them, that will win them over. Anchor to the idea of being a catalyst for change, something that lowers the effort needed to achieve change. And look to manage feelings because it's scary to think that what you are doing as part of your role won't be relevant. Watch out for that and work with them to see it as the less valuable pieces going away, not their importance.Alex is quite excited about some of the new data technology on the data consumption side - it's starting to feel like the tech is finally catching up to the software side in terms of tooling. Data consumers are much more digital and data literate than historically and with low code and no code offerings, with a bit of training, business users are able to actually get to and leverage data for generating insights. Note: Zhamak has said she is skeptical of low code/no code tooling but that has typically been on the data production side.When Alex and team looked at where they were having the biggest challenges around data, it was consumability. Data consumers weren't comfortable trusting the data, couldn't really understand the data, couldn't always find the data, etc. And the data changes were centralized with the data team itself. While that is a common situation - the data team owning changes when they don't have the context of the use case or the context of the source systems - it wasn't scaling well for them.Because of the data issues, data consumers were the hungriest for change and Alex and team decided to set up a bootcamp to level up data consumers. With more knowledge / higher data literacy, data consumers were excited to be able understand the data more, make changes on their own - thus not relying on the centralized data team -, trust the data more, etc.Pushing the idea of finding your failures fast - and being okay with issues/failures - in data is something Alex is pushing. Perfect is the enemy of good so putting something out and then stress testing it is far better than theoretically sound but untested work. With a fast feedback loop, they were able to quickly adjust their data bootcamp when they heard learning SAS before SQL made it very difficult to understand for instance.Alex shared some interesting learnings from the bootcamps they are doing thus far. 1) Focus on practical application and let people get their hands dirty now rather than teaching only theory. Time shouldn't only be spent in the classroom. 2) Look for those fast feedback loops. 3) Work to ensure people can take the time off necessary to actually focus on learning. It's easy to add more things onto a schedule, not put things off. 4) People really do want to learn to use data, they just aren't sure how without some structure. 5) Similar to #3, cognitive load is a very dangerous thing for bootcamps - don't overburden people. 6) Let people know they don't have to retain the exact specifics versus the knowledge on how to leverage data. You won't remember every function by heart and you shouldn't have to.According to Alex, steering the conversation away from ownership towards getting someone excited about learning a new skill has worked well. Instead of 'I need you to do X. I guess I will train you,' instead they are starting from training new skills to unlock additional capabilities and people are far more willing to take on using those new skills. People are so excited to go unlock more value and do cool things with their new skills. And they'll layer in responsibility and ownership as those people learn more and apply their skills.Getting to viable, valuable use cases is not hard according to Alex. He recommends just asking people what's frustrating them and then synthesize those into use cases that you can potentially address. That's actually what they are doing in the bootcamp - having people find use cases before coming into the training and then spending half their time during the bootcamp working on tackling those use cases. Getting them some real world situations to try to apply their new skills to. And if something already does exist around that use case, then they contribute by augmenting it or writing documentation or something similar. Create real-world impact milestones.It's pretty easy to feel like you might be left behind if your team isn't framing data work the right way according to Alex. Instead of pointing out exactly where to fix or that things are changing or they need to upskill, he looks to create the environment for them to realize things aren't great instead and have the realization that they want to go fix it themselves, regardless of the issue.Alex believes there are 3 main barriers to change: logic, credibility, and emotion. Most people try to appeal at most to two of the three and in data we often forget to manage emotion. And it's really important. And there is a heck of a lot of change involved in people's roles and work when it comes to data mesh in the long-run. As stated, it doesn't all change at once but you need to work with people to work through the change. Don't look to skimp on hitting all three.To get a big data literacy program approved like Alex did, look to whose incentives align with it and work with them. Always start from how is this beneficial to the person who gives the green light. You can give them the choice of do we try to hire our way to data literacy or do we train and upskill our current people. It might feel faster to try to hire but it probably isn't. And it's probably way more expensive. For Alex specifically though, the team was pretty bought in so he didn't have to go to a heroic effort. Other tidbits:If you want to get a data bootcamp approved, write a business case for it.Currently, Alex is encouraging a building block approach to everything. It's easy to fall into trying to scale too early but you do have to prepare for scaling if you're successful."Training a team for 2 weeks slows them down for 2 weeks. Not training a team slows them down forever."Basic blocking and tackling questions, those FAQs, are probably the biggest stumbling blocks for most people in data mesh. How to get access to X or Y system. Look for patterns in those questions and try to address them through automation.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 hereAll 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