Fictional teaching case. A product team prepares for a new learning portal launch. Design believes engineering owns the decision to release, engineering expects operations to approve, and operations assumes marketing has final authority. Each team completes its tasks, but no one coordinates the cross-functional readiness decision.
The core idea
Two days before launch, a payment-flow defect is identified. Engineering recommends a delay; marketing wants to keep the announced date; customer service is worried about support volume. Emails multiply. No one can determine who has authority to accept the risk or pause the launch.
How to apply it
- List the decisions that require clear accountability: release approval, defect acceptance, communication and rollback.
- Map the relevant roles using a simple RACI or decision-rights table.
- Check which approvals are mandatory because of legal, privacy, technical or contractual requirements.
- Call a time-boxed meeting with the actual decision owner and the evidence needed to decide.
- Document the decision, alternatives, rationale, conditions and communication owner.
A workplace example
The team agrees to pause the launch for 48 hours while testing the defect fix. One named accountable leader signs off against documented release criteria. Marketing sends an accurate update and customer service prepares a revised support brief. The delay is inconvenient but no longer an unmanaged surprise.
What to watch out for
This case does not imply that one person may override legal or technical controls. Accountability differs by decision type. The deeper failure was not low effort—it was an unclear governance interface that became visible only under pressure.
Practice and reflect
If you were the project sponsor, which three decisions would you clarify before the next milestone?