Why Dependencies Kill More Projects Than Hard Engineering
Here is how most cross-team dependency problems happen. Your team is working on a feature that requires an API from another team. You mention it in a Slack message in week one. The other team acknowledges it. Nobody writes anything down. In week four, you discover that the other team deprioritized the work in their sprint planning. Your June deadline just moved to August. You had four weeks to prevent this. You missed all of them.
Dependencies are where projects go to die quietly. They are hard to manage because they require you to hold someone else accountable — and most engineers would rather assume things are fine than have an awkward conversation about a missed commitment. The result is that the problem compounds silently until it's too big to quietly fix.
The dependency tracking system in this appendix is designed around one goal: making it impossible for a dependency to slip without you knowing about it at least two weeks before it becomes a crisis.
When your project depends on another team, your confidence in your timeline is only as strong as your confidence in their timeline. And their timeline is the thing you have the least control over. This is why you need a system — not trust, not goodwill, not Slack messages. A system.
What Goes Into a Dependency Record
Each external dependency your project has should be tracked with nine pieces of information. Not ten, not four — nine. They cover what you need, when you need it, who promised it, and what you do when it's late.
The Nine Fields
1. What you need. Describe the deliverable specifically. "An API" is not specific. "A REST endpoint GET /users/:email that returns user ID and org ID, documented with OpenAPI spec, with rate limit of 1,000 req/min" is specific. Vague deliverables lead to vague commitments.
2. The team you need it from. Name the team and the specific person who made the commitment. Teams don't commit — people do. "The Identity team" can say "oh, that person left, nobody told us." A named person has accountability.
3. Why you need it. What does your project do with this deliverable? What breaks if it's late? Writing this out forces you to articulate the impact of a slip — which is exactly the information you need when you're having an escalation conversation.
4. The needed-by date. Not the ideal date — the actual last-possible date before your project is affected. Be honest. Padding this date gives the other team false slack and gives you a false sense of security.
5. The check-in date. This is the date before the needed-by date when you will actively confirm status. Set it two weeks before the needed-by date for any high-impact dependency. If the dependency is high-risk (see the risk register), weekly check-ins are appropriate.
6. Current status. Green / Yellow / Red. Green means the other team is on track and you have confirmed this. Yellow means you have concerns but it's not yet a crisis. Red means the delivery is at risk and you are actively managing it.
7. Confirmed commitment. Is this a verbal acknowledgment or a written commitment with a date attached? The difference matters enormously. "Yeah I'll get to that" is not a commitment. "We will deliver by May 10 — I've added it to our sprint board" is closer to a commitment.
8. The SLA (Service Level Agreement). For dependencies between teams, an SLA is simply: "If we ask for X by date Y, you will deliver it by date Z, or let us know by date W if you can't." Having this written down, even informally, changes the nature of the relationship from "please help us" to "here is what we've agreed."
9. The decision trigger. Same concept as the risk register: at what date, if the dependency is not confirmed delivered or on track, do you escalate? Write this in advance. "If by May 7 the Identity team has not delivered a staging-ready endpoint, we escalate to their VP and engage our own backend team to build a stub for development continuity."
Filled Examples: The SSO Project Dependencies
Check-in: May 6 (4 days early)
SLA: Confirmed written commitment on May 1.
Check-in: May 15 (doc delivery date)
SLA: Verbal agreement — formal sign-off within 5 business days of doc receipt.
Check-in: May 24
SLA: To be confirmed with James Li this week.
The Dependency Timeline View
Once you have your dependency records, it helps to see them in time order. This view shows you when your project is most exposed — when multiple dependencies have their needed-by dates close together, you have a coordination bottleneck.
The Escalation Ladder
When a dependency is slipping, there is a right order of operations for escalation. Skipping steps creates political friction that will outlast your project. Following the ladder keeps you professional and gives you the best chance of a quick resolution.
Direct message to the owner
First contact point. "Hey, I want to check in on the D1 API delivery — is May 10 still realistic? I want to plan around any changes early." Keep it collaborative, not accusatory. Give them a chance to raise concerns before they become your crisis.
Follow up in writing
If you've had a verbal conversation but nothing has changed, send a brief written message that documents the status and the timeline. "Following up on our conversation — confirming that the API delivery is still May 10 and that there are no blockers. Let me know if that changes." The writing creates a record and signals that you're tracking this formally.
CC their manager on a written update
If two attempts have not produced confirmation, send an update to their manager. Frame it as a project status update, not a complaint. "Wanted to make sure you're aware that we're tracking the May 10 delivery date for the Identity APIs. Priya and I have been aligned on this, just wanted to ensure you have visibility." This is not tattling — it is stakeholder communication. Do this without embarrassment.
Escalate to your manager for cross-org visibility
If the dependency is still not resolved after manager-level contact, bring in your own manager. Now it becomes a leadership-to-leadership conversation. "I need you to connect with Ranjith Kumar about the Identity team deliverable — we've had three attempts and the date is slipping without a resolution path." Be specific about what you need them to do.
Activate the contingency plan
The escalation ladder assumes the dependency might still be delivered. The contingency plan is the path where it doesn't arrive in time. Activate it as soon as the decision trigger fires — do not wait for the escalation to resolve before building the mock, finding an alternative, or descoping the dependency.
Never skip directly from step one to step four and involve executives before you've given the team a chance to respond to direct contact. It will make you look politically aggressive and will generate resentment that outlasts the project. Follow the ladder. Moving too fast looks as bad as moving too slow.
The Quick-Reference Dependency Table
For projects with many dependencies, the full card format is too heavy for weekly review. Use this table for the weekly scan — it shows you everything you need to decide which conversations to have this week.
| ID | What | From | Owner | Needed By | Next Check-In | Status | Trigger Date |
|---|---|---|---|---|---|---|---|
| D1 | Identity APIs (user lookup + sso config) | Identity Platform | Priya Nair | May 10 | May 6 | Green | May 7 |
| D2 | Security cert design approval | Security Eng | Maria Okonkwo | May 22 | May 15 | Yellow | May 15 |
| D3 | Acme Corp staging validation | Acme IT | James Li (via David Tan) | June 1 | May 24 | Yellow | May 24 |
The Blank Template
ID: _____
Title: ________________________________________________
Status: [ ] Green [ ] Yellow [ ] Red
What we need (be specific — deliverable, format, SLA):
__________________________________________________________________________
Team: _______________________ Owner (named person): ___________________
Why we need it (what breaks if it's late):
__________________________________________________________________________
Needed-by date: ___________ Check-in date: ___________
Confirmed commitment? [ ] Verbal [ ] Written [ ] Formal SLA
Link / record: ____________________________________________________________
Decision trigger (date + action if delivery is not confirmed):
__________________________________________________________________________
Contingency plan (what we do if they don't deliver):
__________________________________________________________________________
Last contact: Date ______________ Summary: _____________________________
The dependency tracker is most useful when it's boring. When every dependency is green, the tracker tells you nothing interesting — but it means you can sleep. The goal is not a beautifully organized document for a post-mortem. The goal is that you never have a post-mortem that says "we didn't know the dependency was slipping." That's the tracker doing its job.