The dependency you don't own

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.

Four things a dependency needs

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 : 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 .