The Dependencies You Forgot to Write Down

A dependency you wrote down is a risk. A dependency you did not write down is a surprise. Same fact, and the only difference is whether the project had a chance to plan around it.

The trouble is that dependencies are the requirements you are least likely to write, for a reason that has nothing to do with diligence: you already know about them. They have been sitting in your head since the kickoff, they feel like context rather than content, and so the one person who needed to read them never does.

Below are five classes worth checking, each with the single question that surfaces it.

Why they go unwritten

Familiarity. The API team's timeline has been in your head for three weeks. It does not feel like information, so it does not get typed.

They live in other people's heads. Half your real dependencies are known to an engineer who mentioned them once in a thread you skimmed. Nobody is hiding anything; the knowledge is just distributed and nobody was asked to consolidate it.

Writing one down concedes control of the date. This is the honest one. An unwritten dependency lets the plan look tight. Naming it means saying out loud that your date depends on someone else's, which is uncomfortable in exactly the meeting where it is most useful.

Five classes and the question that finds each

1 · Team — who else has to ship something for this to work?

The most common and most damaging. Another team must build, expose, migrate, or approve something before your feature functions.

The failure is rarely that the other team refuses. It is that they never knew, because your dependency lived in your plan and not in theirs. By the time you ask, their quarter is committed.

Ask the question in the form above, not as "does anyone have dependencies?" — which reliably returns nothing in a room of people who all assume someone else would have mentioned it.

2 · Technical — what would break if this shipped today?

Infrastructure, migrations, feature flags, rate limits, schema changes, a service that has to exist first.

This question works better than asking for dependencies directly because it is concrete and slightly adversarial. Engineers answer it immediately and precisely, where "what do we depend on?" produces a pause and a shrug.

3 · Data — where does this number come from the first time?

Quietly the most common cause of a launch that ships and then cannot be evaluated.

Your success metric needs a baseline. Your dashboard needs an event that nobody is emitting yet. Your personalisation needs history that does not exist for new users. Your report needs a field three teams populate inconsistently.

Ask it about every metric in the spec. If the answer is "we'd have to start collecting that", you have a dependency with a lead time, and it is almost always longer than the feature itself.

4 · Legal and compliance — what would legal ask if they read this?

Data residency, retention, consent, PII handling, accessibility obligations, contractual terms with existing customers, anything touching payments or minors.

You do not need a lawyer to answer the question — you need it asked early enough that the answer is a conversation rather than a launch block. The expensive version of this dependency is always the one discovered in the final week.

5 · Vendor and external — what here do we not control?

Third-party APIs, model providers, payment processors, email deliverability, app store review, anything with a rate limit or an SLA you did not write.

External dependencies deserve extra attention because their failure mode is different: they do not slip, they degrade. The vendor does not tell you they are late — they return 503s during your launch window. Pair every vendor dependency with the error state that covers it not answering.

What to write for each

Five fields. Four are obvious and one is the one that matters.

What you need. Specific enough to act on. Not "API support" but "a seats_remaining field on the workspace endpoint".

Who owns it. A person, not a team. Teams do not answer messages.

When you need it. A date, derived backwards from your own. "Before the build starts" is not a date.

What happens if it is late. The fallback. If there is genuinely no fallback, say that — a dependency with no plan B is a single point of failure and deserves to be labelled as one.

Confirmed or assumed. ← this one.

Confirmed vs assumed

The distinction that changes outcomes, and it is almost never on the page.

A dependency someone has agreed to, in writing, with a date they chose, and a dependency you are hoping for because it seems reasonable, look identical in a PRD. Both appear as a line in a table. They behave nothing alike.

Confirmed — Priya (Platform) confirmed 22 Aug in #platform-eng. Assumed — Platform has done similar work quickly before.

The second one is not a plan. It is a wish with a name attached, and marking it honestly is what lets a reviewer see the actual risk in your timeline rather than the version you would prefer.

Run the pass with this lens once and the pattern is usually uncomfortable: most timelines rest on more assumed dependencies than confirmed ones. That is fine as long as everyone can see it.

The one that kills projects

The dependency nobody owns.

Not disputed — unowned. Everyone agrees it needs to happen. Nobody's name is on it. It appears in your PRD, gets nodded at in review, and then sits there, because there is no one whose job it is to notice that it has not moved.

This is the most reliable predictor of a slipped date in any spec, and it is easy to find: read your dependency list and check every row has a human name in the owner column. Any row without one is already late.

If you cannot get a name attached before the build starts, treat that dependency as unavailable and make the fallback your primary path. That is a worse product and a real date, which beats a better product and a date you will miss.

FAQ

What counts as a dependency? Anything you need that your team does not control and cannot produce on its own schedule.

Why do they get left out? Because you already know them, so they feel like context rather than content — and because naming one concedes that the date is not fully yours.

What do I write? What you need, who owns it, when, the fallback, and confirmed vs assumed. The last is the one everyone skips.

A dependency nobody owns? Escalate before the build, not when it blocks you. No name in the owner column means it is already late.