--- title: "Tracking cross-team dependencies · DeliverySheet" description: "Most delivery risk sits in work another team has to do for you — and the usual tracking treats it exactly like work you control." canonical_url: "https://www.deliverysheet.com/blog/the-dependency-you-dont-own" last_updated: 2026-08-21 meta: author: "Tan Gravam" "og:description": "Most delivery risk sits in work another team has to do for you — and the usual tracking treats it exactly like work you control." "og:image": "https://www.deliverysheet.com/_og/s/o_1e2d5590e050ffbf.png" "og:image:alt": "The dependency you don't own — DeliverySheet essay card" "og:image:height": "600" "og:image:type": image/png "og:image:width": "1200" "og:title": "The dependency you don't own — DeliverySheet" "twitter:description": "Most delivery risk sits in work another team has to do for you — and the usual tracking treats it exactly like work you control." "twitter:image": "https://www.deliverysheet.com/_og/s/o_1e2d5590e050ffbf.png" "twitter:image:alt": "The dependency you don't own — DeliverySheet essay card" "twitter:title": "The dependency you don't own — DeliverySheet" --- > Index of every page on this site: [llms.txt](https://www.deliverysheet.com/llms.txt) [← All writing](https://www.deliverysheet.com/blog) # **The dependency you don't own** 6 August 2026 · 4 min read · by [Tan Gravam](https://www.deliverysheet.com/about) ## **How should you track dependencies on other teams?** **The short answer ** A dependency on another team is not a task with a different assignee; it is a request you have no authority over, and tracking it as a task hides that. Record who it is needed from, what specifically is needed, by when, and whether the other side has actually agreed — then treat "asked but not confirmed" as a distinct, visible state rather than as done. Most late-stage delivery surprises are dependencies that were logged, never confirmed, and read as handled ever since. Open a plan that slipped and follow the chain back. A surprising share of the time it ends at the same place: something another team had to do, that was written down early, and that nobody checked again until it mattered. The tracking was not missing. That is the uncomfortable part. There was a line item. It had a name on it. It looked handled for eleven weeks. ## Why the usual model breaks Most tools give you one object for work: a task with an assignee. So a dependency on another team becomes a task assigned to someone in that team, and inherits all the assumptions that come with it — that the assignee has accepted it, that it is on their list, that "not done" means "in progress". None of those hold. You cannot assign work to a team you do not run. What you actually have is a *request* you have no authority over, and the single most important fact about it — whether the other side has agreed — has nowhere to live in a model that only knows todo, doing and done. So the state that matters most is the state the tool cannot express, and it gets collapsed into "not done yet", which looks identical to work that is simply early. ## How to track a cross-team dependency: four fields **Who it is needed from.** A team, and ideally a person in it. "Platform" is where dependencies go to be nobody's. **What specifically is needed.** Not "platform work" — "the tenant isolation flag exposed in the config API". A dependency described at the level of a theme cannot be confirmed, because the other side does not know what they would be confirming. **By when.** Not your delivery date — the date *you need it by*, which is earlier, and which is the only date that gives the other team a real choice. **Whether they have agreed.** The one that changes the number. Logged is not asked. Asked is not confirmed. Those three are different states and flattening them is the whole failure. ## "Asked but not confirmed" deserves to be visible If you add one thing to how you track cross-team work, make it this state. It is the state most dependencies live in for most of their life, and it is indistinguishable from "fine" in every tool that does not name it. A plan with four unconfirmed dependencies and a plan with four confirmed ones look the same on a board and are completely different bets. It also converts a vague anxiety into a specific, cheap action. "Chase the dependencies" is a task nobody does. "These two are unconfirmed, both needed by the 14th" is two messages. ## The horizontal problem underneath Per-demand dependency tracking is necessary and insufficient, because each demand only sees its own instance. Security review, legal, privacy, accessibility, design — these are [horizontal work](https://www.deliverysheet.com/blog/vertical-and-horizontal-work) : they pulse into many delivery streams at gates. Four teams can each hold one perfectly reasonable dependency on security, all due the same fortnight, and no individual plan is wrong. The aggregate is what is impossible, and nobody owns the aggregate. So someone has to read the column, not the row: all the demands needing something from the same group, as a calendar rather than a list. You are looking for clustering, not volume. ## What to do when it is not agreed and the date holds Sometimes you cannot get confirmation in time. The dependency stays unconfirmed and the commitment has to be made anyway. That is a legitimate situation and it has a legitimate handling: commit with a recorded exception that names the unconfirmed dependency as what is missing, who is accepting the risk, and what would change the decision — "if platform has not confirmed by the 14th, we re-scope". What is not legitimate is committing and letting the dependency keep looking green. ## How DeliverySheet models it A dependency on a demand carries what is needed, who it is needed from, and a status — and the statuses that matter are *blocked* and *at risk*, which are what the commitment bar reads. An unresolved blocking dependency stops a demand reading as ready to commit; it does not stop you committing, it stops the system claiming you are ready to. "Needed from" uses the same team picker as every other row-level field in the product, so a dependency points at a real team in the workspace rather than a free-text guess — which is what makes reading down the column possible at all. And like every other planning dimension it has three states: not assessed, no known dependencies, or a list. A demand with genuinely nothing external can say so in one click, which is the only reason the ones that do have dependencies stay meaningful. The wider argument — why this and risk and capacity all need the same three-state treatment — is in [the overview on planning that stays honest](https://www.deliverysheet.com/topics/planning) . I'm Tan Gravam. I build **DeliverySheet** — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date. $189/month per workspace, unlimited members. 7-day free trial — card required, cancel before it ends and you're not charged. I answer the support email myself. [**Start 7-day trial **](https://www.deliverysheet.com/login?next=/app) [**See pricing **](https://www.deliverysheet.com/pricing) Not ready for that? Play [eight rounds of Request or topic?](https://www.deliverysheet.com/spot-the-request) It takes two minutes and needs no sign-up. ## **More on planning that stays honest** [Read the overview: Planning that stays honest →](https://www.deliverysheet.com/topics/planning) - [How to run a pre-mortem: forty-five minutes before you commit](https://www.deliverysheet.com/blog/how-to-run-a-pre-mortem) A project pre-mortem in 45 minutes: imagine the failure, write reasons alone, pick the fatal ones, and turn each into a risk, a dependency or a cut. - [Scope is mostly what you're not doing](https://www.deliverysheet.com/blog/scope-is-what-youre-not-doing) An in-scope list describes an intention. The out-of-scope list is what actually holds when someone asks for one more thing in week six. - [Vertical and horizontal work: the distinction planning tools miss](https://www.deliverysheet.com/blog/vertical-and-horizontal-work) Delivery streams and cross-cutting concerns behave differently, need different capacity models, and fail differently. Most tools call both an "epic". ```json {"@context":"https://schema.org","@graph":[{"@id":"https://www.deliverysheet.com/#website","@type":"WebSite","description":"Turn raw work requests into structured, decision-ready demands before you commit people, budget, or a date. AI-assisted shaping, planning and commitment governance for engineering leaders.","name":"DeliverySheet","url":"https://www.deliverysheet.com/","publisher":{"@id":"https://www.deliverysheet.com/#identity"}},{"@id":"https://www.deliverysheet.com/blog/the-dependency-you-dont-own#webpage","dateModified":"2026-08-21","datePublished":"2026-08-06","description":"Most delivery risk sits in work another team has to do for you — and the usual tracking treats it exactly like work you control.","name":"Tracking cross-team dependencies","url":"https://www.deliverysheet.com/blog/the-dependency-you-dont-own","@type":["WebPage","FAQPage"],"breadcrumb":{"@id":"https://www.deliverysheet.com/blog/the-dependency-you-dont-own#breadcrumb"},"isPartOf":{"@id":"https://www.deliverysheet.com/#website"},"mainEntity":[{"@id":"https://www.deliverysheet.com/blog/the-dependency-you-dont-own#/schema/question/1"}],"potentialAction":[{"@type":"ReadAction","target":["https://www.deliverysheet.com/blog/the-dependency-you-dont-own"]}],"primaryImageOfPage":{"@id":"https://www.deliverysheet.com/#logo"}},{"@id":"https://www.deliverysheet.com/#identity","@type":"Organization","alternateName":"Delivery Sheet","description":"Turn raw work requests into structured, decision-ready demands before you commit people, budget, or a date.","name":"DeliverySheet","url":"https://www.deliverysheet.com","founder":{"@type":"Person","@id":"https://www.deliverysheet.com/about#person","name":"Tan Gravam"},"logo":{"@id":"https://www.deliverysheet.com/#logo"}},{"@id":"https://www.deliverysheet.com/blog/the-dependency-you-dont-own#breadcrumb","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","name":"Home","item":"https://www.deliverysheet.com","position":1},{"@type":"ListItem","name":"Writing","item":"https://www.deliverysheet.com/blog","position":2},{"@type":"ListItem","name":"The dependency you don't own","item":"https://www.deliverysheet.com/blog/the-dependency-you-dont-own","position":3}]},{"@id":"https://www.deliverysheet.com/blog/the-dependency-you-dont-own#article","@type":"Article","dateModified":"2026-08-21","datePublished":"2026-08-06","description":"Most delivery risk sits in work another team has to do for you — and the usual tracking treats it exactly like work you control.","headline":"The dependency you don't own","inLanguage":"en","thumbnailUrl":"https://www.deliverysheet.com/_og/s/o_1e2d5590e050ffbf.png","author":{"@id":"https://www.deliverysheet.com/about#person"},"image":{"@id":"https://www.deliverysheet.com/#/schema/image/1"},"isPartOf":{"@id":"https://www.deliverysheet.com/blog/the-dependency-you-dont-own#webpage"},"keywords":["dependencies","planning","risk"],"mainEntityOfPage":{"@id":"https://www.deliverysheet.com/blog/the-dependency-you-dont-own#webpage"},"publisher":{"@id":"https://www.deliverysheet.com/#identity"}},{"@id":"https://www.deliverysheet.com/blog/the-dependency-you-dont-own#/schema/question/1","@type":"Question","inLanguage":"en","name":"How should you track dependencies on other teams?","acceptedAnswer":{"@type":"Answer","text":"A dependency on another team is not a task with a different assignee; it is a request you have no authority over, and tracking it as a task hides that. Record who it is needed from, what specifically is needed, by when, and whether the other side has actually agreed — then treat \"asked but not confirmed\" as a distinct, visible state rather than as done. Most late-stage delivery surprises are dependencies that were logged, never confirmed, and read as handled ever since."}},{"@id":"https://www.deliverysheet.com/about#person","@type":"Person","jobTitle":"Founder","name":"Tan Gravam","url":"https://www.deliverysheet.com/about","sameAs":["https://gravam.com","https://twitter.com/TanGravam","https://github.com/TanGravam"]},{"@id":"https://www.deliverysheet.com/#logo","@type":"ImageObject","caption":"DeliverySheet","contentUrl":"https://www.deliverysheet.com/logo.png","inLanguage":"en","url":"https://www.deliverysheet.com/logo.png"},{"@id":"https://www.deliverysheet.com/#/schema/image/1","@type":"ImageObject","contentUrl":"https://www.deliverysheet.com/_og/s/o_1e2d5590e050ffbf.png","inLanguage":"en","url":"https://www.deliverysheet.com/_og/s/o_1e2d5590e050ffbf.png"}]} ``` ## Sitemap See the full [sitemap](https://www.deliverysheet.com/sitemap.md) for all pages.