Stakeholder Communication and the Steering Committee
Estimated read: 3 min
A dependency graph and a risk register are how the migration team tracks the migration. A steering committee is how everyone outside the migration team – finance leadership, the business users whose trust gate this whole program is ultimately trying to earn, the platform team footing the Databricks bill – gets a shared, current picture of where things stand, without pulling engineers off the work to explain it verbally on demand.
The committee itself should be small and specific rather than a broad invite list: a technical sponsor (usually the migration lead) who reports status, a business sponsor per major domain (finance, ops, whoever owns the workload being migrated) who owns the trust-gate sign-off from that domain, someone from platform/FinOps who speaks to cost against the projected TCO, and a decision-maker with actual authority to approve a cutover or authorize a rollback. A steering committee with no one in the room who can say yes to a cutover decision is a status meeting, not a steering committee.
Communication has to happen at two different cadences, because a weekly summary and an incident alert are not the same kind of message:
- Scheduled status, typically weekly during active phases: progress against the runbook’s phases, the current state of the risk register (what’s newly opened, what’s been mitigated, what’s still open), and reconciliation pass rates by domain. This is a dashboard-driven update – pulling directly from the same
system.billing.usage-style tables and reconciliation logs covered in earlier sections, not a hand-assembled slide deck that’s stale the moment someone asks a follow-up question. - Trigger-based escalation, which happens the moment a risk register entry’s mitigation trigger fires – a domain’s conversion running 50% over estimate, a reconciliation that’s stayed non-zero for more than a set number of days. This message goes to the steering committee immediately, not folded into next week’s status update, because the whole point of naming a trigger in advance is to shorten the gap between a problem occurring and the people who can act on it hearing about it.
The most common failure in stakeholder communication isn’t too little information – it’s a status update so padded with reassurance that the one risk that actually matters is buried on slide fourteen. A steering committee update should lead with what’s at risk, not with what’s going well.
With the committee structure and cadence established, the next lecture covers the specific mechanism the committee approves at the cutover decision point: the 72-hour rollback window that defines exactly how far back the program can walk if the cutover doesn’t hold.
| ← Previous: The Risk Register: Naming Every Way It Can Fail | Next: The 72-Hour Rollback Window → | |:—|—:|