You've spent this course settling definitions, naming owners, and mapping the cast around a dataset. Now comes the part that quietly decides whether any of that survives contact with real people: the stories your colleagues tell themselves about what governance is. Two myths stall more rollouts than any technical gap. The first is that governance belongs to IT. The second is that it's bureaucratic red tape. In this unit you'll learn to spot both in conversation and turn them around without sounding defensive.

The most common myth you'll hear sounds perfectly reasonable: "Data is technical, so governance is IT's job." You'll catch it in small phrasing. When someone says "just have IT decide what 'active customer' means," or "file a ticket and let the data team fix the definition," that's the tell. They've quietly handed a business question to the people who keep the systems running.

Here's the plain-language correction. The business defines what data means; IT supports the environment where it lives. Remember the custodian from the last unit, the role that manages the technical home and keeps it secured? That's IT's lane. But whether revenue counts refunds, or whether a churned customer is gone after 30 or 90 days, is a business call. No engineer can answer it without asking the business first. So when the myth surfaces, your move is to gently relocate the question: "IT can store and secure this, but the meaning is ours to decide. Who in the business should own that call?"

The second myth is louder and more emotional: governance is red tape that slows people down. You can't argue someone out of a feeling, and you shouldn't try. The coaching move is to acknowledge the frustration first, then reframe governance as the thing that removes the rework they already hate.

• Milo: Honestly, this standardization push feels like bureaucracy. We move fast, and now there's a process in the way.
• Nova: I get it, nobody wants more gates. Quick question though: how often does your team rebuild a report because Finance and Marketing disagree on the number?
• Milo: Every month, basically. It's a nightmare before each review.
• Nova: That monthly nightmare is exactly what one agreed definition kills. Governance isn't a gate here, it's what stops the do-over.
• Milo: Okay, if it actually ends the do-overs, I'm listening.

Notice what Nova did not do: she didn't defend "process" in the abstract. She tied the reframe to a concrete pain the person already carries. That's the whole pattern. Governance earns the "enabler" label only when you name a rework, a reopened argument, or a fire drill it prevents, and then connect the standard directly to that relief.

Even after a good reframe, you'll meet people who dig in, often the influential ones whose reaction everyone else copies. Resistance is rarely about governance itself; it's usually a fear underneath, most often "this will slow my work." Your job is to surface that fear, not steamroll it. Stay curious and ask "What are you worried this adds to your week?", then let them answer. Validate it honestly, because the fear is usually legitimate. Then reframe toward the surprises governance prevents, like a launch derailed at the last minute because a number couldn't be trusted.

The behavior that actually moves a team is shrinking the ask. Don't request buy-in to a whole program; offer one small, shared responsibility a person can own, like agreeing to use a single definition or flagging issues to a named steward instead of quietly working around them. Shared responsibility spreads when it feels light and self-interested, not when it's mandated from above.

The single takeaway: governance sticks only when the business owns the meaning and people experience it as relief from rework rather than a new gate. Three practices sit ahead of you. First a quick self-check to spot when a scenario quietly dumps a business decision on IT, then a memo where you'll reframe red tape into a concrete win for a skeptical team, and finally a live conversation with a resistant colleague where the reframe gets tested under real pressure. As you go, keep reaching for the move you just saw: name the pain first, then connect the standard to the relief.