#246 Making Federated Data Governance Approachable and Effective - Interview w/ Kinda El Maarry, PhD

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.

#252 Designing and Building a Better Data Governance Approach - Interview w/ Lauren Maffeo

Kinda's LinkedIn: https://www.linkedin.com/in/kindamaarry/

In this episode, Scott interviewed Kinda El Maarry PhD, Director of Data Governance at Prima. To be clear, she was only representing her own views on the episode.

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

Always be assessing data literacy gaps and work to address them. Gaps don't have to be a bad thing, they are a chance for your people to grow! But ignore them at your own peril :)
A key aspect of your job as someone on the central governance team - or anyone managing a governance function - is to reduce friction, not add overhead. It can be hard to do that at the start of a journey but it should be a north star focus.
The phrase 'data governance' still has a stigma for many people from what often happens with a central-only approach to governance - processes and rules divorced from the actual business processes and the data which creates bottlenecks and headaches.
The federation of governance in data mesh helps address the bottlenecks but it introduces a new layer of complexity which can also cause some fear.
?Controversial?: If you are asking people to take on ownership of data, you must make sure their line of business/part of the org has the actual capabilities to do so. Otherwise, they will greatly struggle to own and are likely to push back.
Don't talk about governance in the weeds to people, the toolbox talks, the policies and standards. Focus on what are you trying to achieve with governance and then lean back on the toolbox if you need to explain the how. But many don't care about the how.
There is a sliding scale of how much is federated versus centralized based on domain capability and maturity level. You don't just push all responsibilities on to each domain at the start, it's a gradual process finding the right balance.
When you find a domain that has skill gaps necessary to overcome, set up a roadmap and have as positive of a conversation as possible to start along that roadmap - it's not what they lack but where they'll grow.
!Controversial!: Where possible, get rid of the central data governance committee. Collaboration is more key than trying to keep every stakeholder across the organization informed and involved in most decisions.
?Controversial?: Data governance people should stop thinking about federation as losing control. It's about enabling the decisions to be made by those that can best make them. That way, the governance team gets to focus on the guardrails, the standards, the blueprints - the things that make stuff easier for everyone.
No one is saying hand over control of very sensitive decisions without reason. It's about making sure the day-to-day decisions can be made so when there is an important/sensitive decision to be made, that's where the central team can step in to assist.
When trying to get teams to take ownership of their data, there isn't a silver bullet - every discussion and domain is different. But start with a clear understanding of what ownership means and start the discussion with what will you do to make them capable and ease the burden of ownership. Just dumping responsibilities in their lap won't go well.
Data culture is an often overlooked aspect of data governance. But it provides your scale - getting people to evangelize and share what's working instead of all knowledge dissemination coming from a central team/training is how you can get scale.
It's not exactly the data governance team's role to find the right reporting structure and career management aspects of a data mesh implementation but the team can help by creating good spaces for people to share and communicate to create a sense of comradery.
Centralized capabilities and coordination of certain aspects are crucial to doing data mesh right. You want to decentralize the decisions and the application of those decisions but centralize the enablement. A core, central data team is pretty important to making that happen.
?Controversial?: Interoperability between data products is important but interoperability often can get in the way of delivering data products. Don't focus as much on it as you probably think.

Kinda started off discussing the traditional view of centralized data governance and the stigma around the phrase. Because the legacy way were a team that didn't really understand many of the key business aspects around the data itself, the policies and guardrails were not designed to make creating data assets or projects easy. The decoupling of understanding from decisions led to bottlenecks. And data mesh is specifically designed in part to eliminate those bottlenecks.

However, as Kinda pointed to, the federated governance model of data mesh brings a whole new layer of complexity to data governance. So talking federated governance can create anxiety that there will be even more bottlenecks. But really, for many things, it makes governance far easier. A crucial point of data mesh is to unlock the ability to quickly react at the domain level by giving them the ability to make (most of) their own decisions - and easily lean on expertise when they need to.

Kinda talked about good communication around governance: focus on the why, what are you doing to drive value via governance, instead of the toolbox angle of policies, standards, etc. If they understand the why, they are more likely to lean in to the extra work data mesh puts on their plates. So start from listening and talking pain points - theirs and other people within the organization. If you are showing they are heard and that you're addressing their pain points to drive value, governance isn't so scary.

One aspect of data mesh that people seem to get a bit wrong in Kinda's view (and Scott STRONGLY agrees) is the federation versus centralization balance. You need to understand each domain's capabilities and overall maturity level. It's okay to start with most of the governance centralized if a domain isn't ready yet. It will be a bottleneck but it's a known bottleneck that is taken as a conscious choice.

Sometimes, in Kinda's experience, domains will want to move on pushing out a data product before they and/or the organization is ready. That's okay, just make sure they understand what they own and that they will be on their own - at least it's okay as long as it isn't breaking regulatory compliance or anything.

Kinda believes that you should look to do away with the central data governance committee where you can. You want stakeholders engaged of course but you can move faster and with better decisioning by collaborating, not committee-ing (blame Scott for that phrasing, not Kinda 😅). For example, instead of creating a global data quality standard herself and pushing it out, she created a hackathon around data quality measurement and the best solution - or really a combination of solutions - won.

Governance people should not look at federation as a 'loss of control' according to Kinda but instead, it's freeing the governance people up to focus on where they can add the most value, creating those blueprints, standards, guardrails, etc. It's helping drive data literacy and data culture. And it's acting as an advisor when necessary - you don't want each domain to implement GDPR compliance for instance. At the end of the day, the people on the ground in the lines of business know the data better than someone with only a centralized view really could so make it possible for them to make the right decisions and apply them easily. A big misconception here is that it's handing over all control but that's just not the case - when there are sensitive decisions or things that are of a bigger scale - e.g. regulatory related decisions - that's when the central team should be focusing on partnering the most.

There are a few parts to Kinda's approach for driving buy-in for a domain to take data ownership. The first is that you have to understand each domain and person is different. There isn't a single script that just works. These are people you're dealing with. Be prepared to customize the conversations and solutions. Second, have an understanding of what ownership actually means so you can communicate expectations clearly. Hard to understand exactly what's needed at the very start of a journey but get as close as you can. And third, when actually having the conversation, don't start from the expectations and new demands on them, start from what you're doing to make it possible so they actually can take ownership of the data. That includes tooling, training, and realigning their KPIs/OKRs so the data work is actually a key part of their role and measured results.

For any data governance effort, Kinda believes you should make sure to focus on all three of technology, process, and people. The people aspect is the most overlooked but your people are what provide scale by enabling the application of whatever governance work you are doing.

In general, driving data culture is crucial for data governance in Kinda's view. Data literacy and culture is part of data governance of course but in general, to find your internal key enablers and to inject data as part of the business processes, you can't just create mandates or platforms. You need to make creating spaces for people to share ideas and celebrate each other part of your culture.

For Kinda, when asked Zhamak's provocative question of "Will we actually need a CDO in an organization doing data mesh?", she and Scott agree the answer is yes. Because, at least at the start, there needs to be someone running that central coordination and helping to make all the decisions around what to decentralize and when and a very important one: doing the exec to exec buy-in and communication. So strategic direction and maintaining momentum and engagement is crucial, thus a data leader is necessary.

Kinda believes in both a top-down and bottom-up approach to doing data governance in data mesh. The top down is that executive buy-in and helping to change people's prioritization and then the bottom-up is focusing on the use case and making sure they have the necessary guardrails and processes as you continue to build those out.

In wrapping up, Kinda shared a somewhat controversial viewpoint on interoperability. While it is important, trying to focus on it too much will likely slow you down. She believes you shouldn't let interoperability get in the way of your work and you can't try to solve for all interoperability at the start.

Quick tidbits:

If you are doing data governance right, it will remove friction instead of add additional overhead. At the start of a journey, the scales might not be as far in favor of removing friction but always look to build that out - that's a key success metric.

For every project or initiative always, always, always start by assessing your data literacy gaps. If you don't, you are setting people up for failure.

You can show success through your data governance program by measuring things like time to actionable insights. Metrics in general will play a big role in proving out success so try to measure what is changing and you will probably be bad at measuring at first.

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