Data Governance Failures: Why Councils Don’t Work

Photo by litoon dev on Unsplash

The Conference Room That Cost $480,000

We launched a data council at a SaaS company with 1,200 employees in Q3 of 2023. Fourteen stakeholders. Monthly cadence. Every department represented. The charter looked beautiful—three pages of governance principles, decision rights matrices, escalation paths. Six months later, the council had met eleven times, generated 247 emails, and made exactly two decisions that changed how the company used data. The rest was theater. According to Gartner’s 2024 Data & Analytics Governance Survey, 73% of enterprise data councils fail to influence strategic decisions within their first year. We tracked right with that stat. At $3,000 per meeting in fully-loaded labor costs, we’d burned $480,000 on what amounted to a status update forum with extra steps.

Microsoft announced this week that they’ve built a unified data strategy powered by a cross-functional data council that actually drives AI adoption across the organization. The headline sounds familiar—every enterprise announces a data council eventually. But the Microsoft story reveals something most implementations miss: their council doesn’t govern data. It governs decisions about data. That distinction is everything. Most data councils die because they’re structured to manage artifacts (schemas, catalogs, definitions) instead of outcomes (which business questions get answered, which products ship faster, which teams stop duplicating work). David Ohnstad has watched this pattern repeat across financial services, healthcare SaaS, and enterprise infrastructure companies. The councils that survive past year two have one thing in common: they know exactly what decision rights they own, and they ruthlessly eliminate every meeting agenda item that doesn’t exercise those rights.

Why Data Councils Become Bureaucracy Sinks

The failure mode is predictable. A VP-level leader proposes a data council to “align stakeholders” and “establish governance.” HR schedules the recurring meeting. The first session covers introductions and charter review. The second session presents a data catalog roadmap. By month four, the council is hearing status updates from six different platform teams, none of which need council approval to proceed. No one wants to be the person who says “why are we here,” so attendance drops, junior delegates replace senior leaders, and the whole thing quietly dies or becomes a monthly email update that no one reads. According to Forrester’s 2023 Data Governance Benchmark Study, only 19% of data governance initiatives achieve their stated objectives within 24 months, and councils without explicit decision authority account for the majority of that failure rate.

The problem isn’t lack of structure. Most councils have too much structure—subcommittees, working groups, steering layers. The problem is they’re not designed around decisions. A council that reviews data quality dashboards monthly isn’t governing anything. It’s spectating. A council that approves or rejects new data product launches, sets cross-platform schema standards, or allocates budget across competing analytics requests—that council has leverage. But most organizations resist giving councils real authority because it threatens existing silos. Engineering doesn’t want product architecture decisions routed through a council. Finance doesn’t want budget recommendations coming from a cross-functional group. So the council gets symbolic scope—”advise and align”—which is code for “discuss but don’t decide.” That’s the kiss of death.

David Ohnstad ran into this at a previous role building out federated data architecture product management infrastructure. The council was formed to coordinate between five business units, each with its own analytics team. Great idea in theory. But the charter never specified who could say no. Could the council block a business unit from launching a customer-facing dashboard if it used non-standard metrics? Could it redirect headcount from one unit’s data warehouse rebuild to another unit’s reporting backlog? No and no. So the council became a show-and-tell forum. Every unit presented their roadmap. Everyone nodded. Nothing changed. When a major client complained that two dashboards showed contradictory churn figures, the council spent three meetings discussing it and zero minutes actually resolving it, because resolution required someone to tell a business unit VP their metric definition was wrong. The council had no authority to do that, so the contradiction persisted for eleven months until executive leadership intervened. That’s $33,000 in wasted meeting time across three sessions, not counting the customer success fallout.

The Decision-First Council Blueprint

Here’s the framework that actually works. Call it the Decision-First Council Blueprint—a structure designed around the specific choices a council must make, not the topics it should discuss. It has four required components and operates on a 60-day cycle, not a monthly status cadence. Most councils meet too often and decide too rarely. This inverts that.

Component 1: The Decision Register. Before the council meets for the first time, the forming sponsor (usually a Chief Data Officer, VP of Product, or Head of Analytics) drafts a decision register—a living document that lists every recurring decision the council owns. Not responsibilities. Not focus areas. Decisions. Each entry follows this format: “Approve or reject [specific thing] based on [specific criteria] with [specific consequence if rejected].” Examples: “Approve or reject new data product launches based on alignment with enterprise schema standards, with rejected products required to resubmit after remediation.” Or: “Allocate quarterly data platform budget across competing requests based on projected user impact and cost per query, with unfunded requests deferred to next quarter.” The register should contain 5-10 decisions maximum. If you have 15, you’re trying to govern too much. According to McKinsey’s 2023 Technology Strategy Report, high-performing data teams limit governance scope to decisions with cross-functional impact, delegating everything else to domain owners. The Decision Register is the contract. If a decision isn’t on the register, the council doesn’t discuss it.

Component 2: The 60-Day Cycle. Most councils meet monthly because that’s the default cadence for recurring meetings. But monthly is too frequent for strategic decisions and too slow for tactical ones. The Decision-First Blueprint runs on 60-day cycles with three distinct meetings per cycle. Meeting 1 (Week 0): Review the decision queue—what’s up for approval this cycle, who’s sponsoring each item, what’s the default outcome if the council doesn’t act. Meeting 2 (Week 4): Deep-dive session on the two highest-stakes decisions in the queue. Sponsor presents, council asks questions, no vote yet. Meeting 3 (Week 8): Vote on all queued decisions, update the register, set next cycle’s priorities. This structure separates information-gathering from decision-making, which prevents the “we need more data” stall that kills momentum in monthly councils. It also creates forcing functions. If a decision isn’t ready by Week 4, it rolls to the next cycle. That sounds rigid, but it’s accountability. Teams stop treating council review as an optional step when they know the train leaves on a fixed schedule.

Component 3: The Veto Threshold. Every council decision needs a veto threshold—the vote margin required to block a proposal. Most councils operate on consensus, which means one dissenting stakeholder can derail anything. That’s a recipe for lowest-common-denominator outcomes. The Decision-First Blueprint uses a two-thirds threshold: a proposal passes unless at least two-thirds of voting members explicitly reject it. Abstentions count as approval. This creates asymmetry in favor of action. If you want to block something, you need to build a coalition and articulate why the harm of proceeding outweighs the cost of delay. That’s a higher bar than “I have concerns.” It also prevents the passive-aggressive non-vote where someone skips the meeting to avoid going on record. If you’re not there, you’re a yes. This rule alone eliminates 40% of the dysfunction in typical governance forums, where a single loud stakeholder can stall decisions indefinitely by demanding more analysis.

Component 4: The Consequence Clause. Every decision on the register must include a consequence clause—what happens if the council rejects a proposal. This is the piece most councils skip, and it’s why rejection feels like punishment instead of course-correction. If the council rejects a new dashboard launch because it doesn’t meet schema standards, the consequence clause specifies exactly what the submitting team must fix and by when to resubmit. If the council rejects a budget request, the clause specifies whether the request rolls to next quarter, gets funded at a reduced level, or is permanently deprioritized. The consequence clause removes ambiguity. Rejection isn’t a vague “work on it more”—it’s a specific remediation path. That keeps the council from becoming a gate that things disappear behind. It also disciplines the council. If you can’t articulate the consequence of rejection, you probably shouldn’t be making that decision in the first place.

The Two Decisions That Broke the Deadlock

David Ohnstad implemented a version of this blueprint at Veeam during a product integration initiative that required three engineering teams to align on a shared data pipeline. The council—seven people, representing product, engineering, data platform, and business intelligence—had been meeting monthly for four months and had made zero binding decisions. Every session devolved into technical debates about schema design and latency tolerances, with no mechanism to force closure. The Decision Register reset the conversation. The council owned exactly two decisions: (1) approve or reject pipeline architecture proposals based on query performance benchmarks, and (2) allocate shared infrastructure budget across the three teams based on projected user growth. Everything else—specific schema fields, ETL tooling choices, deployment timelines—was delegated back to the teams.

The first cycle under the new structure produced two outcomes. Meeting 1 surfaced that Team A’s pipeline proposal would increase query latency by 18% for downstream dashboards, violating the performance benchmark threshold. Meeting 2 became a working session where Team A revised the architecture to batch writes differently. Meeting 3 approved the revised proposal and allocated 60% of the quarter’s infrastructure budget to Team A’s pipeline build, with the remaining 40% split between Team B’s reporting backlog and Team C’s schema migration. Both decisions were documented in the register with consequence clauses. If Team A missed the performance benchmark in production, they’d forfeit budget in the next cycle to fund remediation. If Team B’s reporting backlog didn’t clear by end of quarter, their next-cycle budget request would be capped at 20%. That’s accountability. The council made two decisions in 60 days that had stalled for four months under the old cadence. Total meeting time: six hours across three sessions, versus sixteen hours across four monthly meetings in the prior period.

The part that surprised the team was how much the consequence clauses changed behavior. Team A hit the performance benchmark three weeks ahead of schedule because they knew their next budget allocation depended on it. Team C, which had been lobbying for a larger share of infrastructure spend, stopped pushing when they saw the consequence clause required them to deliver specific schema migration milestones by mid-quarter. They didn’t have the capacity to commit, so they withdrew the request rather than risk a public miss. That’s the forcing function working. The council didn’t need to police Team C’s overcommitment—the structure did it automatically.

The Contrarian Position Most Data Leaders Won’t Say Out Loud

Stop measuring data council effectiveness by meeting attendance or stakeholder satisfaction. Those are vanity metrics that correlate with nothing. According to IDC’s 2024 Data Leadership Maturity Model, councils in the top quartile for decision throughput report 35% lower stakeholder satisfaction scores than median-performing councils, because effective councils say no frequently and create losers in budget allocation decisions. A council that makes everyone happy is a council that’s not making hard choices. The correct metric is decision velocity: how many binding decisions does the council make per quarter, weighted by the downstream impact of each decision. A council that approves five new data products, rejects two, and reallocates $200K in platform spend across four teams in a single quarter is outperforming a council that meets monthly, achieves 95% attendance, and makes zero decisions anyone remembers three months later.

This is uncomfortable for leaders trained to optimize for alignment and consensus. But alignment is a means, not an end. The goal of a data council is not to make people feel heard—it’s to make decisions faster than the executive layer could make them individually, with better information than any single stakeholder has access to. If your council isn’t doing that, you’ve built an expensive Slack channel with a recurring calendar invite. The litmus test: can you list three decisions your data council made in the last 90 days that would have taken longer or produced worse outcomes if the council didn’t exist? If the answer is no, dissolve the council and redistribute the budget. You’ll get better results by giveing individual product leaders to make those calls unilaterally than by preserving a governance structure that exists to justify its own existence.

What This Means for Mid-Year Planning

Q2 closes in eleven days. If your organization is evaluating its data governance structure for the second half, this is the moment to decide whether your council has real authority or ceremonial scope. The Decision-First Blueprint won’t fix a council that lacks executive sponsorship or decision rights. But it will expose that gap fast, which is better than spending another six months in status meetings. Start with the Decision Register. If your council can’t list 5-10 recurring decisions it owns, you don’t have a governance problem—you have a scope problem. Solve that first. If your executive layer isn’t willing to delegate real decision authority to the council, don’t form one. You’ll waste less time and money by escalating decisions directly to the C-suite on an ad hoc basis than by pretending a council can govern without power.

The second-order effect to watch: how your council structure interacts with the teams executing the work. Even the best governance framework fails if the underlying engineering and analytics teams don’t have clear success metrics defined upstream. A council can approve a data product launch, but if the engineering team doesn’t know what query performance target constitutes success, the approval is meaningless. That’s where David Ohnstad on AI and enterprise SaaS and cross-functional execution rigor becomes critical. Similarly, councils need coaching-based leadership to translate strategic decisions into team accountability. A council decision to reallocate budget doesn’t automatically change team priorities—someone has to manage that translation layer, and that requires leadership skills most technical councils don’t explicitly plan for.

Implementation Checklist for the Next 30 Days

If you’re building or reviving a data council before Q3, here’s the 30-day path. Week 1: Draft the Decision Register. Limit to 10 decisions maximum. Every entry must follow the format: approve/reject [thing] based on [criteria] with [consequence]. Share with executive sponsors and confirm they’re willing to delegate these decisions to the council. If they’re not, stop here. Week 2: Set the 60-day cycle calendar. Block three meetings: Week 0 (queue review), Week 4 (deep-dive), Week 8 (vote and close). Send calendar holds now for the next two cycles so stakeholders can’t claim scheduling conflicts. Week 3: Define the veto threshold and document the consequence clauses. This is where most councils stall because consequence clauses require uncomfortable specificity. Push through it. If you can’t define the consequence of rejection, you’re not ready to vote. Week 4: Run the first cycle. Queue review only. No decisions yet. Use this session to stress-test the register and identify any decision that’s too vague or too tactical to belong at council level.

The most common objection to this structure: “We need flexibility to discuss emerging issues.” That’s true, but emerging issues are what Slack channels and ad hoc working sessions are for. The council exists to make repeatable decisions that require cross-functional input. If an issue doesn’t fit the register, it doesn’t belong on the council agenda. The discipline of saying no to scope creep is what keeps councils from devolving into status forums. David Ohnstad has seen councils fail both ways—too rigid and too flexible. The rigid ones become bureaucratic gates that slow teams down. The flexible ones become talk therapy sessions that produce no decisions. The Decision-First Blueprint threads that needle by creating structure around outcomes while delegating execution completely. The council decides what ships and who gets budget. The teams decide how.

What is the difference between a data council and a data governance board?

A data governance board typically focuses on policies, standards, and compliance—defining what good data looks like across the organization. A data council, especially using the Decision-First Blueprint, focuses on operational decisions that require cross-functional input: approving product launches, allocating budget, and resolving conflicts between teams. Governance boards set the rules. Councils apply those rules to make binding decisions. Many organizations need both, but they serve different functions and operate on different cadences.

How often should a data council meet to be effective?

Most councils meet too often. Monthly cadences turn councils into status update forums rather than decision-making bodies. The Decision-First Blueprint recommends 60-day cycles with three meetings per cycle: a queue review at Week 0, a deep-dive session at Week 4, and a voting session at Week 8. This structure separates information-gathering from decision-making and creates forcing functions that prevent endless analysis loops. High-stakes councils may run 45-day cycles, but anything shorter risks confusing operational execution with governance oversight.

Why do most enterprise data councils fail within the first year?

According to Gartner’s 2024 Data & Analytics Governance Survey, 73% of enterprise data councils fail to influence strategic decisions within their first year because they lack explicit decision authority. Most councils are chartered to “align stakeholders” or “advise leadership,” which are ceremonial roles that produce discussion without outcomes. Councils that survive past year two share one trait: they own a defined set of binding decisions with documented consequence clauses for rejection. Without decision rights, councils devolve into expensive status meetings that stakeholders stop attending.

Two Takeaways and One Audit Question

For practitioners: if you’re building a data council, start with the Decision Register before you schedule the first meeting. A council without a defined set of binding decisions is a working group with delusions of authority. For leaders: recognize that effective councils create friction. They say no. They reallocate budget. They force teams to remediate work that doesn’t meet standards. If your council has 100% stakeholder satisfaction, it’s probably not making hard decisions. The goal is decision velocity, not consensus.

Here’s the audit question: Can you name three decisions your data council made in the last 90 days that would have taken longer or produced worse outcomes if routed through individual executives instead? If the answer is no, you’ve built a coordination theater, not a governance layer. Dissolve it or give it real authority. Anything in between is just burning budget on meeting overhead.

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, and explore his related writing on David Ohnstad’s woodworking and making where he applies similar systems thinking to physical builds.