What Actually Broke in Month 3 of Our Data Stewardship Rollout

Every stewardship rollout looks the same in month one: a series of workshops, a RACI chart, a slide with "data owner" and "data steward" in tidy swim lanes, a room full of nodding heads. I directed an enterprise-wide Alation catalog implementation at a Fortune-200 agriscience company that had exactly that kickoff — cross-functional workshops, unified governance objectives, agreed-upon quality standards and definitions. Plenty gets published about how to design that first month. Almost nothing gets published about what the program looks like three months later, once the workshop energy has worn off and the catalog has to survive contact with how people actually work. Here's what broke, anonymized, and what fixed it — or didn't.

Stewards assigned by org chart, not data proximity

The fastest way to staff a stewardship program is to ask each department head to name a steward. It's also, reliably, a mistake. Org charts group people by reporting line, not by who actually creates, edits, or troubleshoots a given dataset day to day. A director names a steward because that person reports to them and has bandwidth on paper — not because that person has ever opened the table in question.

The pattern I've seen play out, here and elsewhere: the person with the deepest knowledge of a dataset's quirks — the analyst who knows that a "region" field silently changed meaning after a system migration two years ago — has no formal steward title and therefore no mandate, no time allocation, and no visibility in the catalog when someone has a question. Meanwhile the named steward, picked for organizational tidiness, has to go find that analyst anyway every time a real question comes in. The org chart didn't remove the dependency on the person with the knowledge; it just added a layer of indirection in front of them.

What actually helped: re-mapping steward assignments against a simple proximity test — who queries this data weekly, who gets paged when it looks wrong, who wrote the last transformation logic touching it — and re-assigning based on that instead of the department roster. It's a less politically comfortable conversation than "each VP names someone," because it can mean the steward for a dataset is someone several levels below the person who owns the budget for it. It's also the version that survives contact with an actual question in the catalog.

"Steward" as an unfunded second job

Almost nobody's steward responsibilities came with a corresponding reduction in their existing workload. It was added on top, framed as "part of your role now," with no change to headcount, deadlines, or performance goals. For the first few weeks, people showed up because the kickoff was recent and visible. By month three, curation queues were the thing that got deprioritized the moment a real deadline showed up — which was every week.

This is the single most common failure mode I've seen in stewardship programs generally, not specific to any one rollout: governance work competing against billable or deliverable-driven work always loses, unless it's explicitly protected time with its own accountability. Nobody's manager was measuring catalog curation. Everybody's manager was measuring the thing the steward was hired to do before "steward" got added to their plate.

What partially fixed it: converting a portion of steward time into a formally tracked allocation — a fixed number of hours per week that showed up on the same capacity planning tools used for project work, with a named line item their manager could see. It didn't fully solve the problem; curation still competed with deadlines and still lost sometimes. But making the time visible and accounted for, instead of implicitly volunteer, cut the drop-off meaningfully. What didn't work: appeals to the importance of good data. Everyone already agreed data quality mattered in the abstract. Agreement in the abstract doesn't survive a Friday deadline.

Definition debates the workshops didn't settle, resurfacing as edit wars

Workshops are good at generating agreement on definitions that are easy to agree on — "customer," most of the time, is not controversial. Workshops are bad at forcing resolution on the definitions that are genuinely contested across departments, because the room runs out of time and the facilitator (reasonably) moves on rather than let one term consume the whole session. Those unresolved definitions don't disappear. They show up three months later as competing edits inside the catalog itself, with two teams silently overwriting each other's description field for the same asset because they never actually agreed in the room — they just stopped arguing when the workshop ended.

A live example of the shape of this problem: finance and operations each had a defensible definition of what counted as an "active" account, and the workshop notes recorded both without flagging that they conflicted. Three months in, the catalog had a description field that had been edited back and forth four times, each edit a different team quietly asserting its version was correct, with no resolution mechanism and no notification that a conflict was even happening.

The fix that worked: treating unresolved definitions as an explicit backlog item coming out of every workshop, not a silent gap. If a term had two credible definitions in the room, it got logged as "contested — needs executive decision" rather than left ambiguous, and it got escalated to a specific decision-owner with a deadline before it ever went into the catalog as a locked field. Standardizing taxonomy and definitions across departments is exactly the kind of policy work I've done in multi-year governance roadmaps for a large manufacturer — the workshop energy makes people willing to surface disagreement; the mistake is not carrying that disagreement to an actual decision afterward. If you're building the definitions layer that other tooling — including an internal AI assistant — depends on, I go deeper on why that layer has to be solid first in this post on data dictionaries and RAG governance.

Access-request queues routing to people who'd left

This one is mundane and it still cost real time. Access-request workflows in the catalog and in the underlying cloud permissioning — Azure, Databricks, SQL role grants — were configured with named approvers during setup. By month three, a non-trivial share of those approvers had changed roles or left the company, and requests were queuing silently against an inbox nobody was checking. Requesters didn't escalate because they assumed the request was "in review." It wasn't in review. It was invisible.

The fix was structural, not procedural: routing approvals to a role or group mailbox instead of a named individual wherever the access-control platform allowed it, plus a simple staleness check — any request untouched after a set number of days auto-escalates rather than sitting silent. That second part mattered more than it should have. The instinct is to trust that people will flag a stuck request; in practice, most people assume silence means process, not failure, until they've been waiting long enough to be genuinely blocked. If you're comparing catalog and access platforms and want the tradeoffs on this kind of workflow durability before you commit to one, see this post on data governance tool RFPs and TCO for the buy-side considerations.

The metric trap: counting curated assets vs. measuring lookup success

The dashboard everyone defaults to is "number of assets with a description," "percentage of tables tagged," "curation completion rate." It's an easy number to report upward, and it climbs reliably if you push people to fill in fields. It also measures almost nothing about whether the catalog is doing its job. A completed description field is not the same thing as a description someone trusts, and a fully tagged table nobody actually queries doesn't move the needle on the problem the catalog exists to solve.

The metric that mattered more, and that we started tracking alongside the completion numbers: when someone searches the catalog for something, do they find a usable answer, and do they trust it enough to act on it without going around the catalog to ask a person directly. That's a harder number to get cleanly — it requires actually watching search behavior and following up on whether people bypassed the catalog — but it's the number that correlates with the catalog actually reducing the "who do I even ask" problem it was funded to solve. Reporting completion percentage looked like progress every month. Reporting lookup success was the number that occasionally went down, which was uncomfortable, and also the number that was telling the truth. The same logic applies once AI agents start querying the catalog directly instead of humans — a policy built on stale classification data fails the same way a dashboard built on the wrong metric does, which I go into in this post on governing AI agents' data access. It's also the same discipline that matters upstream of the catalog, when you're deciding what "clean" means for incoming records in the first place — see this post on customer MDM intake and data quality.

What would make this wrong

• These patterns come from a rollout in a large, matrixed enterprise with cross-departmental data ownership. A smaller organization with a flatter structure and fewer competing definitions may never hit several of these failure modes at all.
• Some of what "fixed" a problem here was partial, not complete — the unfunded-second-job problem in particular was reduced, not solved, and a different organization's incentive structure might need a heavier intervention than a visible time allocation.
• This is a single anonymized rollout experience, generalized with the pattern language ("a pattern I've seen") where the detail is illustrative rather than a literal, verified data point from that one engagement — treat it as a practitioner's field notes, not a benchmark study.
• Tooling has moved since this rollout; some catalog platforms now have native workflow features — auto-escalation, ownership-change detection — that would blunt one or two of these failures out of the box rather than requiring a manual fix.