Data Doesn't Respect Any Org Chart

I've worked across Data Quality, Metadata, Master Data Management and Data Products. I've developed data strategy, built operating models, led teams and spent a good portion of my career figuring out how information actually moves through complicated organizations. Yet one of the hardest things to explain about this work is how rarely it stays where it started.

You begin with a quality problem and find yourself tracing a business process. That process reveals a decision nobody quite made. The decision raises a question about ownership, which raises another about authority. Before long, you're in a technology conversation wondering whether the operating model is ready for what everyone is trying to build.

Data would be much easier if data problems had the professional courtesy to remain data problems. They rarely do.

Follow one far enough and eventually you're going to cross somebody's organizational boundary. Data doesn't respect any org chart. Neither do the hardest problems organizations need it to solve. The irony has never been lost on me. And I don’t think it’s a coincidence.

Follow the number

I once investigated an inconsistency in a critical enterprise measure. The same information informed external reporting, business planning, analytics, sales and forecasting, but different parts of the organization interpreted, calculated and used it differently. None of those differences lived neatly inside one system or function.

So I followed the number. I talked to the people doing the work, job-shadowed, documented processes, and profiled and tested the data. Definitions mattered, of course. So did ownership, handoffs, controls, technology and the ways different teams used the information. But the discovery that stayed with me wasn't a technical one.

They weren't talking to one another. There was no shared standard operating procedure for the handoffs. Each team worked toward its own deadlines, performance measures and responsibilities, often frustrated by the same flow of work but discussing that frustration only within its own group, if at all. People were working hard inside their own little worlds. Few had stopped to ask how the whole process could work better for the business or the client.

While that was as stunning as it was sad to see, I knew it was also an enormous opportunity. Once we brought people together to understand the entire journey, we could do more than reconcile a measure. We could clarify responsibilities, strengthen controls, reconnect fragmented processes and improve communication. And everyone's life got easier.

We didn't have a data-quality problem sitting neatly inside a database. We had an organizational problem traveling as data. Since the number hadn't respected the org chart, neither could the investigation - and sometimes that can make folks uncomfortable.

The problem with what we want to be true

Organizations need principles. For example, data is an enterprise asset, not the private property of the function that creates or maintains it. Critical information should have clear meaning, appropriate stewardship and accountable ownership. We want reliable sources of truth and technology that supports the way the business needs to work. These are good principles. I've spent much of my career helping organizations establish them.

The real test comes when principle meets operating reality. Consider enterprise ownership. CRM information may be maintained by Sales, but its value and consequences reach far beyond Sales. Who can make a decision that affects another function's use of it? Who understands the downstream consequences? Who can change the process that produces it, and who can influence the technology that carries it? Does everyone involved recognize the same person's authority?

Putting someone's name in a data inventory’s OWNER column is easy. Excel will even let you make the cell green. Unfortunately, the organization does not immediately reorganize itself around the spreadsheet.

What actually has to become true?

Over time I've become more interested in the distance between what an organization says should be true and what must happen for it to become operationally true. Enterprise ownership is a worthy principle, but what has to change for ownership to mean something? A single source of truth sounds reassuring, but which decisions about meaning, process and use must be settled before a platform can deliver it? A control may catch a defect, but is it resolving the underlying condition or simply becoming exceptionally good at catching the same symptom? And when we say technology can automate something, has the business made the decision we're asking it to implement?

This is where data gets inconvenient: it exposes the distance between the principle and the operating reality. Once you see that distance, you can stop at the boundary of the function that technically owns your piece, or you can keep following the problem. Following it does not mean claiming ownership of everything you encounter. A Data Quality team doesn't suddenly own Operations because it found an upstream process issue. Nor does the data team get to appoint itself CEO for the afternoon, tempting though that may occasionally be.

The job is to understand enough of the system to see what is connected. Because the organization is a system. The org chart is a representation of one. Those aren't the same thing.

The space between the boxes

People experience organizations through functions. Finance, Technology, Operations, Legal, Risk, Sales and Data each have legitimate responsibilities. Those boundaries create specialization, accountability and some semblance of order. But information doesn't forget where it came from because it crossed a dotted line. Meaning, decisions, consequences and bad assumptions travel with it.

Every handoff creates another opportunity for something to shift. A definition changes slightly. An owner lacks the authority everyone assumes they have. A process that works inside one team creates friction for the next. Technology faithfully implements a requirement without knowing the business never reconciled what that requirement meant. Eventually the symptom appears somewhere visible enough that somebody calls it a data problem.

The data travels so much, you're gonna need a passport to get back home.

I would be delighted to stay in my lane. Unfortunately, the data keeps leaving it.

Be careful what you put in the middle

There's a discipline I've spent years watching sit in the middle of all this: Data Governance. Perhaps we've done it a disservice by making it sound considerably drier than it actually is. We talk about policies, stewardship, ownership, controls, compliance, metadata and decision rights. Riveting stuff, I know. But those are the artifacts. The work itself happens somewhere much messier.

You can study the frameworks, examine the DAMA wheel, earn a CDMP and learn what an operating model is supposed to contain. Then you introduce Data Governance into a real organization and discover that the diagram didn't account for politics, territorial ownership or authority that exists on paper but not in practice. Nothing sets off organizational fireworks quite like introducing an authority discipline where several people already believe they have authority. Unless, perhaps, it's an organization that has become exceptionally skilled at avoiding accountability altogether.

Data Governance doesn't just reveal competing claims to authority. Sometimes it reveals an absence of anyone prepared to exercise it. I worked with a domain whose designated business owner was exactly the person the operating model said should make a decision. When the decision arrived, he effectively handed his vote to someone else. On paper, ownership was crystal clear. In practice, the decision was wandering around looking for someone willing to own it.

Sometimes 'we need more alignment' means precisely that. Sometimes it means nobody wants their name next to the decision. And sometimes the most uncomfortable thing Data Governance introduces isn't a new policy, control or committee. It's the expectation that a decision will actually be made by someone both authorized and willing to own what happens next.

The heart, eyes and ears

Data Governance is often described as sitting at the heart of the data disciplines. I’ve come to take that description more literally. A heart isn’t important because it owns everything. It doesn’t. It’s important because so much moves through it. Done well, Data Governance can be the heart, eyes and ears of the data organization: connecting information, decisions and accountability; seeing relationships that individual functions experience separately; and hearing where meaning, expectations and operating reality stop matching. And the people doing this work can lead with heart, too: caring about what serves the whole organization, even while learning to navigate its competing interests.

From that position, you notice where formal ownership separates from effective authority, where technology and operating reality diverge, and where one function needs something another doesn't realize it owes. You see a business that has evolved faster than the processes supporting it. You'll probably hear about all of this from everybody involved. Welcome to the heart.

Spend enough time there and the work changes not only what you see, but how you see. You become better at hearing what isn't said, recognizing when a data question is really a decision question, and distinguishing a genuine need for collaboration from a reluctance to make a call. That can be an extraordinary vantage point. It can also be an uncomfortable one.

The fireworks may be telling you something

Resistance is information, but it isn't automatically proof that Data Governance is right. Sometimes we really have followed a textbook too closely, imposed a standard that doesn't survive contact with the business or created an approval process nobody needed. I've gotten organizational dynamics wrong myself. But sometimes the friction comes from exposing something people would rather leave undisturbed. Telling those situations apart takes judgment, and experience doesn't make the politics disappear.

I once invested a great deal of energy walking a senior leader through the work, the rationale and what I was seeing. I believed we were exchanging knowledge, building trust and working toward the same greater good. I even reached for The Emperor's New Clothes analogy and asked whether she'd want me to tell her if I saw something significant beneath the surface. She said yes. So I told her she had no clothes. Subtle, I know. Then I explained what I was seeing.

I walked away believing we'd made a breakthrough. Boy, was I wrong - about the meeting, the relationship and the trust I thought we had built.

What made that experience so difficult was not simply that a hard truth had landed badly. I had always approached strong teams as something bigger than any one person's position. Playing team sports taught me early that you work to earn your place and improve your own performance, but you also help develop the people who will carry the team forward after you're gone. I brought that same belief to work. I thought contributing an uncomfortable observation in service of the organization was part of being in someone's corner. I learned that a contribution offered in that spirit can still be received as a challenge or threat.

I can't know every motive behind another person's reaction. I can say that the experience taught me how differently people may understand trust, shared purpose and the stakes of an honest conversation. It made me more attentive to organizational politics, but I don't want the lesson to be that you must abandon your belief in doing good work for something bigger than yourself. The lesson is to become more discerning about the people and conditions in which you try to do it.

If I could change anything, it would be who I trusted most: me. Not because I always have the right answer. I don't. But because I had already built more capability than I recognized. Maybe that's the thing about going out on a limb. The goal isn't to be certain the branch will hold. It's to trust the muscles in your own wings enough to know you can fly if it doesn't.

When trust changes the work

There was a point in my career when people stopped bringing me only complicated data problems. They began bringing sensitive business problems that happened to involve data. Client relationships, regulatory exposure, reputations and consequences for people could all be at stake. Getting the analysis right mattered, but so did knowing what to say, when to say it and how to handle what had been entrusted to me. Discretion mattered as much as discernment.

Business leaders began seeking my judgment, not just an answer from my function. Looking back, that was one of the clearest signs of how much the work, and I, had evolved. But when you're inside the friction, it can be hard to recognize that growth. You experience the difficult stakeholder, the ownership dispute, the technology disagreement, the council that can't decide, or the definition everybody liked until somebody wrote it down. Some days it feels like pushing a boulder uphill only to watch it roll back toward you.

What I couldn't see from underneath the boulder was that the work had built something in me, too. I needed distance to recognize it.

A little space between

A mentor gave me some distance. A career coach gave me a little more. Eventually, stepping outside the organization gave me the perspective to pull the thread together. Years navigating business, technology, operations and data had developed discernment, judgment and pattern recognition. They had taught me to distinguish formal from effective authority, to handle situations where discretion mattered as much as technical expertise, and to see connections that no one functional leader necessarily could from inside their own part of the organization.

Those are difficult capabilities to recognize when you're busy using them to get through Tuesday. I wish I'd understood sooner how much insight and influence can come from standing in the middle.

Not formal authority over every function, and certainly not responsibility for every problem you can see. But a remarkable view: across people, operations, technology and data; across the distance between the story an organization tells and the way it actually works; across what it wants to accomplish and what must become true to get there. That perspective can be a source of influence and leverage, even when nobody has given it a tidy box on the org chart.

It can also be uncomfortable. Seeing a problem doesn't mean you're obliged to carry it indefinitely. There is no medal for taking perseverance to the nth degree. Sometimes strength means pushing again. Sometimes it means pausing, setting the load down and deciding whether it is still yours to carry. Eventually, that's what I did, and I'm proud that I did. Learning the difference is part of the discernment, too.

Follow the problem farther than its label

Maybe that's the practice underneath all of this: follow the problem farther than its label. Don't assume the place where a symptom becomes visible is the place where it began.

When something looks like Data Quality, ask what produced it. When it looks like ownership, ask where the authority actually sits. When it looks like a technology problem, ask what decision technology is being asked to implement. When it looks like resistance, ask whether you're creating unnecessary friction or exposing friction that was already there. And when you find yourself carrying the same organizational problem again and again, ask whether it's still yours to carry.

What the view gives you

If you work in Data Governance, you may have built more capability than you realize. You have learned to see across functions, hear what isn't being said, and notice when an organization's principles and its operating reality have drifted apart. That perspective can make you valuable. It can also make others uncomfortable. Neither response, by itself, tells you what your contribution is worth.

You can learn to navigate politics without becoming cynical about people. You can recognize competing interests without giving up the belief that work should serve something greater than individual advancement. And you can decide when to put the boulder down without deciding that the effort was wasted. The boulder may have rolled backward today, but that doesn't mean you're standing where you started.

I've spent a lot of my career in those spaces between. Increasingly, I think that's where some of the most revealing work happens, because Data Governance asks us to reconcile what the organization wants to be true with what it actually takes to make it true. Data doesn't respect any org chart. Maybe one of the gifts of standing at the heart of it is learning to see beyond one, too.