Free Cross-Team Dependency Declaration Template

A cross-team dependency declaration is the document one team writes when their work depends on something another team has to ship. It is not a Jira ticket. It is not a roadmap callout. It is a structured asks-and-asks-of document that names what is needed, by when, what the consequence is if the dependency slips, and what the cost is to the dependency-providing team. Teams that adopt this pattern stop discovering in week ten that a dependency from week three is not going to land.

The template below is the lean version. It assumes good faith between teams; it is not a contract. The form factor exists to make the dependency legible to both sides, so the slip — when it happens — is a known slip rather than a discovery.

When to use it

• Any team-quarter where one of your deliverables depends on work from another team.
• Anytime you find yourself saying "we are waiting on platform" with no specific commit from platform.
• When a roadmap planning cycle is about to happen and you want to surface dependencies before the plan is locked.
• When a dependency you thought was resolved has come back as a surprise blocker.

The template structure

This is the structure of the template. Copy it into a Notion page, a Linear doc, or a markdown file in your repo — it works in any of them.

CROSS-TEAM DEPENDENCY DECLARATION
ID:          DEP-[NNN]
Declared by: [team]
Declared to: [team]
Date:        [date]
Status:      [proposed / accepted / declined / at-risk / met / missed]

WHAT WE NEED
  One sentence. The specific deliverable.
  Example: "A versioned event schema for billing.invoice_finalized
  exposed on the event bus."

WHY WE NEED IT
  One paragraph. The thing we want to build that depends on this.

WHEN WE NEED IT
  Target date:    [date]
  Hard deadline:  [date — what happens after this]
  Why this date:  [external commitment / launch / quarter end]

WHAT WE WILL DO WITHOUT IT
  Plan B if the dependency does not land:
    - [path]
  Cost of plan B:
    - [time, complexity, customer impact]

ACCEPTANCE CRITERIA
  How will we know it is met?
    [ ] [concrete criterion]
    [ ] [concrete criterion]
    [ ] [concrete criterion]

PROVIDING TEAM SECTION
  (filled in by the dependency-providing team)

  Accepted / Declined / At-risk: [status]
  Committed date:   [date]
  Owner:            [name]
  Effort estimate:  [rough]
  Trade-off:        [what they are NOT doing to do this]
  Notes:            [...]

DURING THE DEPENDENCY
  Mid-point check:  [date — providing team confirms still on track]
  Re-declare if scope or date changes.

WHAT HAPPENS IF IT SLIPS
  The declaring team is told within [N] business days.
  Re-plan happens [where].

How to use it well

• Plan B is the load-bearing field. A dependency without a plan B is not a dependency, it is a wish. Writing the plan B forces the declaring team to be honest about whether the dependency is critical or merely convenient.
• The providing team commits in writing. "We can probably do that" is not a commit. The status field has values that mean something. If the providing team is not ready to commit, the status is at-risk and the declaring team builds plan B.
• Re-declare on scope change. A dependency that changed shape after acceptance is a new dependency. Update or supersede the doc; do not let the original drift silently.
• Mid-point check is mandatory. The mid-point check is the cheapest way to surface a slip while there is still time to react. Without it, slips arrive at the deadline.
• Bring all open dependencies to roadmap planning. The roadmap that does not name its dependencies is a fiction. Use the DEP-NNN IDs as roadmap line items.

What to skip

Skip the temptation to use this for trivial asks. A two-hour code review request is not a dependency declaration. The format has overhead because it earns its keep on dependencies that span weeks. For week-level coordination, a PR comment or a Slack thread is the right tool.

Skip treating a declined dependency as failure. "Declined, with reason" is a much healthier state than "accepted but secretly will not land." A team that declines clearly enables a real plan B; a team that vaguely accepts disables one.

Frequently asked questions

Is this template free?

Yes. The structure above is the template. Many teams keep these in a /dependencies folder per quarter, or in the company's roadmap planning tool.

Can I edit it?

Yes. Add a Compliance Impact row if your dependencies touch regulated code paths. Drop the Mid-point check if your sprints are short enough that mid-points are not meaningful.

Do I need to give my email?

Not for the structure. The downloadable version is just formatted; the email is for our newsletter only.