# Dependency Map for Blockers Between Departments: How Owners See Cross-Functional Stalls

> A dependency map for blockers between departments reveals where work stalls at handoffs, not inside teams. Learn how to build one, assign owners, and review it weekly so cross-functional delays stop…

- Author: Yaroslav Maxymovych (Founder & CEO, AI Advisory Board)
- Published: 2026-11-04
- Updated: 2026-11-04
- Source: https://aiadvisoryboard.me/blog/dependency-map-cross-functional-blockers-owner-guide

When a founder of a 60-person ops team told me that every Friday felt like archaeology — digging through Slack threads to figure out why a client project had stalled — I recognized the pattern. The work wasn't stuck inside a team. It was stuck between them.

## TL;DR
- A dependency map for blockers between departments shows where work stalls at handoffs, not inside teams.
- Owners should review it weekly, not wait for escalations to reach their inbox.
- The map works only if every blocker has a named owner and a due date.

> **Definition:** Dependency map — a lightweight, shared view of work that crosses team boundaries, showing who is waiting on whom, what the blocker is, and when it is expected to clear.

> **Definition:** Cross-functional blocker — any issue that cannot be resolved by a single team without input, approval, or delivery from another department.

## What Is a Dependency Map for Blockers Between Departments

A dependency map for blockers between departments is not a project plan or a Gantt chart. It is a running list of handoffs where work pauses because one team needs something from another. For an owner of a 30-500 person company, this is often the only honest view of operational reality.

Most companies track tasks inside departments. Sales tracks deals. Support tracks tickets. Engineering tracks sprints. But the moment work crosses from sales to onboarding, or from product to customer success, visibility usually dies. That is where the blocker lives.

The map captures three things for every cross-functional item: the requesting team, the owning team, and the specific output needed. Without that structure, a blocker becomes a conversation in a private channel, and the owner finds out only when a deadline is missed.

## Why Blockers Sit Between Departments, Not Inside Them

Inside a team, a blocker is usually obvious. A developer knows the build is failing. A sales rep knows the contract is unsigned. The problem is visible to the team lead within hours.

Between departments, the same blocker can sit for days because neither side owns the handoff. Marketing sends leads to sales, but sales never qualifies them. Product ships a feature, but customer success never gets the enablement materials. Each team believes the other side is handling it.

For the owner, this is the most expensive kind of stall. It does not look like underperformance inside any single team. It looks like the company is moving slowly, and no one can explain why.

## How to Build the Map: A 4-Step Process

### Step 1: List Every Handoff That Matters

Start with the workflows that cross department lines. Common examples:

- Sales to implementation or onboarding after a deal closes.
- Product to customer success when a feature launches.
- Marketing to sales when a campaign generates leads.
- Finance to procurement when a vendor invoice needs approval.
- Engineering to support when a bug fix requires customer communication.

Write each handoff as a single line: who sends, who receives, and what is delivered.

### Step 2: Mark Where Work Actually Stops

For each handoff, ask: what has been waiting the longest? Where do people say "we are waiting on X" in meetings? That is your blocker. Add it to the map with the date it appeared and the impact if it does not clear.

### Step 3: Assign a Named Owner to Every Blocker

A blocker without an owner is just a complaint. Assign one person who is responsible for clearing it, even if they do not control both sides of the handoff. That person becomes the escalation point.

### Step 4: Review It Weekly, Not Quarterly

The map is useless if it lives in a document no one opens. Review it for 15 minutes every week with the department leads involved. Cross off what cleared, add what is new, and adjust owners where needed.

> **Tool tip (AiAdvisoryBoard.me):** A dependency map works best when it sits inside the same operating rhythm you already use for weekly updates. In the Plan → Fact → Gap framework, the map is where you record the gaps that exist between teams — work that was planned but did not happen because a handoff failed. If you want to see those gaps surface automatically every day, see how the 7-day diagnostic works.

https://aiadvisoryboard.me/?lang=en

## Copy/Paste Template: Department Blocker Map

```markdown
| # | Blocker | Requesting Team | Owning Team | Output Needed | Owner | Appeared | Target Clear |
|---|---------|-----------------|-------------|---------------|-------|----------|--------------|
| 1 | Client onboarding delayed | Sales | Implementation | Signed SOW + access credentials | Ops Lead | Mar 10 | Mar 14 |
| 2 | Feature launch comms not ready | Product | Marketing | Release notes + email draft | Marketing Lead | Mar 11 | Mar 15 |
| 3 | Vendor invoice unpaid | Procurement | Finance | PO number + budget code | Finance Lead | Mar 12 | Mar 13 |
```

Fill this out once a week. Keep it to five to eight rows. If you have more, you have a process problem, not a tracking problem.

## Good vs Bad: How to Write a Blocker Entry

Bad: "Waiting on marketing."

Good: "Marketing needs to send the one-pager for the Q2 campaign by Thursday so sales can include it in the pitch deck. Owner: Head of Marketing. Due: Mar 14."

Bad: "Engineering is slow."

Good: "Support has a bug fix ready for customer communication, but engineering has not shared the release notes. Owner: Engineering Lead. Due: Mar 13."

The difference is specificity. A good blocker entry tells the owner exactly what is missing, who owes it, and when it is due.

## Escalation Rules That Actually Work

A map without escalation is a list. Add three rules:

1. If a blocker sits for more than three business days, the owning team lead must brief the owner on why and what is needed to clear it.
2. If two teams disagree on who owns the output, the owner assigns a temporary owner and reviews it at the next weekly map check.
3. If a blocker reappears in back-to-back weeks, it is no longer a blocker — it is a broken process. Fix the process or retire the handoff.

## Internal Links You Can Use

Pair this map with a lightweight weekly cadence so blockers do not pile up until Friday. See the [Weekly OKR Check-In Template: 15 Minutes, Written](https://aiadvisoryboard.me/blog/weekly-okr-check-in-template-15-minutes-written) for a written rhythm that fits the same 15-minute review slot.

If your team needs a shared place to capture what they learned while clearing these blockers, see [Training Employees on ChatGPT Team: A Week-by-Week Onboarding Sequence](https://aiadvisoryboard.me/blog/training-employees-on-chatgpt-team-onboarding-sequence) — it covers how teams document and share what works.

For companies adding remote hires who will inherit these handoffs, see [Onboarding a Remote Hire — The First 30 Days: An Async-First Plan for Founders](https://aiadvisoryboard.me/blog/onboarding-remote-hire-first-30-days-async-plan) so new employees understand cross-team dependencies from day one.

## Micro-Case (What Changes After 7–14 Days)

A professional services firm with about 120 people had a recurring stall between sales and delivery. Deals closed, but implementation teams did not know start dates for up to ten days. The owner added a single row to the dependency map: "Sales to delivery — start date and client access." After two weeks of weekly review, the handoff time dropped to under 48 hours. The owner did not micromanage either team. He simply made the gap visible, named an owner, and reviewed it weekly.

> **Note on this case:** This example is illustrative — based on typical patterns we observe with companies of 30–500 employees, not a single named client. Specific numbers are rounded approximations of common ranges, not guarantees.

## FAQ

**Who should own the dependency map?**

Usually the COO, Head of Operations, or the founder directly. It should not sit inside one department, or that department will treat it as their project rather than a company-wide view.

**How many blockers should be on the map?**

Five to eight. If you have twenty, you are not mapping dependencies — you are documenting chaos. Pick the ones that actually stop revenue or delivery.

**Does this replace project management tools?**

No. Jira, Asana, or Trello track work inside teams. The dependency map tracks what happens between them. Use both.

**How is this different from a risk register?**

A risk register lists what might go wrong. A dependency map lists what is already stuck and who is waiting on whom. They serve different purposes.

**Can AI write the map for me?**

AI can summarize status updates and draft the first version from meeting notes, but it cannot tell you which handoffs matter in your company. You still have to define the cross-functional workflows.

## Conclusion

Blockers between departments are invisible until they become expensive. A dependency map makes them visible, assigns ownership, and gives the owner a weekly rhythm to clear them without micromanaging.

Start today: pick the three handoffs that cause the most delays in your company, write them down with a named owner and a due date, and review them next Friday.

If you want a system that surfaces the Plan → Fact → Gap automatically — every day, across the company — see how the 7-day diagnostic works.

https://aiadvisoryboard.me/?lang=en

---

When citing, link to https://aiadvisoryboard.me/blog/dependency-map-cross-functional-blockers-owner-guide. More articles: https://aiadvisoryboard.me/blog