The Dependency Dance

Why Dependencies Are the Silent Project Killers

Here is the most common project failure pattern in large engineering organizations: a project is well-scoped, well-staffed, and well-planned. The team knows exactly what to build. They're moving fast. Then, eight weeks before launch, someone says the words that give every principal engineer a cold feeling in their stomach: "Wait — doesn't this depend on Team X finishing their API first?"

It does. And Team X didn't know they were on your critical path. They've been heads-down on something else. The thing you need from them will take four weeks minimum. You have eight weeks left. You just lost your margin entirely, and the launch is now a coin flip.

This is not a story about incompetence. It happens constantly at Google, Meta, Amazon, and every large company in the world. It happens because dependencies are easy to discover and easy to defer. The team had many things to figure out at the start of the project, and "check with Team X" felt like something you could do next week. Then next week became next month, and the month after that became the discovery that you're in trouble.

The fundamental challenge with dependencies is that they exist at the intersection of two different teams' priorities. Your project is important to you. But to the team you depend on, it's an inbound request among a dozen other inbound requests, competing with their own roadmap commitments. Nobody is being malicious. The system is just structured such that the cost of a slipping dependency is paid by you, not by them.

This asymmetry — where the pain lands on a different team than the team making the decision — is the root cause of most dependency problems. Once you understand that, the solutions become more obvious. Your job is to change the incentive structure, create visibility, and make it easy for the other team to prioritize your needs before things get urgent.

The Anatomy of a Dependency

Before you can manage dependencies, you need to be precise about what you mean by the word. A "dependency" in project execution isn't just "something Team X has to do." That's too vague to act on. A dependency has a specific structure:

Notice how different "we depend on the Platform team for some API stuff" is from: "We need the Platform team's user profile API v2 with the timezone field, delivered by October 3rd. If it slips past October 10th, we cannot launch before the November freeze." The second version is actionable. The first version is just background anxiety.

The Five Types of Dependencies

Not all dependencies are the same, and treating them the same will cause you to over-manage some and catastrophically under-manage others. Here are the five types you'll encounter on a large project, and what makes each one different:

The most dangerous type is not the hardest one — it's the Review/Approval dependency. Engineers systematically underestimate how long review processes take. A security review that you think will take a week can take a month if the security team is backed up, if they find issues, or if the review uncovers work that needs to be redone. Legal and privacy reviews are even less predictable. The engineering culture of "ship it then we'll do the review" has delayed more launches than any technical problem.

Mapping Before You're Stuck

The right time to map your dependencies is before you start building. Not at kickoff. Not after the first milestone. Before. The reason is simple: a dependency you discover at the start of the project has three, six, or nine months of runway to be resolved. A dependency you discover at week ten has three weeks.

Dependency mapping is an exercise you do with your team and your key technical leads. You take your project plan — the milestones, the components, the launch requirements — and for every single piece, you ask: "What has to be true for this to work, that we don't own?" Write everything down. Then for each item, you find the owner.

The Dependency Graph

A dependency graph is a visual representation of what your project needs and where it comes from. You don't need fancy tooling. A whiteboard or a shared doc with a simple table works fine. What matters is that it's visible, updated, and reviewed regularly.

The columns you need in your dependency tracker are simple. Aim for the following:

Finding the Critical Path

Once you have your dependency tracker, the next step is to find the critical path. The critical path is the sequence of work where a one-day slip equals a one-day slip to launch. Everything off the critical path has some float — it can slip a bit without affecting the launch date. Everything on the critical path has zero float.

The critical path is almost never the longest list of tasks. It's the narrowest chain. Take your timeline, find the sequence of work where every step feeds the next with no slack, and that's your critical path. Every dependency on the critical path deserves your personal attention every week. Every dependency off the critical path can be monitored but doesn't need the same intensity.

The Dependency SLA: Getting Commitment Before You Need It

Here is the hardest truth about cross-team dependencies: a team that hasn't committed to a date hasn't committed to a date. "Yeah we should be able to get that to you" is not a commitment. "We'll try to do it in Q3" is not a commitment. An SLA — a Service Level Agreement — is a mutual, explicit commitment about what will be delivered, when, and what happens if it slips.

Most engineers hate the phrase "Dependency SLA" because it sounds like bureaucratic overhead. Here's a simpler way to think about it: it's a short written confirmation that you and the other team have the same understanding of what they're delivering and when. That's it. You write it, they read it, they say yes. The whole thing takes ten minutes and it has saved entire quarters of work from blowing up.

What Goes Into a Dependency SLA

A Dependency SLA is not a legal document and it doesn't need to look like one. It's usually a few bullets in a shared doc or a structured Slack message that you send, they confirm, and you both have a record of. Here's the structure:

This message takes five minutes to write and it does several important things at once. It forces precision — writing it down exposes vagueness. It creates a paper trail. It tells the other team that this is real, named, and tracked — not just a casual ask. It makes the consequences of slipping concrete. And it asks for explicit confirmation, which means silence is no longer ambiguous.

The most important line is: "flag us immediately — not at the deadline — if anything changes." This is the part most teams skip. And it's the part that causes disasters. When a team knows a dependency is at risk, they often wait until the deadline to tell you. They're hoping the situation will improve. They don't want to create alarm prematurely. They're busy. But from your perspective, finding out on October 24th that the API won't be ready is a crisis. Finding out on October 3rd that they're running two weeks behind is a problem you can work around. You need them to tell you early, and you need to explicitly ask for it.

When a Dependency Is Late

You did everything right. You mapped your dependencies early. You got explicit commitments. You sent weekly check-ins. And now it's three weeks before the date, and the other team is behind. This happens. The question is what you do next.

Early Warning Signals

Before a dependency is officially late, it shows signs of stress. The sooner you see these signals, the more options you have:

The common theme here is: do not wait for the other team to come to you. Your job is to have enough visibility into their progress that you see the problem before they've decided how to tell you about it. This requires a relationship — not surveillance. If you've built a good working relationship with your point of contact, they'll often tell you early and voluntarily. If the relationship is purely transactional, you won't hear about problems until they've become crises.

Escalating Without Burning the Bridge

Escalation is the word that makes everyone uncomfortable. It sounds aggressive. It implies you're going over someone's head, creating drama, making enemies. When done poorly, that's exactly what it does. When done well, it is simply the act of getting more senior people involved so that a decision can be made at the right level.

The fundamental rule of escalation: escalate the situation, not the person. There is a world of difference between "Team X is failing and their lead isn't responding" and "We have a project risk I want to make visible: we're dependent on Team X for X by Y date, and current signals suggest we may miss it. I'd like to get both teams' managers to align on how to handle it." The first destroys a relationship. The second solves a problem.

The key discipline: move through these steps deliberately and in order. Jumping straight to step four when step one hasn't happened is not escalation, it's ambush. The other team's manager finds out they have a problem at the same time they find out you've complained to your manager about it. That is a relationship-damaging move that you will feel for years. Go in order.

The "We'll Do It Ourselves" Decision

At some point in almost every complex project, someone on your team will say: "If Team X can't get us what we need, let's just build it ourselves." Sometimes this is the right call. Often it is not. It is never a decision to make in frustration.

Building it yourself solves the dependency problem by eliminating the dependency. But it creates a different problem: you now own something you weren't planning to build, maintain, operate, and support. The team that was supposed to build it has domain expertise you don't have. Their solution would have benefited from their years of context. Your solution will be built in weeks under pressure with none of that context. It will have bugs. It will have edge cases they would have known about. It will require on-call ownership in perpetuity.

None of this means you should never build it yourself. Sometimes the dependency is on a genuinely low-priority item for the other team. Sometimes the scope is small enough that the risk is manageable. Sometimes waiting is more expensive than building. But you need to evaluate this honestly, not emotionally.

The Four Questions

Buffer Teams and Coordination Debt

There is a pattern in large organizations called the "buffer team" — a team that exists between you and the team you actually need, whose primary job is to coordinate the coordination. You submit a request to the buffer team. They submit a request to the platform team. The platform team submits the change. Three weeks later, something ships. Nobody is sure exactly what happened.

Buffer teams are a symptom of an organizational problem: the real owners are too busy, too specialized, or too siloed to interact directly with every team that needs them. The buffer team exists to reduce their communication overhead. This is understandable. It is also, from a project execution standpoint, extremely dangerous.

Buffer teams introduce distance. Distance introduces lag. Lag introduces misunderstanding. By the time your requirement has passed through a buffer team to the real owner, the nuance of what you actually needed may have been lost. By the time the response comes back, the context has shifted. Requirements that needed clarification didn't get clarified; they got approximated.

When you're working through a buffer team, you need to do one thing: find the actual owner. Not to bypass the buffer team's process, but to supplement it. "I work through your PM for requests, but is there a technical lead I can speak with directly to make sure we get the requirements exactly right?" Most engineers on the other side of a buffer team are delighted to have a direct conversation with the person who actually knows what they need. The buffer team can keep their process; you just want to also have direct technical communication.

Coordination debt is the accumulation of unresolved ambiguity across multiple teams. Each handoff that happens without full context being transferred adds a small amount of debt. Each assumption that gets made instead of confirmed adds debt. Each week that passes without a dependency status check adds debt. Like financial debt, coordination debt compounds: small misalignments become larger misalignments, which become integration failures in the final sprint.

The only way to pay down coordination debt is through direct, explicit communication — regularly, not just at crisis moments. Weekly dependency check-ins, brief but consistent, are worth far more than a monthly escalation when things go wrong.

The Seven Most Common Dependency Management Mistakes

After watching dozens of projects navigate dependency problems, the same mistakes appear over and over. None of them are mysterious. All of them are avoidable.

Putting It All Together: The Dependency Review

The practical system that brings all of this together is the weekly dependency review — a ten-minute standing check-in that happens every week for the life of the project. It is not a status meeting. It is not a blame session. It is ten minutes where you and your tech lead go through every open dependency on the tracker and ask three questions:

Is it still on track? A quick confirmation from the owner. If the answer requires a long explanation, that's a signal.

Has anything changed that could affect it? Org changes, priority shifts, resourcing moves. This surfaces early warning signals before they become late warnings.

Does the status need to change? Green, Yellow, or Red. If it was Green last week and something changed, update it. The status is only useful if it's accurate.

This ten-minute ritual, done consistently, is worth more than any dependency tracking system, any project management tool, or any escalation process. The dependencies that kill projects are always the ones that looked fine until they suddenly weren't. The weekly review is the mechanism that finds the "it's fine" dependencies that are quietly about to become "it's not fine" dependencies.