Managing Cross-Team Dependencies

Scenario

Example organisation: the payments team needs a new field from the identity team's API for a compliance launch. They ask in a Slack channel two weeks before the deadline. The identity team's quarter is already planned. The launch slips a month.

What you see on the team

• Blockers on other teams discovered late, usually near deadlines.
• Requests made through chat, without owners or dates.
• Teams waiting on each other in a chain; each blames the next.
• The same kind of request (a new API field, a new permission) every quarter.

The common mistake

Treating dependencies as favours requested ad hoc instead of planned, explicit agreements — and never working to remove the recurring ones.

Why it happens

Each team plans its own backlog; work needed by others isn't visible until someone asks. Requests through chat have no owner or deadline. Recurring dependencies often mirror the organisation: Conway's law observes that systems tend to reflect the communication structure of the organisations that build them, so team boundaries and system boundaries need to fit.

The playbook

1. Map dependencies at planning time. For each initiative, list: what we need from whom, by when, and what we provide to others.

2. Agree explicitly, in the other team's planning process, with an owner and a date — not in a chat thread.

3. Design to decouple:

• agree the interface (contract, schema) first; build against a stub or mock;
• prefer self-service: an API or config the other team exposes once, instead of a change per request;
• put the riskiest dependency in the earliest slice.

4. Track dependencies visibly (a short list in the planning doc), and raise risks early.

5. Reduce recurring dependencies: if you need the same team for every launch, propose a self-service capability or a change in ownership.

What to say

To another team's tech lead, at planning time:

"For the Q3 compliance launch we need verified_at on the identity API by 15 August. Could we get it into your planning? We can draft the schema change and the PR if that helps — we'd just need your review and release. Who would be the owner on your side?"

Raising a risk early:

"The identity change hasn't been scheduled yet, and our launch depends on it. If it's not planned by Friday, our launch date moves by at least three weeks. Can we decide this week?"

Trade-offs

• Contributing code to another team's service speeds things up but needs their review and ownership agreement.
• Self-service platforms take investment from the providing team; worth it for frequent requests.
• Over-planning dependencies slows small work; focus on cross-team items on the critical path.

Signals it's working

• Dependencies appear in planning documents, with owners and dates.
• Fewer late surprises; risks are raised weeks ahead.
• Recurring requests decline as self-service capabilities appear.
• Teams describe each other as partners, not blockers.

Key points

• Map dependencies at planning time: what, from whom, by when, and what you provide.
• Agree them in the other team's planning, with owners and dates — not in chat.
• Agree interfaces first and build against stubs; put risky dependencies early.
• Reduce recurring dependencies with self-service or ownership changes.