The part of the plan you don’t own
A dependency is not a task — it is a request into someone else’s priority queue. What another team’s yes is actually worth, and how to keep your critical path out of their backlog.
Your pre-mortem turned up an item that was easy to write and easy to skim past:
The vendor was fine, but wiring their model to our existing user and org tables turned out to be the actual work, and nobody had looked at it.
Those tables belong to the platform team. You need a change there — the org record needs to carry an identity-provider connection, and it does not today. So the plan you are about to commit to contains a piece of work that you cannot do and cannot schedule.
Every previous lesson assumed the work was yours. This one is about the part that is not, which in most real projects is the part that decides the date.
A dependency is not a task
The error that causes most of the damage is quiet and almost administrative: putting the other team’s work on your plan as a line item, with a duration, in a position.
It looks reasonable. It is a fiction. A task is something you can start, sequence and finish. A dependency is a request into somebody else’s priority queue, and you do not control the ordering of that queue, its arrival rate, or what gets bumped when their own incident happens. Writing “platform: 3 days” on your plan does not make three days appear in their quarter. It only makes your plan look complete.
What their “yes” is actually worth
You will go and talk to them, and you will get a reply that sounds like a yes. Most of these are not. There are three distinct things and they are routinely heard as the same thing:
- Agreement — “yeah, that makes sense, we’d support that.” They think your request is reasonable. It carries no information about when.
- Prioritisation — “that’s in our next cycle.” Someone has put it in an order relative to their other work. This is the one that matters, and it is much rarer than agreement.
- Commitment — “you’ll have it by the 14th.” A date a named person will be held to.
The distinction is the same one from the estimate lesson, pointed the other way. There you had to stop your forecast being heard as a promise. Here you have to stop hearing someone’s agreement as their promise, which is the more comfortable error because it lets you write the plan and leave.
The question that separates them is not “can you do this?” It is “what would this displace?” A team that cannot answer that has not prioritised your request; they have agreed with it. The answer is also genuinely useful to you: if the thing it displaces is more important than SSO, you have learned that early and cheaply, and you should probably stop asking.
Keep your critical path out of their backlog
This is where the planning move is, and it is more powerful than any amount of chasing.
DORA’s research found that teams able to test, deploy and change their systems without requiring another team to move first deliver measurably better, and that this coupling is architectural as much as organisational (DORA, “Loosely coupled teams”). That is usually read as advice about system design. Read it as advice about plans.
It means the design question is not only “what is the best way to build this?” but “which of these designs lets us ship without them moving first?” For the SSO work that might be storing the connection reference in your own table and reconciling later, rather than adding the column to theirs. Technically that is worse. It is a duplicate, it will need cleaning up, and you would not choose it in a vacuum.
But it converts a five-week queue latency into an afternoon of your own work, and it turns a dependency into a follow-up. Very often that is the better plan even though it is the worse design, and recognising when it is not is judgment — a duplicate of an authentication-critical record probably is not worth it; a duplicate of a display name almost certainly is.
Where people get burned
Write the reason down when you make this trade, in the decision record — including what you would do to undo it. A deliberate duplicate with a documented cleanup is a plan. The same duplicate with no note is indistinguishable from someone not knowing the right table existed, and in eighteen months nobody will be able to tell the difference, including you.
If you do need them: make the ask small and dated
Sometimes there is no design that avoids it. Then the shape of the request determines how long it sits.
A large vague ask — “we need SSO support in the org model” — requires them to do discovery before they can even size it, so it queues behind everything that is already understood. A small specific one they can evaluate in a minute gets an answer:
“We need one nullable column onorganisations—idp_connection_id, a string — plus it exposed on the existing org read endpoint. Happy to write the migration and the PR myself if you would rather review than build. We need it by the 20th to hold our date; if that does not work, tell me and I will plan around it.”
Four things are doing work there. The ask is small enough to answer without a meeting. It offers to move the effort to your side, which is often the actual constraint. It has a date. And it says what happens if the answer is no — which is the assumption-with-an-expiry-date from the framing module, pointed at a person instead of a question.
Retrieval check
Without scrolling up: what is the question that distinguishes a team agreeing with your request from a team having actually prioritised it — and why is the answer useful to you even when it is bad news?
Check your answer
“What would this displace?” Agreement costs nothing to give and carries no information about when. Prioritisation means your request has been placed in an order against other work, which is only possible if something else moved.
The answer helps either way. If what it displaces matters less than your project, you have a real position in their queue. If it matters more, you have learned in one conversation that this dependency is not going to clear in your window — early, cheaply, and in time to design around it rather than discovering it in week six.
When their date slips
It will sometimes, and you have no authority whatsoever. What you have instead is what you prepared: this is a monitored risk, and it gets the same owner, trigger and response as any other.
- Owner — you, not “platform”. You are the person whose plan breaks, so you are the person who checks.
- Trigger — a date before theirs, not the same day. “If the PR is not open by the 13th” leaves you a week; “if it is not delivered by the 20th” leaves you nothing.
- Response — decided in advance, while it is still cheap: which fallback design you switch to, and what that costs.
And when it fires, the escalation is not about them. It is about your plan: what changed, what it means for the date, what you need decided. Escalating a dependency by complaining about another team is the fastest way to make the next one slower, because you have just taught them that talking to you is expensive.
Now apply it: plan around the platform team
Hands on
Turn the dependency into something you control
Done when: You have a fallback design that does not need them, a small dated ask if you decide to make one, and the dependency written up as a monitored risk.
- Write the dependency as it really is: what you need, from whom, and — honestly — how long you think it takes to arrive, not how long it takes to do. If you do not know their queue, say that rather than guessing a small number.
- Design the version that does not need them. There is almost always one, it is almost always worse, and the point is to know what it costs before you decide. Write down what it would take to clean up afterwards.
- Decide, and record the reason. Either you are taking the worse design to keep your critical path clear, or you are accepting the dependency because the duplicate is not worth it here. Both are defensible; drifting into one without noticing is not.
- If you are asking: write the request. Small enough to answer in a minute, offering to do the work yourself, with a date and with what you will do if the answer is no.
- Write it up as a monitored risk with an owner, a trigger dated before theirs, and the fallback you already designed as the response.
- Bring it into the chat. I will play the platform team — busy, reasonable, and with a roadmap of my own — and I will say “yeah, that sounds fine” at least once without committing to anything. Noticing that, and asking what it would displace, is the skill.
What this does not cover
You now know what you own, what you do not, and what you will do when the part you do not own moves. That is the last thing you needed before committing to the plan out loud, in a room, to someone who wants a different date than the one you have. Which is next.
Read this next — primary source
Capabilities: Loosely coupled teamsDORA (dora.dev) — free, and short
Read it as a planning document rather than an architecture one. The finding is that teams able to test, deploy and change their systems without depending on other teams deliver better — which reframes coupling from a design preference into a schedule risk. For the structural version of the same argument, Team Topologies by Matthew Skelton and Manuel Pais is the standard reference.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.