Cross-Team Dependencies and the Critical Path: A TPM Interview Guide
For a Technical Program Manager, the critical path runs through teams you do not manage. Here is how to find the program's critical path across organizational boundaries, and how to reason about it in an interview.
By The Cala Voice Team ·The mechanics of the Critical Path Method are the same whether you are running one team or ten. What changes for a Technical Program Manager (TPM) is where the critical path runs. On a single-team project, the longest dependent chain of tasks lives inside one backlog you can see. On a cross-team program, that chain crosses organizational boundaries, threading through teams that do not report to you, each with its own roadmap and its own reasons to deprioritize your program. The skill an interviewer is testing is not calculating a path. It is managing one that runs through people you cannot direct.
If you want the underlying mechanics, the Critical Path Method for Project Managers covers float, schedule compression, crashing, and fast-tracking in detail. This article assumes those and focuses on what the method looks like at program scale.
The Program Critical Path Runs Through Other Teams
On a technical program, the tasks on your critical path are usually owned by different teams. The mobile team ships the client, which depends on the platform team's application programming interface (API), which depends on the infrastructure team provisioning capacity. The chain is real, but no single manager owns all of it. Your critical path is a line drawn across the org chart.
This changes the job in a specific way. On a single team, you shorten the critical path by reallocating people you influence directly. On a program, the critical-path task that is slipping belongs to a team whose manager has their own priorities, and you have no authority to reassign anyone. The path is the same concept. The lever is different: it is influence, not instruction.
The first move is therefore visibility. You cannot manage a program critical path you have not mapped across teams, because each team sees only its own slice and assumes the seams are someone else's problem. Building the cross-team dependency map, and keeping it current as teams replan, is the foundational TPM skill the critical path depends on.
Float Tells You Which Team's Slip Actually Threatens the Program
At program scale, float is what stops you from firefighting every team's local delays. A team can be behind on its own work and still not threaten the program, because that work sits on a path with slack. Another team can slip by a single day on a task with zero float and put the entire program date at risk.
The practical consequence is that a TPM does not treat all teams' status updates as equally urgent. The team on the critical path with no float gets disproportionate attention, escalation cover, and unblocking effort. A team comfortably off the critical path gets left to manage itself. Spreading attention evenly across every team is how a program manager drowns while the actual risk goes unwatched.
And because teams replan constantly, the program critical path shifts more often than a single project's does. A dependency that had two weeks of buffer last month can be on the critical path today because an upstream team reprioritized. Re-deriving the path after every major replan is not busywork, it is the only way the map stays true.
A Worked Example: One Program, Five Teams
Take a feature launch that needs five teams. Durations are in weeks, and the program launches when the mobile client, the web client and the analytics are all done.
| Work | Team | Weeks | Depends on | Float |
|---|---|---|---|---|
| Provision capacity | Infrastructure | 3 | None | 0 |
| Build the API | Platform | 4 | Capacity | 0 |
| Ship the mobile client | Mobile | 3 | API | 0 |
| Ship the web client | Web | 2 | API | 1 |
| Instrument analytics events | Data | 4 | None | 6 |
The critical path runs infrastructure → platform → mobile: 10 weeks, across three teams that report to three different managers.
Two updates arrive in the same week. The data team says analytics will be two weeks late. The infrastructure team says capacity will be one week late because they reprioritized. The data slip is the louder one, and it does not matter: analytics still finishes with four weeks to spare. The infrastructure slip is quieter, and it moves the launch by a week, because everything downstream waits on it. That is where your attention goes. First, find out what would let infrastructure recover the week. If nothing can, the program date moves, and the people who own that date need to hear it now, not at the next review.
Keep an eye on the web client too. If its two weeks turn into three, it ties with mobile for the critical path. Any more, and the web team sets the launch date.
When a Critical-Path Dependency Is Owned by a Team That Will Not Prioritize It
This is the scenario TPM interviews are built to surface, and it has no clean answer that relies on authority. A task on your critical path is owned by a team that has it low on their own backlog. You cannot reassign it. Telling them "it is on my critical path" means nothing to a team optimizing for their own goals.
The move is to make the dependency legible in their terms and to escalate on program risk, not on personal blockage. First, connect the work to something they already care about, because a team moves for their own Objectives and Key Results far faster than for your timeline. Second, if influence alone does not clear it, escalate. Naming the critical path is what makes that escalation legitimate: you are not asking for a favor, you are surfacing a program-level risk that a decision-maker needs to resolve. How to frame that escalation without burning the relationship is covered in influence without authority in TPM interviews.
How the Critical Path Shows Up in TPM Interview Questions
Interviewers ask scenarios that force you to reason across teams, not within one.
Typical questions: "How do you decide which team to push when several are behind?" Or "A team that owns a dependency on your program keeps deprioritizing it. What do you do?"
What a strong answer does:
It anchors on the program's critical path: which slipping work has zero float and actually threatens the date, versus which teams are behind on work with slack. It treats the critical-path dependency as the priority regardless of which team owns it, and it clears a resistant owner by connecting the work to that team's own goals first, then escalating on program risk with the specific date and decision named, rather than complaining that a team is uncooperative. It notes that the path is remapped as teams replan.
What a weak answer does: pushes every behind team equally, or jumps straight to "escalate to their manager" without first making the dependency matter to the owning team. Both read as someone who tracks status but does not manage cross-team risk by structure.
Common Mistakes
Mapping the path only within your own view. The program critical path lives in the seams between teams. If you only see one team's plan, you will miss the dependency that actually sets the date.
Treating another team's committed date as a fact. A date on another team's roadmap is a forecast made under their priorities, not yours. Ask what it depends on and what would move it, and track it as a risk rather than copying it into your plan.
Leading with escalation. Escalating before you have made the dependency legible to the owning team signals you cannot influence without authority, which is the exact skill the role exists for.
Leaving the handoffs unowned. The work between teams, such as integration testing, contract changes and environment setup, often sits on the critical path while appearing on no team's backlog. Give each handoff an owner and a date, or it will be the task nobody knew was late.
The Critical Path Method in a TPM Interview
At program scale, the Critical Path Method is less a scheduling calculation and more a prioritization and influence tool: it tells you which of many teams' delays actually matter, and it gives your escalations a concrete, defensible basis. It builds on the dependencies you surface when reading a system design, and it feeds directly into portfolio risk management, where those same cross-team dependencies become the risks you manage at the program level. Reasoning from the program critical path, using float to prioritize across teams, and clearing dependencies through influence before escalation is a strong signal that you operate at program scope rather than project scope.
For the full interview process this framework fits into, What Is a Technical Program Manager Interview? Complete Overview for First-Timers covers every stage of the loop and what each round tests.
Cala Voice runs you through cross-team program scenarios built around exactly this kind of dependency and influence reasoning, so you can practice walking through a program critical path out loud before it comes up in a real interview.