Data stewardship programs have been a fixture of enterprise data governance for over a decade now. The patterns are familiar: identify business domain owners, assign stewards within those domains, build a RACI matrix, hold regular forums, document policies. Most large organisations have done some version of this.

What’s less familiar is honest reflection on which of these programs have produced material improvements in data quality, lineage clarity, and decision-making, versus which have produced documentation, meeting cadences, and the appearance of governance without substantive change.

Having worked with about a dozen stewardship programs over the last several years, I can identify some patterns that distinguish the two outcomes. None of these are revolutionary, but several of them aren’t what the standard governance literature emphasises.

The Pattern That Predicts Success Most Strongly

The strongest predictor of whether a stewardship program produces real outcomes is whether the stewards have authority that matches their responsibility.

This sounds obvious. In practice, most stewardship programs assign responsibility without commensurate authority. A steward is held accountable for data quality in a domain but doesn’t control the systems that produce the data, doesn’t control the budget for remediation, and can’t compel changes from the business processes that introduce quality issues.

Programs that work either give stewards meaningful authority—budget, decision rights over system changes, escalation paths with teeth—or they redefine the steward role to match the authority that’s actually available. The failure mode is the middle ground where stewards have title and responsibility without the ability to act.

In one successful program I observed at a financial services firm, stewards had explicit authority to delay system changes that would impact their data domains. This wasn’t popular initially, but it created a real conversation about data quality at the point of change rather than after the fact. Quality metrics improved meaningfully over 18 months.

In a less successful program at a healthcare provider, stewards had no such authority and were expected to influence outcomes through advocacy. After three years, the program produced detailed documentation of data quality issues but limited improvement in the underlying systems.

The Time Allocation Question Nobody Wants to Discuss

Most stewardship roles are assigned as additional responsibilities on top of existing day jobs. The expected time commitment is usually stated as “10-20% of role” or similar.

This nearly always undercounts what’s actually required. In programs I’ve measured time commitment in, effective stewardship for a meaningful domain typically requires 25-40% of a senior person’s time. When that time isn’t available, the steward role becomes performative—attending meetings, signing off on documents, but not doing the substantive analytical and coordination work that produces outcomes.

The honest fix is one of two things. Either the role is structured as a meaningful percentage of someone’s role with explicit relief from other responsibilities, or the steward role is consolidated into a smaller number of dedicated positions rather than spread across more part-time stewards.

The trend I’ve seen in the last two years is toward consolidation. Programs that started with twenty part-time stewards across a large organisation are restructuring into five to eight dedicated stewardship professionals with broader domains. The total people-time involved is similar; the effectiveness is dramatically different.

The Domain Definition Problem

How you define stewardship domains matters more than people credit.

Domains defined by organisational structure—the marketing data domain, the sales data domain—tend to fail because data doesn’t respect organisational boundaries. Customer data is jointly produced and consumed by multiple functions. Assigning a steward to “customer data in marketing” creates a permanent boundary dispute with whoever owns “customer data in sales.”

Domains defined by data lifecycle or system tend to work better. The customer master data steward, regardless of organisational function, has clearer scope. The order management data steward owns everything happening in the order management system, regardless of which business function is consuming it.

The best programs I’ve seen use domain definitions oriented around specific datasets or data products, not around organisational structure. This requires more upfront work to define and sometimes some political navigation, but the resulting clarity is worth the effort.

The Data Management Association’s recent guidance on data product orientation provides reasonable starting points for this kind of domain definition, though the practical work of applying it in a specific organisation requires significant local judgment.

What Effective Stewards Actually Do Daily

When I’ve observed stewards in successful programs, the work they’re doing is more operational than the title suggests.

They’re triaging issues that get raised against their domain—incoming data quality complaints, requests for clarification on data definitions, requests for new datasets or modifications.

They’re doing analytical work on usage patterns and quality metrics, often hands-on with the data rather than just reviewing dashboards built by others.

They’re embedded in project work where their domain is affected—not as approvers at the end, but as participants throughout. This is where the authority question matters most. Participating without authority is observation; participating with authority is governance.

They’re maintaining relationships with both the consumers and producers of data in their domain. This is the relationship-building work that documentation can never replace.

In programs that aren’t working, stewards’ daily work looks different. They’re attending governance forums, reviewing documents produced by others, and reporting on metrics whose underlying problems they can’t actually influence. The work feels important but doesn’t change outcomes.

The Technology Question

A common failure mode is investing in stewardship technology before clarifying the operational model. Data catalogues, data quality tools, lineage tools, and governance platforms are valuable, but only if the human processes they support are well-designed.

The right sequencing, in my experience, is to invest in clarifying stewardship roles and accountability for six to twelve months before tooling. Then select tools that fit the operational model. Then iterate on both together.

Programs that invest in tools first—usually because tooling is easier to procure than organisational change—often end up with sophisticated platforms that nobody uses because the roles to use them don’t exist properly.

Recommendations for Programs in 2026

If you’re running a stewardship program now and looking at whether it’s working, three questions are diagnostic.

Are your stewards making decisions that materially change data outcomes, or are they primarily producing documentation? If documentation is the main output, the program is probably performative.

Do your stewards have enough time and authority to do the work, or are they doing what they can squeeze in around their actual day jobs? If it’s the latter, expect modest results regardless of program design.

Are domain boundaries causing more disputes than they’re resolving? If so, the domain definition probably needs revisiting.

The programs that have succeeded over the last decade aren’t following different frameworks than the programs that have failed. They’re following the same frameworks more honestly, with more authority, and with clearer-eyed acceptance of what stewardship work actually requires.

That’s not a satisfying answer, but it’s the honest one. Data governance is a long discipline. The shortcuts that promise faster results almost always cost more time in the medium term than the direct path would have.