How to Create a Cross-Team Dependency Board in Linear
Cross-team dependencies are where roadmaps go to die. Team A needs an API from Team B before they can build the frontend. Team B has not prioritized it because it is not in their quarterly goals. By the time the dependency surfaces, Team A's sprint is half over and the feature slips by three weeks. This scenario plays out in nearly every product organization that has more than two engineering teams, and it is almost always preventable with better visibility.
Linear's project system, labels, and cross-team visibility features make it possible to track dependencies without introducing a heavyweight project management overlay. The key is making dependencies visible before they become blockers — when there is still time to reprioritize, negotiate, or find workarounds. This guide shows you how to build a dependency tracking system in Linear that surfaces risks early and keeps cross-team work coordinated.
Step-by-step guide
Define what counts as a cross-team dependency
Not every interaction between teams is a dependency. A dependency exists when Team A cannot complete their work until Team B delivers something specific: an API endpoint, a shared component, a data pipeline, a design review, or an infrastructure change. Define clear criteria for when a dependency should be tracked: the work is blocking or will block within the current or next sprint, it requires effort from a team that did not plan for it, and it has a specific deliverable (not just 'coordination'). Publish these criteria so teams self-identify dependencies during planning.
- Write a one-paragraph definition of what constitutes a trackable cross-team dependency
- Provide examples: API endpoints, shared components, infrastructure changes, data migrations
- Distinguish dependencies from requests: a dependency blocks your work, a request is nice to have
- Share the definition in your engineering handbook and reference it during sprint planning
Create a dependency tracking system in Linear
Create a dedicated Linear project called 'Cross-Team Dependencies' that is visible to all teams. Each dependency is tracked as an issue in this project with a standardized format: the title describes the deliverable (e.g., 'API: User preferences endpoint for mobile team'), and the description includes the requesting team, the providing team, the deadline, the blocking issue (linked), and the impact if delayed. Use Linear's issue relations to link the dependency issue to the actual work items it blocks.
- Create a 'Cross-Team Dependencies' project visible to all teams
- Create a dependency issue template with fields: Requesting Team, Providing Team, Deadline, Impact of Delay
- Use Linear's 'Blocked by' relation to link dependency issues to the work they block
- Set the project to allow issues from any team
Set up labels for dependency status and priority
Create a set of labels specifically for dependency tracking. Status labels: dep-identified (dependency recognized but not yet committed), dep-committed (providing team has agreed to deliver), dep-in-progress (actively being worked on), dep-delivered (deliverable is ready), dep-blocked (providing team is blocked and delivery is at risk). Priority labels: dep-critical (blocks a launch), dep-high (blocks sprint completion), dep-medium (blocks a feature but workaround exists). These labels make the board view instantly scannable.
- Create status labels with distinct colors for instant visual recognition
- Create priority labels to distinguish between hard blocks and soft dependencies
- Add an 'At Risk' label for dependencies that are behind schedule
- Document label meanings in the project description for consistency
Build the dependency board view
Create a custom board view in the Cross-Team Dependencies project grouped by status label. The columns should be: Identified, Committed, In Progress, Delivered, and Blocked. Add swimlanes or filters for the providing team so you can see which teams have the most dependency load. Create a second view filtered to 'dep-critical' and 'dep-high' priority for leadership visibility. Pin both views in the project for easy access.
- Create a board view grouped by dependency status labels
- Create a filtered view showing only critical and high-priority dependencies
- Add a 'By Team' view that groups dependencies by the providing team
- Pin the board view as the default project view
Integrate dependencies into sprint planning
Make dependency review a standing item in every team's sprint planning. Before committing to sprint work, each team reviews the dependency board for: dependencies they have committed to deliver (ensure they are planned in this sprint), dependencies they are requesting from others (verify the providing team has committed and the timeline holds), and new dependencies that have been identified since last planning. This 10-minute review prevents the most common failure mode: teams planning work that depends on deliverables nobody has committed to.
- Add 'Dependency Review' as the first item in your sprint planning agenda
- Review incoming dependencies: what have we committed to deliver to other teams?
- Review outgoing dependencies: are teams we depend on on track?
- Flag any dependencies without a committed status for immediate escalation
Set up dependency risk alerts
Create Linear Automation rules or use Slack integrations to alert when dependencies are at risk. Trigger alerts when: a dependency issue is moved to the 'Blocked' status, a dependency's deadline is within 5 business days and it is not yet 'In Progress,' or a dependency has been in 'Identified' status for more than one sprint without being committed. Route these alerts to the engineering leads channel so blockers are surfaced to people who can resolve them.
- Set up a notification when any dependency moves to 'Blocked' status
- Create a weekly automated digest of dependencies approaching their deadline
- Alert when a dependency has been in 'Identified' for more than 10 business days
- Route dependency risk alerts to a dedicated Slack channel monitored by engineering leads
Run a weekly dependency standup
Schedule a 15-minute weekly standup with one representative from each team. Walk through the dependency board focusing on three categories: at-risk dependencies (status is Blocked or deadline is approaching without progress), newly identified dependencies (does the providing team acknowledge and commit?), and recently delivered dependencies (confirm the requesting team can unblock). This standup is the coordination layer that prevents dependencies from becoming surprises. Keep it strictly to 15 minutes by limiting discussion to decisions and escalations.
Common mistakes
Only tracking dependencies after they become blockers
If you only add a dependency to the board when someone is already blocked, you have lost the window for proactive resolution. Dependencies should be identified during planning (before the sprint starts) when there is still time to negotiate priorities, adjust timelines, or find alternatives.
Not assigning owners to dependencies
A dependency without a clear owner on the providing team is a dependency nobody is working on. Every dependency issue must have an assignee from the providing team who is accountable for delivery. If the providing team has not assigned someone, the dependency is not committed — it is a wish.
Creating dependencies for everything instead of reducing them
Sometimes the best way to handle a dependency is to eliminate it. Can the requesting team build a temporary solution? Can the interface be simplified so the dependency is smaller? Can the work be reordered to defer the dependency to a later sprint? The dependency board should trigger dependency reduction conversations, not just dependency tracking.
Tips
Add a 'Cost of Delay' field to dependency issues that quantifies the impact of a missed deadline in concrete terms (team members blocked, sprint goals at risk, launch date impact) — this helps providing teams prioritize realistically.
Color-code dependency issues by providing team so the board visually shows which teams are carrying the most dependency load — this informs hiring and architecture decisions.
Create a quarterly 'Dependency Retrospective' that analyzes patterns: which teams are the most common providers, which dependency types take longest to deliver, and which dependencies could have been avoided with different architecture.
Use Linear's project insights to track dependency cycle time (time from Identified to Delivered) and set improvement targets quarter over quarter.
How Vantage helps
Vantage automatically detects cross-project dependencies during ticket generation. When multiple projects share requirements or affect the same system components, Vantage surfaces these connections in the planning phase, helping teams identify and manage dependencies before they become sprint-disrupting blockers.