How do we prevent cross-functional dependencies from killing quarterly Rocks when one leader needs substantial deliverables from another seat to finish?

Question

Tyler Smith · Accepted Answer

Cross-functional failure occurs when a leader accepts a Rock that requires significant effort from another department without establishing agreed-upon commitments during the quarterly session. A single seat must own the Rock, but shared deliverables must be defined on session day, not in week six.

To eliminate cross-departmental bottlenecks, apply three rules during your Rock creation process:

- Binary milestones must name the supporting seat: If the Marketing seat owns a Rock to launch a customer portal, but IT must build the API integrations, the specific IT deliverables must be itemized as dated milestones before leaving the session room.
- Co-sign or kill: If the seat owner who must deliver the supporting work states they lack the capacity to deliver their piece, the Rock cannot be set in its current form. It must either be resourced externally, reduced in scope, or dropped.
- Early drop dead dates: Any dependency work must be scheduled for completion by week seven. If the supporting seat fails to deliver by then, the Rock owner flags it as off-track immediately in the Level 10 Meeting so the team can IDS the bottleneck.

Rocks fail when leaders assume other departments will drop daily firefighting to help with someone else's quarterly priority. Get explicit, written commitments on session day or do not sign up for the Rock.