How to Set Up Cross-Team Dependency Tracking in Linear
Cross-team dependencies are the leading cause of sprint delays at growth-stage companies. Team A finishes their feature only to discover that Team B, who was supposed to deliver the shared API endpoint, deprioritized it for a hotfix. Linear's dependency tracking features — when properly configured — make these risks visible before they become delays.
This guide covers how to set up cross-team dependency tracking in Linear using issue dependencies, a shared dependency project, and a weekly review workflow.
Step-by-step guide
Enable and use Linear's dependency fields
In Linear, every issue has "Blocks" and "Blocked by" fields. Open an issue, click "Relations" in the right panel, and add a "Blocked by" relation pointing to the upstream issue in another team. The blocked issue shows a blocked indicator in all views. The upstream issue shows that it is blocking a downstream issue. Both teams see this relationship — no separate tracking needed. Establish a team norm: any issue with an external dependency must have a "Blocked by" relation set before sprint planning.
Create a shared Cross-Team Dependencies project
Create a Linear project called "Cross-Team Dependencies [Quarter]" shared across all teams in the workspace. Any issue that represents a dependency deliverable (something another team is waiting on) gets added to this project. The project view shows all inter-team commitments in one place. Use the project's description to list the teams involved and the quarter's key dependencies. EMs from all teams subscribe to this project to get notifications when dependency tickets change status.
Build a dependency health view
Create a workspace-level saved view (not team-level) called "Dependency Health." Filter: Issues in the "Cross-Team Dependencies" project AND (status is not Done OR has "Blocks" relations). Group by Team. This view shows every active cross-team dependency with the teams involved visible at a glance. Sort by Due Date to see which dependencies are at risk of missing their commitment date first. Share this view URL in Slack so any EM can check dependency health without navigating the Linear workspace.
Add due dates and owners to dependency tickets
Every dependency ticket in the shared project must have: a Due Date set to the date the upstream team commits to delivering, an Owner who is the specific engineer responsible (not just the team), a Priority set to match the urgency of the downstream blocker, and a comment explaining what the downstream team is waiting on and why. Without this information, a dependency ticket is just an issue with a label — not an actionable commitment.
Run a weekly dependency review
Add a 15-minute "Dependency Review" to your weekly EM sync. Open the Dependency Health view and walk through: any dependency tickets that changed status this week (did anything get unblocked or newly blocked?), any dependencies due in the next 2 weeks (are they on track?), and any newly added dependencies (does everyone know about them?). This short weekly review catches surprises before they become sprint-day discoveries.
Common mistakes
Dependency tracking that relies on human memory
Teams that manage dependencies through Slack threads and verbal commitments discover blockers at the worst possible moment: sprint planning, when it is too late to adjust. Every cross-team dependency must be formalized as a Linear "Blocked by" relationship before the sprint starts. The "Blocked by" field is the source of truth — not the Slack message from 3 weeks ago.
Dependencies without committed delivery dates
A "Blocked by" relationship with no due date on the upstream ticket means the downstream team does not know when to expect the dependency. Every upstream dependency ticket must have a date the delivering team commits to. If the team cannot commit to a date, the dependency is not real — it is aspirational. Make the ambiguity explicit rather than using a vague dependency.
Resolving blockers without notifying downstream teams
An engineer completes the upstream dependency ticket and moves it to Done without notifying the downstream team. The downstream team discovers the unblocking during their next standup — a day or two of delay. Configure Linear notifications: any engineer on a team with "Blocked by" relations on their issues should be subscribed to status changes on the upstream issues. Linear's notification settings allow this per-user.
Tips
Use Linear's project milestone feature in the Cross-Team Dependencies project to mark key "dependency freeze" dates — the last date a new dependency can be added to the current sprint without disrupting commitments
Add the Cross-Team Dependencies project to your sprint planning agenda as the first agenda item — reviewing the dependency health view before committing sprint capacity prevents the most common cause of sprint failures
Create a Linear automation: when an issue in the shared dependencies project is moved to Done, automatically post a notification to the #engineering Slack channel tagging the teams that had "Blocked by" relationships on it — this ensures unblocking events are visible immediately
How Vantage helps
Cross-team dependencies in Linear create the execution complexity that product roadmaps must account for. Vantage generates dependency-aware tickets from PRDs: when a feature requires work from multiple teams, Vantage structures the tickets with explicit dependency relationships so EMs can see the cross-team coordination requirements before sprint planning begins, not after.