Here’s the draft for Part 2 of the book part on the Organization’s Impact on Data Modeling. Here, we get into the politics and power dynamics that impact data modeling. You can easily extend this to other technology initiatives as well.
Again, I can’t say this is a complete depiction of what happens in the world, as every organization is special in its own special way. But these are some of my experiences and observations over the decades that will hopefully shed some light on how organizational dynamics will impact your work as a practitioner. If I need to add or edit anything, I’ll note it in the footnotes.
Please leave a comment if you feel I’ve missed something important. And if there are grammatical or similar errors, please leave a note here.
Thanks,
Joe1
Data is Political.
You might have cringed reading that, but it’s true. The data modeling process is often marked by negotiation, influence, and outright conflict. Behind every metric is a potential turf war. Every entity might be a battle for naming rights. The decision of what constitutes the “source of truth” can become a zero-sum game where one department’s win is another’s loss.
Early in my career, I saw how data can be politicized. At one company, the CEO received glowing reports from every department: the sales close rate was phenomenal, retail was crushing it, and marketing couldn’t miss. Everything seemed amazing! There was just one problem. The numbers didn’t match the reality on the ground. The warehouse was overflowing with unsold inventory, a fact that directly contradicted the rosy pictures being painted. The CEO found it impossible to trust the data. The CEO, tired of the conflicting narratives, sat me outside his office as his “numbers guy” and tasked me with providing him with the correct data. It took a while, mainly because I had to gain the trust of the CEO and the various department heads who felt threatened by my position, but we got there. That experience showed me that data wasn’t just about numbers.
The lesson that stuck with me is that data is political. I saw firsthand how departments could manipulate numbers to make their performance appear better than it actually was. It also taught me that data models are political artifacts. They reflect a shared understanding, but that “shared” understanding is often shaped by influence, competing interests, and unwritten rules. A poor model in a dysfunctional organization creates a downward spiral where trust erodes and bad decisions multiply.
In contrast, a supportive and constructive organization with psychological safety will likely provide you with numerous opportunities to properly model your data, which in turn gives people better data upon which to base decisions and act. This positive feedback loop is far more desirable. In high-trust organizations, data models serve as accelerators of alignment rather than weapons in turf wars. Trust fosters clarity, and clarity in turn reinforces trust.
I realized that to succeed, I couldn’t just be the “numbers guy.” I had to become a Practitioner who could get the technicals right, a Salesperson who could convince stakeholders of the new reality, and a Servant who could mediate departmental disputes and gain trust. To navigate this landscape, you must also learn to operate in these three distinct, often overlapping, personas. You won’t always be equally good at fitting these personas, so it might be best to work with people who can fill in where you’re a bit weaker, and you fill in where you’re stronger. However, data modeling is a combination of practice, sales, and service. Briefly, here are the requirements of these personas.
- The Practitioner is the data detective and the master builder, the technical expert comfortable working in the trenches. You understand the schemas in various systems, can reverse-engineer an arcane system, decipher poor-quality data, and build a data model under pressure.
- As a Salesperson, you’re the translator and diplomat. You translate complex technical work into compelling and tangible business value, convincing people of its importance. As you’ll see, this is not easy. You will need to be both an advocate and a negotiator.
- When you’re a Servant, you’re the empathetic facilitator. You understand that your primary job is to listen, build consensus, and mediate disputes over definitions to deliver timely, real-world value.
Think of these personas as roles you’ll switch in and out of, depending on the situation. Mastering them isn’t just about building better data models. You are also creating the trust and alignment that turn data into a true organizational asset.
Stakeholders Dynamics
In the full-contact sport of data modeling, you are never working in isolation. Your success depends on your ability to navigate a complex web of people with competing interests, needs, and levels of influence. These are your stakeholders. Identifying them isn’t just good practice. It’s the first step in mapping the political terrain, which we’ll dive into shortly.
Internal vs. External Stakeholders
We all have stakeholders, those individuals or groups that have a “stake” in some part of an organization’s success. This could be the success of a new initiative, the launch of a new product, or a boost in the share price. In data modeling, you’ll encounter two main types of stakeholders: internal and external. Let’s examine these and their impact on data modeling.
Internal stakeholders are individuals or groups that are directly involved in the company’s operations and have a vested interest in its success. They are typically found within the organization and include employees, management and executives, the board of directors, and shareholders and investors.
The data model you provide for internal stakeholders will be used within the company. It might be an application that powers a part of the business, a report used by executives, or an ML model powering a business process. These use cases may not directly impact end customers, but they help streamline business operations and processes. Here, the data model must influence trust inside the company.
External stakeholders are individuals or groups outside the organization that are indirectly affected by the company’s actions and decisions, including customers, suppliers, governments, and the broader community impacted by the organization. Here, the stakes often involve compliance, contractual obligations, and maintaining a strong brand reputation.
For instance, I have many friends who work in the financial industry, which is heavily regulated. Here, their data must be modeled to produce the exact data required to meet regulations and expectations of various other external stakeholders (investors, boards, etc). Providing an “almost good” answer won’t work and may result in fines or jail time. The stakes are clearly understood, and the data is modeled accordingly.
In another example, regulations like GDPR clearly state you must delete a user’s data upon request. How will you do this? It’s incredible how many data models don’t allow for an easy, cascaded deletion of data, forcing manual deletion instead. Given the risk of “missing something” in this case, proper attention to modeling is imperative.
The Power Interest Grid
Before we look at the major stakeholder groups you’ll meet, let’s quickly lay out a classic framework for stakeholder management - the Power Interest Grid. This provides a rubric for understanding who to prioritize and who you don’t need to invest as much time with.
Source: https://www.projectmanagement.com/wikis/368897/stakeholder-analysis--using-the-power-interest-grid#_
Here are the four buckets to pay attention to:
- High Power, High Interest (Key Players - Manage Closely): These are the people you must fully engage and manage closely (e.g., your executive sponsor, the lead developer of the app using your model).
- High Power, Low Interest (Keep Satisfied): These are individuals who can derail your project but don’t care about the details (e.g., a CFO who only focuses on the budget line). Give them the executive summary.
- Low Power, High Interest (Keep Informed): These are often your end-users or allies who are passionate but lack influence (e.g., the analyst who will use the data). They are a great source of feedback.
- Low Power, Low Interest (Monitor - Minimum Effort): This is your “Everyone Else” category, which you’ll learn about shortly.
As you learn about the four stakeholder groups, keep in mind where they fit into the Power Interest grid. The groupings will vary on the situation, and realistically, don’t map neatly (except the “everyone else” group). The reason is that you might have a High-Power, High-Interest stakeholder who could be an internal or external consumer, or part of the Support Crew. Use this guide to map the terrain of your working relationships and determine how much you’ll need to serve them.
The Four Stakeholder Groups You’ll Work With
Your stakeholders will view your data models in different ways. Some will be directly involved in it, while others will be tangentially impacted, and still others will be unaware of what data modeling is or who you are.
In data modeling, consider stakeholders from four complementary perspectives: internal and external consumers, supporters, and all other relevant parties. These stakeholders are presented in terms of those you’ll impact most to those least affected by your work. Let’s examine the first two types of consumers: internal and external.
Internal Consumers
Most of the time, internal consumers are your co-workers and bosses. They utilize your data model to perform their tasks and support the business’s progress. The data they use to do their jobs is the nervous system of the company.
Some typical internal consumers of data are:
- Executives require data to inform their decisions and actions. Often, executives must make quick decisions in uncertain situations. The data you provide should be analyzed for KPI dashboards and strategic summaries.
- Operational and line-of-business staff who rely on timely, accurate data to keep day-to-day processes running. These individuals might be from the supply chain, marketing, or accounting departments, all of whom rely on high-quality data to perform their jobs effectively. They might also be the people who impact your data by manually inputting data. This is often the classic feedback loop in data: garbage in, garbage out, or, conversely, quality in, quality out. Furthermore, this same data might be used to power apps, analytics, or ML models used by other internal and external consumers.
- Developers who both create and rely on data to keep applications running. Applications are a feedback loop where data is generated, processed, and saved either in an updated form or as a new piece of data. Central to all this is a robot data model that powers the application.
- Analysts and data scientists require flexible, well-structured data to conduct in-depth analyses and experiments on various business questions. The quality of analysis and experiments is only as good as the underlying data. A bad place is when data is dirty, full of errors, and full of null values. In this case, the analyst or data scientist must decide how to impute or clean the messy data. This is not the value-added work that the analyst or data scientist is either trained for or should be spending their time doing.
- AI and Machine Learning models. You might think of models as consumers, but remember that a data model serves humans and machines. These models are critical automated consumers that require clean, reliable, and well-structured data (”features”) to make predictions, classifications, or generate content. The performance of a customer-facing recommendation engine, LLM, or an internal fraud detection system depends entirely on the quality of the data it consumes.
Your primary job is to serve your internal consumers. They rely on you, and you rely on them. You must be empathetic, attentive, and focused on the needs of your co-workers. Your data model needs to be believable enough that people trust it, and performant and straightforward enough that people will use it. A data model that doesn’t answer questions or is too slow, confusing, or limited will have abysmal adoption, no matter how elegant the design. Modeling for internal consumers is about clarity, accessibility, and alignment with the goals and decisions they’re accountable for.
External Consumers
”The purpose of a business is to create and keep a customer.” - Peter Drucker
For some technicians, there’s the belief that their work stops outside of their team or company. Especially for people operating in Enterpriseland, this is especially true. Ultimately, every organization serves someone or something in the greater world. The data you provide to internal consumers should, in turn, have an indirect impact on the end customer of your organization.
If you’re in Productland, your data model will be directly consumed by external users, outside of your organization. Let’s call them customers. Customers are the ultimate consumers, interacting with the output of your data models through product features such as personalization, search results, and recommendations.
If you’re not in Productland, your data model might still be consumed by non-customer external consumers. These may include business partners, suppliers, regulators, auditors, or any other individuals who require access to your data to perform their duties. These external stakeholders consume data from your systems through APIs, file sharing, and other means.
Depending on the external stakeholder, your data model will need to meet varying degrees of precision and requirements. Much of this depends on the risk involved. For instance, if you’re selling shoelaces and you share an Excel report with a supplier about last week’s sales (you laugh, but this is extremely common), if the report is off by a few units here and there, it’s probably not a big deal. Any discrepancies in quantity will balance out over time through sales. On the other hand, if you’re providing data for regulatory purposes (e.g., SOX, GDPR, etc), the risk is high if your data doesn’t meet the strict requirements of the regulator. The public may also be affected by your data model, in the form of biased algorithms and data being used for purposes such as lending, hiring, or policing. Know the game you’re playing. What are the ethical, privacy, or legal consequences of your data model?
Your role is Sales. Not hard selling, but you need to persuade leadership and colleagues why taking extra care in the data model matters, balancing the investment versus the risks of getting it wrong. You must advocate for ethical, compliant, and fair data practices, even when they incur additional costs or delay delivery. Selling the “why” is essential to prevent reputational, legal, and ethical disasters.
Your Support Crew
Data modelers don’t work in a vacuum, or at least shouldn’t. Inevitably, you’ll have a support crew around you who will support your data model in various ways. These might be software or data engineers, DBAs, or IT teams. Alternatively, if your company lacks resources, you may need to be your own support team.
Here, I will focus on supporting the physical data model, as this is what most internal and external consumers encounter. While the conceptual and logical models remain essential, the physical model is what most people rely on to perform their jobs.
A data model is useless if nobody can use it. Support focuses on ensuring the model’s accessibility, maintainability, and integration with other systems. Engineers and DBAs will keep the systems performant and scalable, integrate the model into applications and pipelines, and monitor the reliability, cost, and security.
All of these activities support the work you’re doing, so make sure your supporters are your allies. Here, you step fully into the Practitioner role. You’ll earn respect by being technically proficient enough not to be a bottleneck or nuisance. Win over this group and your model will stand the test of time. I’ve seen data modelers ignore the input from their support team. For instance, the physical model may be overly complicated, difficult to maintain, or too costly to operate. Ignore your support group at your peril. If you do so, your model will likely collapse under its own weight or wither from obscurity. Instead, bring them in early, listen to their concerns, and bake these into your model, and co-design where possible. Remember, data modeling is a full-contact sport. Collaboration, especially with the people directly supporting you, is key to building a resilient, production-grade data model.
Everyone Else
Then there’s everyone else. Beyond the dedicated few, a vast majority of individuals remain largely unfamiliar with the craft or importance of data modeling. Frankly, many do not perceive it as a pressing concern. Put more bluntly, most people are unaware of or uninterested in data modeling. Your work may impact them, but discussing data modeling with them will likely elicit blank stares and possibly even annoyance. When communicating data modeling, gauge the room’s temperature to ensure you’re speaking with people who understand the subject matter.
A classic trap I see technicians run into is equating their role to that of the larger organization. I once overheard a coworker claiming that most startups fail because they don’t adopt functional programming. I shook my head in disbelief at this person’s lack of awareness of how business works. Software engineers might view things through a systems lens, while some data professionals think that every solution for the company should be “data-driven,” and so on. Remember, your world isn’t the bigger world. Know the difference.
You might take on the Sales role here, with a strong emphasis on might. More likely, it’s none of the three roles at all, and your role is simply to know whether to be quiet. Before diving into technical specifics, gauge others’ understanding and interest in the subject matter. Tailor your communication approach to resonate with their level of comprehension, focusing on the practical implications and benefits rather than the underlying technical complexities. A successful data modeler understands not only the data itself but also the diverse perspectives and priorities of the stakeholders they serve, adapting their message to ensure clarity, relevance, and ultimately, buy-in.
Power Dynamics and Situational Awareness
The stakeholders we discussed all have their own needs, some of which they compete with others for. Sometimes, these needs align with the company’s goals. Other times, these needs are selfishly motivated. Here are some power dynamics you’ll need to watch out for when modeling data. Like many aspects of this part of the book, I can’t say it is complete, but it will at least make you aware of your surroundings.
Power Dynamics: Who Defines Truth?
Now, I know what you’re thinking. This is a book on data modeling, so just show me how to model data. But let me ask you something. Who defines “truth”? The end-customer? A committee? A regulatory committee? Or the HIPPO (Highest Paid Person’s Opinion)? You might think that data comes down to what’s most accurate or leads to data-driven decisions. There are more layers to truth than you might be comfortable with.
The truth is that “Truth” means different things to different people. This often depends on where power sits and who defines truth in your organization.
Where does real power sit? Sometimes it’s not where you think. While official organizational power ultimately resides with executives and their board, sometimes real power is held by the people who most closely interact with those who have immediate control over you. It might be the engineering team supporting your data model. Or it might be a department VP gunning for a promotion, and who might “tweak” the numbers “just a tad” to make themselves look good.
Much of this behavior stems from incentives. As Charlie Munger once said, “Show me the incentive and I’ll show you the outcome.” People will behave according to how they’re rewarded or punished. If someone’s bonus depends on an outdated or modified definition of “new customer,” your new data model is a direct threat.
Understanding power dynamics starts with knowing what game you’re playing. For example, in Enterpriseland, analytics battles revolve around truth, specifically, whose metric wins. In Productland, battles revolve around control: who owns the systems, schema, and revenue-critical data.
How are decisions made? Are they made by consensus, mandate, or by gut feel? Here, you’ll mostly lean on the Salesperson persona, persuading decision-makers why straightforward, consistent definitions matter, while defusing the politics that come with challenging entrenched interests.