Part 7 · 1 chapters · ~8 min

Cross-Team Dependencies and Planning

Making dependencies visible early, dependency mapping in quarterly planning, negotiating with other teams' roadmaps, contracts and stubs to decouple timelines, escalation without blame, tracking cross-team work, and the staff engineer's role in large initiatives.

Dependencies surface early or late, never not

practice	how it helps
dependency mapping at planning	each initiative lists what it needs from other teams, by when; owners confirm or decline before the quarter starts
agree contracts first	an API or event schema agreed in week 1 lets both teams build in parallel against stubs and contract tests
one accountable lead for cross-team initiatives	someone owns the whole outcome, not just their team's slice
weekly written status	green, yellow, red with the reason and the ask; red means "here is what I need"
escalate the trade-off, not the people	"Team B can deliver X or Y this quarter; which matters more?" goes to whoever owns both priorities

code

initiative: instant payouts (Q1)
  needs  ledger-team:   hold API v2 with expiry          by wk 3   status: confirmed
  needs  risk-team:     real-time limit check < 50 ms    by wk 6   status: DECLINED (capacity)
         → escalated wk 1: risk lead + payments director choose: delay fraud rules v3, or ship payouts with static limits
         → decision wk 2: static limits for launch, real-time in Q2 (recorded in ADR-231)

A staff engineer's leverage in large organisations often lies here: finding the dependency nobody listed, writing the contract that unblocks two teams, and making the trade-off explicit so the right person can decide.