A Calendar Is Not a Control

I sat in a change management review this week where a director announced a new policy: all change tickets must be submitted 24 hours before the meeting. No exceptions. Late tickets get rejected. The justification was one sentence: “This is an organizational maturity step we need to take.”

Everyone nodded. Nobody asked the question that actually matters.

Mature compared to what?

Because here is the thing… A blanket 24-hour rule for every department and every change type isn’t a maturity step. It’s a ceremony step. And confusing the two is one of the most expensive mistakes a data leader can make, because ceremony feels like control while providing none of it.

A calendar is not a control. A deadline is not a risk assessment.

The Ceremony Trap

I understand the instinct. When change reviews are chaotic, when tickets show up mid-meeting with no context, when the same three teams keep breaking production, leadership reaches for the one lever that’s easy to pull: process. Make everyone fill out the form. Make everyone wait the same amount of time. Make the meeting orderly.

And the meeting does get more orderly. That’s the trap. The room feels calmer, so leadership concludes the organization got safer.

It didn’t. You changed the paperwork, not the risk.

Ask yourself what a 24-hour lead time actually does to a change. Does it force a better rollback plan? No. Does it verify the blast radius? No. Does it confirm the person approving the change understands the system being changed? Absolutely not. The only thing a flat lead time guarantees is that every change, from a column comment update to a production database migration, waits in the same line.

That’s not governance. That’s a queue.

And the research on this is not ambiguous. DORA’s Accelerate research found that formal approval by an external body, a change advisory board or a senior manager, had a negative impact on delivery performance, and organizations with that kind of process were 2.6 times more likely to be low performers. Worse for the “maturity” argument: they found no evidence that heavyweight external approval reduced change failure rates at all. The UK’s Financial Conduct Authority looked at real CAB data and found boards approving over 90% of everything put in front of them, with some firms not rejecting a single change in a year.

Read that again. The gate approves everything, slows everything, and prevents nothing. If your control never says no, it isn’t a control. It’s a toll booth.

What Maturity Actually Looks Like

Here’s the part that stings if you’re the one who wrote the policy. The frameworks these policies claim to descend from already solved this problem, and they solved it in the opposite direction.

ITIL 4 didn’t just rename “change management” to “change enablement” for marketing. It restructured the entire practice around one idea: the process should match the risk, not the calendar. It defines three types of change, each handled differently:

• Standard changes are pre-approved. Low risk, repeatable, documented in a runbook. They don’t go to a board at all. They just happen, with an audit trail.

• Normal changes get risk assessment and approval scaled to their actual impact.

• Emergency changes get an expedited path, because production doesn’t wait 24 hours to catch fire.

A blanket lead-time rule collapses all three into one. It treats a new data integration landing in a dev catalog the same as a schema change to the table your CFO’s dashboard reads. One of those needs a conversation. The other needs a commit message.

ITIL 4 goes further with a concept most organizations quoting ITIL have never implemented: the Change Authority. The person or group who approves a change should be the one closest to its risk. A delegated team. A peer review. An automated pipeline check. The framework is blunt about it: there is no point in convening a board to assess low-risk items that can be approved locally. Decentralized approval is standard practice in high-velocity organizations, and peer review is one of the strongest predictors of high performance in the research.

So when the maturity conversation comes up, here is the actual maturity ladder:

Immature: No process. Cowboys pushing to prod. Tribal knowledge as change log.

Ceremonial: One process for everything. Flat lead times. A board that approves 90% of what it sees. Feels safe. Isn’t.

Mature: Risk-tiered process. Pre-approved standard changes. Change authority sitting with the owner who can actually evaluate the change. The board reserved for what genuinely crosses boundaries.

Most organizations announcing “maturity steps” are climbing from rung one to rung two and declaring victory. Rung two is not the destination. Rung two is where careers go to wait in line.

“Should Data Teams Even Be in IT Change Control?”

I hear this question from data leaders constantly, usually right after a policy like the one above lands on their teams. And I want to be careful here, because the tempting answer is the wrong one.

The tempting answer is: no, data is different, exempt us.

Wrong. If you’ve read The Medallion Masterclass, you know where I stand: governance is the architecture. A data team that exits change control entirely is a data team building the next un-auditable swamp. When the regulator or the CFO comes asking who changed the revenue logic and when, “we’re exempt from change management” is a resignation letter with extra steps.

The right answer is more precise. Data changes belong under change enablement. They do not belong under a generic IT change authority that can’t tell a Delta table from a dinner table.

Think about what the enterprise CAB is actually competent to evaluate. Network changes, server patches, firewall rules. Now hand that same room a ticket that says “backfilling SCD Type 2 history for the customer dimension using Change Data Feed.” What is that room going to do with it?

Approve it. Obviously. They approve everything. Which means the approval is worthless as a control, and the 24-hour wait was pure cost.

Meanwhile the person who could actually catch the problem, the data platform owner who knows that backfill touches the table feeding three executive dashboards, was never meaningfully in the loop. The ceremony ran. The risk walked straight through it.

A signature from someone who can’t evaluate the change isn’t governance. It’s liability laundering.

The Change Lane Protocol

So if you’re the director, or you’re the data leader who has to counter-propose to the director, here is what the actual maturity step looks like. Not a memo. A structure.

1. Classify before you schedule. Every change gets typed first: standard, normal, or emergency. This is the step the 24-hour rule skips entirely, and it’s the step that does all the work. A change you can’t classify is a change nobody understands well enough to approve anyway.

2. Split the review into lanes with named owners. Infrastructure lane, application lane, data platform lane. Each lane has one Change Authority: the director or manager who owns that domain and its blast radius. That person approves normal changes in their lane, because they’re the only one qualified to. Accountability follows competence, not org-chart altitude.

3. Set lead times by risk tier, not by meeting cadence. A high-risk normal change touching regulated data? Give it 48 hours and a real review, longer than the blanket rule, because it deserves it. A net-new integration landing in an isolated dev environment? Same-day, peer-reviewed. The lead time is a function of what could go wrong, not of when the meeting happens to be.

4. Pre-approve the repeatable. Build the runbook for standard changes once, review it hard once, then let those changes flow with an automated audit trail. Every standard change you pre-approve is meeting time returned to the changes that actually need human judgment.

5. Demote the board from gatekeeper to coordinator. The cross-functional meeting still exists, and it still matters. Its job is scheduling conflicts, cross-lane dependencies, and the rare change big enough to need multiple owners in one room. It advises and coordinates. It stops pretending to be a control for changes it cannot evaluate.

Notice what every step has in common. None of them can be executed by policy memo. Each one requires someone who can look at a change and correctly judge its blast radius, which means each one requires someone who has watched changes go wrong. Risk classification done by people who’ve never seen the failure mode is just the ceremony trap with better vocabulary.

The Verdict

The director in that meeting wasn’t wrong that the organization needed a maturity step. The diagnosis was right. The prescription was a placebo.

Maturity is not how long a ticket waits. Maturity is whether the person approving the change could have caught the failure. A 24-hour rule optimizes the first and does nothing for the second, and the second is the only one that shows up in your incident count, your audit findings, and your cloud bill.

Stop measuring your governance by how orderly the meeting feels. Start measuring it by a harder question: when was the last time this process actually caught something?

If the answer is “never,” you don’t have a control. You have a calendar.

---

If your organization is bolting ceremony onto its data platform and calling it governance, that’s exactly the kind of structural problem Gambill Data untangles. We’ll map your change flow to actual risk, put authority where the competence lives, and give your board a job it can actually do. Book a strategy call.

And if you’re the engineer stuck on the receiving end of these policies, wondering how to push back without torching your standing: that companion piece is coming. It enters this story where you do, when the memo hits your inbox.