Feb. 11, 2025
Read time: 4 minutes and 57 seconds.
tags:Data governance developed from failing until a need was developed.
Expertise comes from breaking stuff, seriously.
You might think expertise comes from endless practice, but it often comes from spectacular failures. Not every problem is created equally, and taking the complex problems that teach us the most as playbooks for future solutions is a practice that formed Data governance. Smashing your head against problems, especially in data governance, teaches you more than any textbook. This is how you learn what truly matters and what’s just bureaucratic noise. Even if it’s bureaucratic noise that helps you solve problems at times, but being able to get through that bureaucratic noise is the signal and skill most valuable in organizations preserving data velocity and value.
No haiku, limeric or rhyming couplet, but i’ve consistently realized that errors are probably the greatest teachers. When one can commit erros, you can actually adapt and learn rapid, flexible solutions that no textbook can teach. Even if we talk about DAMA - DMBOK, the pragmatic skills learned in the textbook don’t compare to years of learning first hand. It might be helpful for getting a certification, but practical skills you can apply time and again come from the sharpening of your blade, over and over again from errors committed. It is not only good to run into problems, but the pathways to resolving are what help us be samurai swords vs. butter knives.
The best data governance practices are often born from major blunders.
I can’t begint to share just how true this is for my experience and myself as well as the case studies I have seen time and again. If you base your life on a textbook, you’ll likely encounter problems that will paralyze you since they live outside of the scope of your issues. However, being able to learn lessons from your mistakes and the mistakes of others is naturally what helps make us aware of what to avoid. Big banks have made big mistakes by ignoring key problems that exis or ignoring alarming behaviour that later violated more than one regulatory rule. Politicians on both sides of the aisle try to help cover it up, but there’s something to be said about mishandling of information on behalf of companies’ customers that makes it virtually impossible to ignore due to catastrophic consequences. Banks are not alone:
We need to evolve our data practices where necessary. Not because we are living under constant threat of the violating federal regulations, but instead because we cannot afford to make silly mistakes that can cost a business money. I remember at my time in Harry Rosen I worked with my team to create a Data governance initiative that had taught me more than any semester in university. There was often disagreement and arguments over figures and their accuracy that it made “data-driven decision-making” virtually impossible. A meeting would stall almost immediately if different figures were seen. Role-based Access Conrols? no one cared, just give me the data. Data quality? It meant that your numbers were “wrong” and “mine” were “right”. Months of back and forth with different groups that disagreed on unimportant points became the important point to be able to accelerate the use of data. We realized need to educate people and get their skin in the game to actually motivate mobility for users of data.
We wanted to avoid hours / weeks of work so someone can crush the credibility of a technically sophisticated tool in seconds because the numbers were different. Our group headed the initiative and since our group valued statistics more than opinions we lost several battles of convincing people about the project importance. Instead, we spun our tires on a 2 year long initiative that still required us to work AND try to convince people why adopting robust DAMA practices were important.
Crediting statistics and discrediting people about reporting was surely one of the biggest mistakes I made during this part of my career. People just WOULD NOT buy into my suggestions, recommendations or plans.
A large part of this problem was a result of data ownership and encouraging people to see data ownership as a responsibility worth having. People were already drowning in work and couldn’t be bothered to learn more, attend more meetings or do something outside of the scope of their “job description”. Especially as our group relied heavy on data-related tools, a lot of ML / DL / AI relied on people’s buy in on methods. Now that AI is in the frame of 80-90% of data-related conversations, the ownership of information created increased in complexity by an exponential factor. No one knew how to solve these problems and endless blogs, guides and books tried to support us with down-time worthy attention. A reason why having some type of structure around Data Governance initiatives is of the utmost importance. More than once, I’ve confidently presented the “wrong” answer and it’s largely because I would define “right” on the fly while others had a different concept about what “right” really was.
The whole point of data governance is avoid this non-problem with pragmatic documentation while decisions are made and involving key stakeholders to ensure the result makes sense for everyone.
Data governance isn’t about stifling red tape; it’s about consistent, accurate processes. As much as compliance is valuable to protect end users, consider the employee who is tired of dealing with it daily because a manager in some group is not providing a clear path for a validated and robust point of performant problem-solving. Data ownership, data sourcing and lineage, as well as data-quality is what helps us most on the path to data velocity and ensuring our data works for us and with us; Not against us.
Data governance is about balance – knowing what adds up and tracing problems to their roots. It’s a field shaped by trial, error, and a lot of learning from failures.