The Role of Design and Technical Authorities in Data Product Approval and Certification

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.

Benny's LinkedIn: https://www.linkedin.com/in/bennybenford/

Iulia's LinkedIn: https://www.linkedin.com/in/iuliavarvara/

Nailya's LinkedIn: https://www.linkedin.com/in/nailya-sabirzyanova-5b724310b/

Stefan's LinkedIn: https://www.linkedin.com/in/stefan-zima-650229b7/

In this episode, guest host Benny Benford, Founder and CEO at Datent - a data transformation focused consultancy/community - and guest of episode #244 facilitated a discussion with Iulia Varvara, Advisory Consultant in Digital and Organizational Transformation at Thoughtworks (guest of episode #268), Nailya Sabirzyanova, Digitalization Manager at DHL (guest of a soon-to-be-released episode), and Stefan Zima, Data Transformation Lead at Raiffeisen Bank International AG (guest of episode #270). As per usual, all guests were only reflecting their own views.

The topic for this panel was transformation when it comes to data and data mesh in general but especially understanding how organizational transformation must play a large part in a data mesh implementation to be successful. And that transformation is not simply making changes, it is making _lasting_ changes. Organizational transformation is a crucial aspect of doing data mesh even if it's not spoken about all that often.

Scott note: I wanted to share my takeaways rather than trying to reflect the nuance of the panelists' views individually.

Scott's Top Takeaways:

1. Transformation means changing something. We aren't starting from scratch. You have to consider the starting points, not only the target end points - and in data mesh, there isn't really an end. Every organization's transformation starting point, whether a data mesh transformation or otherwise, will be unique so adjust your transformation journey plan accordingly.
2. There are so many reasons transformation initiatives, especially data transformations, can fail but a big one is not preparing for the long-term change necessary to make changes actually stick. It's easy to try to make changes but actually making them to last for the long run is something else entirely.
3. There needs to be a sense of urgency to drive forward a large-scale top down-driven organizational transformation. If there isn't a real business reason and one where there is a need - or at least a strong desire - to be addressed in the near-term, you are far more likely to lose momentum/sponsorship. And you need lots of momentum and sponsorship for large-scale sustainable transformation.
4. If you are trying to pitch something like data mesh, speak to real pain points. Just selling the potential benefits instead of solving real, painful existing challenges is not likely to win you as many converts. There's a reason painkillers are easier to sell than vitamins.
5. Transformation and product thinking have a lot in common. Org transformation is treating the organization as something like a product to improve over time. That means prioritization. You can't take everything on at once. Work with your stakeholders to make progress on what matters most.
6. Driving data transformation - data mesh or otherwise - will likely take a lot of education. There is a general sense people should be using data for additional use cases but really, many aren't thinking of the great ways they could use data. Help them find the link between their business priorities/pains and data.
7. Your business partners don't need to know the particulars of your transformation initiative. Sell them a story, give them an enticing vision. Why is this worth doing and what is the payoff? Stop taking them on the sausage factory tour against their will, give them - or promise them - a wonderful sausage tasting party instead.
8. Organizational transformation - data or otherwise - only happens when things change, when they transform. Sounds obvious but you really have to get your business partners to engage or your transformation won't be as successful and is likely to stall/fail. Trying to change the entire organization from just the data team is daunting at best.

Other Important Takeaways (many touch on similar points from different aspects):

1. Transformation might not be the best word since transformation implies an end state, an end to transforming. And while you should have some kind of target future state in mind, that's likely to be a target state along the journey rather than an end state. The only constant is change as Iulia said.
2. If you try to break your data mesh transformation down into very separate component parts and transform them separately, it's going to make it more difficult. You need to transform across technology, mindset, understanding, ownership, etc. simultaneously - pushing in the same cohesive direction. The organization has to be ready and capable for a change.
3. Relatedly, you can't start with some massive change or only look to deliver value starting in year 3. Find ways to make progress and deliver value - especially provable/marketable value - along the way. Incremental value delivery is the key to maintaining exec attention and sponsorship, which are crucial to maintaining momentum.
4. Also relatedly, this doesn't mean your progress on different aspects will all be at the same pace. Maturity, buy-in, capacity, etc. will determine how far you can transform different aspects and when. Don't try to wait for everything to move together.
5. A data mesh transformation driven from the bottom up and mostly by the data team is possible but will likely be harder - far harder? - than top-down. You need to constantly win more support but that can also have its advantages than something with fanfare but not a lot of specific direction.
6. Prioritization is key to doing org transformation well; so is measuring progress. If you aren't addressing the real pain points - or at least the pain points your exec sponsors care about 😅 - you will likely lose that sponsorship. Show them you are making progress against those pain points.
7. Get your business partners to tell you about their actual pain points. Not just about data but about areas where data may be able to improve their work. They will often literally tell you how to sell doing something like data to them by making them feel seen and heard, actually creating a plan to address their specific pain.
8. Relatedly, work with stakeholders to define success metrics around your progress. If you can continually show them incremental value and that you are addressing their needs, you are far more likely to be successful with your transformation initiative. But getting to clear metrics around the data work will be _hard_. Scott note: I'm writing a book on this for a reason 😅
9. ?Controversial?: If you want to 'prove' value from data work, create a way for other teams to measure the value created. A data team claiming they created value versus Finance claiming the data team created value is a world of difference when it comes to credibility.
10. When it comes to prioritization of data transformation, should the data team really be setting the priorities? For certain aspects like the platform, probably. But really, the business should tell you what are the highest priorities where you should focus your work.
11. ?Controversial?: The head of the data org should be there to enable other parts of the business to derive value from data. It's about making everyone else better.
12. Because of the central nature of many - most? - data teams in large organizations, too many people are used to them essentially being free - incremental data work doesn't typically cost the line of business or at least doesn't cost much. Transforming that mindset to get them to focus on extracting value from data work might be challenging.
13. As constantly comes up in almost every data mesh conversation, incentivizing data producers is hard. You should try to create structural incentivization at the organizational level to push some of the value created back to the data producers.
14. Data mesh isn't the point. It should never be the point. Zhamak has said this as well. We are looking for ways to achieve our goals and data mesh (hopefully) provides good framing to do that.
15. At the end of the day, data work should be about impact. Focus on impact with your business partners and they will be far more likely to continue to engage.

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