Data Council Strategy: Why Most Companies Get It Wrong

Photo by litoon dev on Unsplash

Microsoft’s Data Council Launch: What Most Companies Will Copy (And Get Wrong)

Microsoft announced this week that they’ve spun up a unified data strategy powered by a formal data council. The news hit the usual enterprise channels—headlines emphasizing alignment, governance, AI readiness. What didn’t make the headlines: most companies reading that story will launch their own data council in the next 90 days, schedule the first meeting for maximum executive attendance, and watch it die by September because nobody defined what decisions the council exists to make.

According to Gartner’s 2024 Data & Analytics Leadership Survey, 62% of organizations now operate some form of data governance council or committee. But only 19% of those councils report measurable impact on data quality, access speed, or decision velocity. The gap between existence and effectiveness is a chasm, and it’s widening as more organizations treat council formation as the outcome rather than the starting point.

David Ohnstad has sat in enough cross-functional data meetings at Veeam to recognize the pattern. A council gets chartered with great intentions: break down silos, align on standards, accelerate AI adoption. Six months later, the meetings are biweekly status updates where nobody has decision rights and every contentious issue gets escalated to someone who wasn’t in the room. The council becomes a coordination theater—a place where data strategy goes to get discussed, not executed.

The Council Collapse Pattern: Why Most Data Councils Fail Within Two Quarters

Data councils fail predictably, and they fail for structural reasons that have nothing to do with the people in the room. The failure mode follows a sequence: initial enthusiasm, charter confusion, scope creep, meeting fatigue, silent abandonment. By month six, attendance drops. By month nine, the meetings stop appearing on calendars. By month twelve, the Slack channel is archived and nobody writes the postmortem.

The root cause isn’t lack of commitment. It’s lack of clarity on three foundational questions that most councils never answer before they hold their first meeting: What decisions does this council own? What decisions does it influence but not own? What topics are explicitly out of scope, no matter how data-adjacent they appear? Without bright-line answers to those questions, every meeting devolves into the same trap: interesting discussion, unclear outcome, no follow-through.

Here’s what that looks like in practice. A retail company launches a data council to “govern enterprise data strategy.” The first meeting tackles data quality standards for customer records. Engineering wants strict validation rules. Marketing wants flexibility for campaign segmentation. Finance needs clean data for revenue recognition but doesn’t care about marketing’s use case. Three meetings later, the group has drafted a standards document nobody will enforce because the council has no authority over how teams actually build pipelines. The discussion was productive. The outcome was zero.

According to McKinsey’s 2023 report on data governance maturity, organizations with high-performing data councils share one structural trait: they operate with explicit decision rights documented in a publicly accessible charter, and those rights map to specific system-level outcomes—not to aspirational principles. The underperformers universally describe their councils as “advisory” or “coordinating,” which in practice means they coordinate nothing and advise on everything, which is functionally the same as advising on nothing.

The Decision Rights Framework: How to Structure a Data Council That Actually Governs

This is a five-part framework. It works because it forces clarity before the first meeting, not after six months of drift. David Ohnstad has used variations of this structure to stand up cross-functional data governance at scale, and the core insight is simple: if you cannot explain what this council decides versus what it discusses, you are building a talk shop, not a governing body.

Step 1: Define the Council’s Decision Boundary—And Make It Uncomfortably Narrow. Most councils fail because their scope is aspirational rather than operational. “Govern enterprise data strategy” is not a boundary—it’s a mission statement. A boundary looks like this: “This council owns approval authority for any new data source integration that will feed the enterprise data warehouse, any change to existing schema that affects more than one business unit, and any tooling spend over $50K that touches shared data infrastructure.” That’s narrow. That’s intentional. Everything else—team-level analytics, departmental reporting, exploratory data science projects—lives outside the council’s jurisdiction. The most important decision a council makes in its first 30 days is what it will NOT govern.

Step 2: Assign Three Tiers of Decision Rights—Own, Approve, Consult. Every topic that enters the council’s boundary gets classified into one of three tiers. Own: the council makes the final call, no escalation required. Approve: the council must sign off, but the proposing team owns execution. Consult: the council provides input, but the decision lives elsewhere. Most councils operate entirely in the Consult tier and wonder why nothing changes. The framework works when at least 40% of the council’s scope sits in the Own or Approve tiers. If you cannot name five decisions this council owns outright, you do not have a council—you have a steering committee with no steering wheel.

Step 3: Map Decision Rights to Named Individuals—Not Roles. This is the step that surprises people, and it is the step most councils skip. A decision rights matrix that says “Engineering Lead” or “Data Owner” is worthless because it does not tell you who to call when a pipeline breaks at 3 a.m. The matrix must name people: Jane Chen owns schema changes for customer data. Raj Patel approves tooling spend for the analytics platform. When decision rights live with roles, accountability evaporates. When they live with people, execution accelerates. David Ohnstad learned this the hard way when a major architecture decision stalled for six weeks because “the data owner” was on leave and nobody knew who had signing authority in their absence.

Step 4: Schedule Decision Meetings, Not Update Meetings. Most councils meet biweekly for 60 minutes and spend 50 of those minutes on status updates that could have been an email. The Decision Rights Framework inverts that structure. The council meets monthly for 90 minutes. The first 30 minutes are pre-reads: no verbal updates allowed, every agenda item requires a one-page memo circulated 48 hours before the meeting. The next 45 minutes are decision time: each agenda item gets 15 minutes for discussion and a recorded decision. The final 15 minutes are action review: who owns what follow-up, what is the decision deadline, what escalation path exists if the deadline slips. If a topic does not require a decision, it does not belong on the agenda.

Step 5: Publish a Decision Log Within 24 Hours of Every Meeting. This is the accountability mechanism that separates governing councils from talking shops. Every decision made in a council meeting gets logged in a public document with five fields: decision summary, rationale, owner, deadline, and escalation contact. The log lives in a location accessible to every employee who touches data—not buried in a SharePoint folder that requires three levels of permissions to access. The log is the council’s work product. If the log does not grow by at least two decisions per meeting, the council is not governing—it is coordinating, which means it is failing.

What Senior PMs Get Wrong About Data Council Participation

There is a widespread belief among senior product managers that data councils are where strategy gets set, so the goal is to attend, represent your domain, and influence the roadmap. That belief is expensive. It costs time, credibility, and execution speed. The reality is that data councils are where decisions get made or blocked, and the PMs who treat councils as influence forums rather than decision forums consistently lose to the PMs who show up with a pre-read, a specific ask, and a fallback position.

David Ohnstad has watched this play out repeatedly: a PM brings a data integration request to the council, frames it as strategic alignment, and spends 20 minutes building context for why the business needs this capability. The council nods. The discussion meanders. Someone raises a concern about schema compatibility. Someone else asks whether this overlaps with another team’s roadmap. The clock runs out. The decision gets tabled for the next meeting. Two months later, the integration still hasn’t shipped because the PM treated the council as a stakeholder to persuade rather than a decision body to navigate.

The PMs who succeed in council-governed environments do three things differently. First, they submit a decision memo 48 hours before the meeting that states the ask in one sentence, the business case in three bullets, and the fallback option if the ask gets rejected. Second, they pre-wire the decision by talking to key council members before the meeting to surface objections early and adjust the proposal accordingly. Third, they ask for a specific decision type—Own, Approve, or Consult—so the council knows what action is required. That approach treats the council as a governing body with finite decision bandwidth, not as an audience for a product pitch.

This distinction matters more as organizations scale AI and ML capabilities. According to Forrester’s 2024 AI Governance Report, 73% of enterprises now require some form of council-level approval for production AI deployments, up from 51% in 2023. The councils that handle those approvals efficiently operate with the Decision Rights Framework. The councils that do not are creating a bottleneck that slows AI adoption without improving AI quality, because the approval process checks for governance compliance but not for model effectiveness. That is the gap David Ohnstad on AI and enterprise SaaS explores in depth—councils that govern structure but not outcomes produce process overhead, not risk reduction.

The Three-Meeting Test: How to Know If Your Council Will Survive

By the third meeting, a data council reveals whether it will last or collapse. The pattern is consistent. High-performing councils make at least two recorded decisions per meeting by month three. They publish those decisions in a shared log within 24 hours. They enforce pre-read requirements and cancel meetings when no decisions are on the agenda. Low-performing councils spend meeting three litigating whether they need a mission statement revision, debating whether the charter should include more stakeholders, or discussing whether the council should meet weekly instead of biweekly. Those are symptoms of structural failure, and they are visible by meeting three.

Here is the test David Ohnstad uses to evaluate whether a council is on track or doomed: Can you name three decisions this council made in its first 90 days, who owned execution for each decision, and what measurable outcome changed as a result? If the answer is no, the council is already failing. It may continue meeting for another six months, but it is not governing—it is performing governance theater, which is worse than having no council at all because it creates the illusion of coordination while consuming senior leadership time.

The surprising part of the three-meeting test is that councils do not fail because they make bad decisions. They fail because they defer decisions. A council that approves a controversial schema change in meeting two and reverses it in meeting four is still governing. A council that tables the schema discussion for three consecutive meetings while gathering more input is not. Speed of decision-making is a better predictor of council longevity than quality of decision-making, because councils that move fast build credibility, and credibility attracts the decision rights that matter.

The Leadership Trap: Why Councils Need Coaching, Not Just Charters

Even councils with clear decision rights and strong charters collapse if the leader treats their role as facilitation rather than execution. The failure mode is subtle. The council chair runs efficient meetings, ensures every voice is heard, and maintains neutrality on contentious issues. The meetings feel productive. The decision log grows. But six months in, nothing has changed at the system level because the chair never pushed a decision through resistance, never escalated a blocker to the executive team, and never told a stakeholder that their concern was noted but would not delay the decision.

Effective council leadership is not neutral. It is opinionated, directive, and willing to make people uncomfortable in service of decision velocity. That does not mean dictatorial—it means the chair arrives at each meeting with a perspective on what the council should decide, advocates for that position, and calls the question when discussion reaches diminishing returns. The best council chairs David Ohnstad has worked with all shared one trait: they were willing to make a decision with 70% of the information rather than wait for 90%, because they understood that delayed decisions compound into organizational drag faster than imperfect decisions do.

This is where the intersection with leadership execution becomes critical. Data councils need coaching-based leadership to translate strategy into team accountability rather than relying on governance structures alone. A council can define decision rights perfectly, but if the chair cannot hold decision owners accountable for follow-through, the framework collapses. That accountability layer is what separates councils that govern from councils that coordinate, and it requires leadership skills that most organizations do not assess when selecting council chairs. The technical expertise to understand data architecture is table stakes. The willingness to drive decisions through friction is the differentiator.

When to Kill Your Data Council

Most organizations treat data council formation as a one-way door. Once you stand one up, the default is perpetual operation. That is a mistake. Councils should have explicit success criteria and sunset clauses. If the council has not made a decision that materially changed system behavior in the past 60 days, the council should be paused or disbanded. Governance infrastructure that exists without governing is organizational debt, and it accumulates interest in the form of meeting overhead and stakeholder fatigue.

Here is the contrarian claim that senior data leaders push back on: stop treating data councils as permanent governance structures—they are temporary forcing functions that should dissolve once decision rights are embedded in line roles. The goal of a high-performing data council is not to exist indefinitely. The goal is to clarify decision authority so thoroughly that the council itself becomes unnecessary. When schema approval authority is clearly documented, when tooling spend thresholds are widely understood, when cross-team data integration follows a published playbook, the council has succeeded by making itself redundant. Councils that operate for more than 18 months without evolving their scope or disbanding are usually solving a problem that no longer exists, or solving a problem that should have been solved by hiring decisions and org design rather than by coordination committees.

David Ohnstad has seen this pattern in woodworking projects and in data governance: the best structures are the ones you build once, use hard, and then dismantle when the need changes. He built bookshelves for his daughters’ rooms because they needed storage. When they no longer need those bookshelves, he will dismantle them and use the wood for something else. The same principle applies to councils. They are tools, not institutions. When the problem changes, the tool should change with it. Organizations that treat councils as permanent fixtures end up with governance structures that outlive their utility, which is how you end up with five councils that all claim authority over the same decision and none of them can tell you when they last made one.

The Measurement Problem Nobody Talks About

Even well-structured councils fail if they do not define what success looks like before the first meeting. Most councils track inputs—number of meetings held, attendance rate, topics discussed—but not outcomes. A high-performing council tracks decision velocity (average time from topic submission to decision), decision durability (percentage of decisions that remain unchanged after 90 days), and system impact (measurable change in data quality, access speed, or adoption resulting from council decisions). Those metrics are hard to instrument, which is why most councils do not track them. But without them, the council has no mechanism to know whether it is governing effectively or just meeting efficiently.

According to IDC’s 2024 Data Governance Benchmark, only 27% of organizations with active data councils measure decision velocity, and fewer than 15% track system-level impact of council decisions. The gap is not a measurement problem—it is a clarity problem. Councils that cannot define what outcome they are driving cannot measure whether they are succeeding. The fix is not better dashboards. The fix is defining success criteria in week one: by the end of Q2, this council will have approved or rejected at least 12 data integration requests with an average decision time of 10 days or less. That is a measurable outcome. “Improve data governance maturity” is not.

This measurement discipline also prevents councils from drifting into scope creep. When a council is accountable for decision velocity, members push back on agenda items that do not require decisions. When a council is accountable for system impact, members prioritize decisions that unblock high-leverage work over decisions that resolve minor process friction. The metrics create guardrails that keep the council focused on governing, not discussing. And when the metrics stop improving, the council has a forcing function to ask whether the structure still serves its purpose or whether it is time to disband and move decision rights into line roles.

The Integration Layer: Why Councils Fail Without Engineering Alignment

Data councils that operate in isolation from ML engineering teams create decisions that sound good in principle but collapse in practice. The failure mode is predictable: the council approves a data quality standard, engineering builds pipelines that meet the standard, and the ML team discovers six weeks later that the standard optimized for reporting accuracy but broke model training because it stripped out the variance the models needed to detect anomalies. The council made a decision. The decision was executed. The outcome was negative because the council did not have line of sight into how the data would actually be used.

This is why even the best data council structure fails without ML engineering teams having clear, aligned success metrics defined upstream. Councils govern data access, quality, and integration. Engineering teams build the pipelines and models that consume that data. If those two layers are not aligned on what success looks like, the council will make technically correct decisions that produce operationally wrong outcomes. The fix is not to expand the council to include ML engineers in every meeting—that creates the coordination bottleneck the council was designed to avoid. The fix is to define shared success metrics that both layers optimize for, and to require every council decision to include an engineering validation step before it gets logged as final.

David Ohnstad has seen this gap close when councils adopt a simple rule: no decision is final until an engineering lead confirms it is feasible within the current architecture and does not introduce latency, cost, or accuracy regressions. That validation step adds 48 hours to the decision cycle. It also prevents councils from approving changes that sound strategic but are structurally unshippable. The councils that skip this step end up with decision logs full of approved initiatives that engineering quietly deprioritizes because they would break production systems. That is governance failure masquerading as governance success, and it erodes trust faster than making no decisions at all.

FAQ: How to Run a Data Council That Drives Decisions

What is the most common reason data councils fail?

Data councils fail most often because they never define what decisions they own versus what they discuss. Without explicit decision rights mapped to specific outcomes, councils become coordination forums where topics get discussed but nothing changes. The fix is assigning Own, Approve, or Consult tiers to every topic in the council’s scope before the first meeting.

How do you measure whether a data council is effective?

Effective data councils track decision velocity (time from submission to resolution), decision durability (percentage unchanged after 90 days), and system impact (measurable improvement in data quality or access speed). Councils that only measure attendance or meeting frequency are tracking inputs, not outcomes, which means they cannot tell whether they are governing or just meeting.

When should a data council be disbanded?

A data council should be paused or disbanded if it has not made a decision that materially changed system behavior in the past 60 days. Councils exist to clarify decision authority and drive action. Once decision rights are embedded in line roles and operational playbooks, the council has succeeded by making itself unnecessary. Councils that operate indefinitely without evolving are organizational debt.

Two Takeaways and One Question

For practitioners: your data council will fail if you treat it as a forum to discuss strategy rather than a body to make decisions. Submit decision memos, not status updates. Ask for specific decision types—Own, Approve, or Consult—so the council knows what action you need. Pre-wire contentious decisions by talking to key members before the meeting. That approach treats the council as a governing body with finite bandwidth, which is what it is.

For leaders: councils are temporary forcing functions, not permanent institutions. Define success criteria before the first meeting, track decision velocity and system impact, and disband the council when decision rights are embedded in line roles. Governance structures that outlive their utility become coordination theater, and theater is expensive. The best council is the one that solves the problem so thoroughly it makes itself redundant.

When was the last time your data council made a decision that someone disagreed with, you moved forward anyway, and the outcome proved the decision was right? If you cannot name one, you are not governing—you are building consensus, which is not the same thing.

For more on this topic, visit David Ohnstad’s woodworking and making.

For more on this topic, see federated data architecture product management.

For more on this topic, see data product manager federated architecture.

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Follow his work at github.com/davidohnstad40-netizen.