The Politics of Multi-Team Projects: When You Need Other Teams to Deliver (And They Don't Report to You)
The Project That Depends on Everyone Else
Picture a network upgrade project. Your part is ready. Design complete. Equipment ordered. Team prepared. Timeline clear.
But you need:
Security team to update firewall policies
Server team to update DNS configurations
Application team to update connection strings
Facilities to run new fiber between buildings
Vendor to deliver equipment on schedule
The problem:
None of these teams report to you. Each has its own manager, priorities, and timeline. Your "urgent" project is their "we'll get to it when we can."
What happens next is predictable:
The security team is understaffed and backlogged. Your firewall policy request sits in their queue for three weeks.
The server team prioritizes your request behind two other projects that their leadership considers more urgent.
The application team says they can help, but their developer won't be available until the next sprint, which starts in five weeks.
Facilities is juggling 15 projects, and yours isn't their top priority.
Vendor promises equipment delivery date, then pushes it back twice.
Meanwhile:
Your boss asks: "When will this be done?"
Your team is ready but waiting.
Stakeholders are frustrated by delays.
And you're stuck in the middle with no authority over any of the teams blocking your progress.
Welcome to multi-team projects - where technical skills matter less than political navigation, and your success depends entirely on your ability to influence people who don't report to you.
This is one of the hardest aspects of technical management. Let's talk about what actually works.
Why Multi-Team Projects Are So Hard
Before diving into tactics, understand why this is genuinely difficult:
The Authority Gap
You're responsible for outcomes you don't control.
Your project's success requires deliverables from other teams. You can't assign work to those teams. You can't prioritize their backlog. You can't performance-manage them.
You have responsibility without authority. That's a fundamentally difficult position.
Competing Priorities
Every team has its own priorities.
What's urgent to you is one of 15 requests the security team received this week. Your timeline emergency is not their timeline emergency.
They're optimizing for their objectives, not yours. That's not malicious - it's organizational reality.
Different Incentives
Teams are measured on different outcomes.
You're measured on project delivery. The security team is measured on incident response time and vulnerability remediation. The server team is measured on uptime and service reliability.
Helping your project might conflict with their performance metrics.
Communication Overhead
Every additional team increases coordination complexity.
One team: simple. Two teams: manageable. Five teams: coordination nightmare.
Each team has different tools, processes, communication preferences, and meeting schedules. The coordination overhead grows exponentially.
The Blame Game
When multi-team projects fail, everyone points at each other.
"We delivered our part on time; it's [other team] that's delayed."
"We would have delivered if [another team] had given us what we needed."
"The requirements kept changing because [someone else] couldn't make decisions."
Accountability gets diffused across multiple teams, making it hard to address problems directly.
The challenge of being responsible for outcomes you don't control connects to When Your Team Is Right and Leadership Is Wrong - sometimes the constraints are organizational, not technical.
The Common Scenarios (And Why They're Frustrating)
Let's get specific about situations you'll face:
Scenario 1: The Silent Blocker
What happens:
You send a request to another team. No response. You follow up. Still nothing. You escalate. Finally get a response: "We'll look at this next sprint."
The next sprint comes. Nothing. Follow up again. "Oh, we had some urgent issues come up. We'll get to it."
Why it's frustrating:
You can't force them to respond. You can't escalate without seeming difficult. Your project is stalled on something they could probably handle in 2 hours if they prioritized it.
The impact:
Your timeline slips. Your team sits idle. Your stakeholders question your competence. But the blocker isn't your team - it's a team you have no control over.
Scenario 2: The Moving Target
What happens:
You coordinate with multiple teams on a cutover window. Everyone agrees: Saturday midnight. You send calendar invites. Everyone accepts.
Thursday: One team realizes they have a conflict. Asks to move to Sunday.
Friday: Another team says they can't do Sunday, their person is on call for something else.
Saturday morning: Third team discovers they need an extra week of prep.
Why it's frustrating:
Coordinating five teams' calendars is nearly impossible. Every change creates ripple effects. Nobody thinks their schedule change is a big deal, but combined, they make the project impossible to schedule.
The impact:
Delays cascade. Equipment rental gets extended (costs money). Stakeholder confidence erodes. Some teams prepare unnecessarily, wasting effort.
Scenario 3: The "Not My Job" Response
What happens:
You need another team to configure something. Their response: "That's not really our area. Have you talked to [different team]?"
You talk to the different team. They say: "We don't own that. [First team] should handle it."
You're now in a loop between two teams, both claiming it's not their responsibility.
Why it's frustrating:
Organizational boundaries are fuzzy. Nobody wants additional work. Everyone points to someone else.
The impact:
Work falls into the gap between teams. You end up either doing it yourself (outside your team's scope) or escalating to leadership to force clarity on ownership.
Scenario 4: The Surprise Requirement
What happens:
You're 80% through the project. Another team finally reviews your requirements. They identify something: "You need to integrate with our system differently than you planned."
This requires significant rework. Change your timeline. Might require different equipment.
Why it's frustrating:
If they'd reviewed the requirements three months ago when you asked, this would have been addressable. Now it's a crisis because their delayed review created late-stage surprises.
The impact:
Timeline blows out. The budget might increase. Stakeholders are unhappy and the team that caused the delay probably won't face consequences because "they were just doing their job reviewing requirements."
Scenario 5: The Scope Creep From Dependencies
What happens:
You're working with another team on integration. During implementation, they mention: "Oh, while we're at it, can you also handle [additional thing]?"
It seems small. You agree. Then another small request. And another. Suddenly, the scope has doubled, but the timeline hasn't.
Why it's frustrating:
Saying no feels difficult when you need their cooperation with your original request. But saying yes creates scope creep that damages your project.
The impact:
The original project suffers because you're doing work outside the scope. Or you say no and damage the relationship, making future collaboration harder.
What Doesn't Work (But You'll Try Anyway)
Let's talk about approaches that seem logical but fail predictably:
Failed Approach 1: Escalating Immediately
What it looks like:
Another team isn't responding fast enough. You escalate to your boss or theirs. "Can you make [team] prioritize my request?"
Why it fails:
Escalation burns political capital. Use it too often, and you become "that manager who can't work with other teams."
Even if escalation works this time, you've damaged the relationship. Next time you need that team, they will remember you escalated instead of working with them.
When escalation IS appropriate:
Real blocking issues where collaboration has genuinely failed. Not as a first response to slower-than-you 'd-like progress.
Failed Approach 2: The Email Ultimatum
What it looks like:
"If we don't receive [deliverable] by Friday, the project will be delayed, and we'll have to inform leadership that [your team] is the cause."
Why it fails:
Threatening rarely produces cooperation. It produces defensiveness and resentment.
Even if they deliver under threat, they'll remember. Future collaboration will be harder.
The alternative:
"Help me understand what would need to change for Friday delivery to be possible. What's blocking that timeline?"
Failed Approach 3: Going Around Them
What it looks like:
The other team won't help. You ask your team to do their work instead. "We'll just handle the DNS changes ourselves."
Why it fails:
You're crossing organizational boundaries. If something breaks, you're responsible, but don't have the expertise.
The other team gets upset that you went around them. Future collaboration is damaged.
When it's appropriate:
Never, unless explicitly negotiated: "Would it help if we drafted the DNS changes and sent them to you for review and implementation?"
Failed Approach 4: Public Shaming
What it looks like:
In a status meeting with leadership present: "We're blocked waiting on [team]. They haven't responded to our requests."
Why it fails:
Public blame creates enemies. That team will remember, making future collaboration difficult.
Even if leadership pressures them to help, the damage to the relationship costs you in the long term.
The alternative:
Before the meeting, privately: "I need to update leadership on the timeline. I'll need to mention we're waiting on your team's input. What's a fair way to characterize that?"
Failed Approach 5: The Passive-Aggressive Follow-Up
What it looks like:
"Just following up again on this. Third request. Still waiting. Wondering if you received my previous emails?"
Why it fails:
Passive-aggression creates resentment without creating action. They know you're frustrated. Adding more frustrated emails doesn't help.
The alternative:
Pick up the phone. Have a real conversation. "Hey, I keep emailing, but I'm not sure if email is working. Can we talk about what you need from me to move this forward?"
What Actually Works: A Framework for Multi-Team Success
After navigating these situations repeatedly, patterns emerge around what actually produces results:
Strategy 1: Build Relationships Before You Need Them
The principle:
Political capital is earned before you need to spend it. Build relationships with peer teams during peacetime, not during a project crisis.
What this looks like:
Regular informal contact:
Coffee chats with peer managers. Not about projects. About challenges, organizational dynamics, and their priorities.
"How are things going with your team? What's keeping you busy?"
Offering help first:
"I noticed you're working on [project]. If there's anything my team can help with, let me know."
Build a relationship where you've helped them before asking for help.
Understanding their world:
What are they measured on? What's hard for them? What are their constraints?
Why this works:
When you need help, you're not a random name in their inbox. You're someone they have a relationship with.
People help people they know and like. That's human nature. Use it.
Strategy 2: Make It Easy for Them to Help You
The principle:
The easier you make it for other teams to help, the more likely they are to help.
What this looks like:
Do their homework for them:
Don't: "We need firewall rules updated."
Do: "We need these specific firewall rules [detailed list with source, destination, ports, business justification]. I've formatted it in your team's standard template. Just need review and approval."
Provide all context upfront:
Why is this needed? What it enables. Business justification. Timeline. Impact if delayed.
They shouldn't have to ask follow-up questions to understand.
Offer flexible timing:
Don't: "We need this by Friday."
Do: "Ideally, we'd have this by Friday for our timeline, but we can work with anything before the 15th. What's realistic for your schedule?"
Respect their process:
If they have a ticketing system, use it. If they have a request template, fill it out completely. If they have a standard meeting cadence, work within it.
Why this works:
You're removing friction. The path of least resistance for them is to help you.
Compare that to requests that create work for them: incomplete information, unclear requirements, urgent demands outside their process.
Strategy 3: Frame Requests in Terms of Their Priorities
The principle:
People prioritize work that helps them achieve their goals. Frame your request in terms of what matters to them.
What this looks like:
Security team:
Don't: "We need this firewall change for our project."
Do: "This firewall change supports our security posture by [specific security benefit]. It's part of our effort to [security goal they care about]."
Server team:
Don't: "We need DNS changes."
Do: "These DNS changes support the infrastructure standardization you're working toward. It eliminates a legacy configuration that's been causing support tickets."
Application team:
Don't: "You need to update connection strings."
Do: "This change improves application resilience by [specific benefit to their apps]. Reduces risk of downtime from [current vulnerability]."
Why this works:
You're speaking their language. The work isn't "help another team's project." It's "advance your own team's objectives."
Framing requests in language stakeholders care about connects to Explaining Technical Topics to Non-Technical People - translation is a core leadership skill.
Strategy 4: Create Shared Accountability
The principle:
When everyone shares ownership of outcomes, everyone has an incentive to make it work.
What this looks like:
Joint success metrics:
Not: "My project success depends on your delivery."
Instead: "We're both measured on [shared outcome]. How do we structure this so we both succeed?"
Shared visibility:
Create a shared status dashboard or update the process. Everyone sees the same information about overall progress and blockers.
Collaborative problem-solving:
When blockers appear, bring teams together to solve rather than blaming.
"We've hit a blocker. Let's figure out how to work around it together."
Why this works:
Moves from "my project" to "our project." Creates collective ownership rather than finger-pointing.
Strategy 5: Understand and Work With Their Constraints
The principle:
Other teams have real constraints. Understanding and working within them produces better results than fighting them.
What this looks like:
Ask about their constraints:
"What would make this hard for your team?"
"What concerns do you have about this timeline?"
"What would you need to make this work?"
Adapt to their reality:
If they're understaffed, you might be able to do some prep work to reduce their workload.
If they're backlogged, maybe your timeline can flex.
If they lack expertise in an area, you may be able to provide documentation or training.
Acknowledge their challenges:
"I know your team is slammed right now. I appreciate you making time for this."
Not: "I don't care about your constraints, just deliver."
Why this works:
You're demonstrating that you understand they're not being difficult - they have real challenges. That builds goodwill and willingness to find solutions.
Specific Tactics That Work
Beyond high-level strategy, here are specific tactics that produce results:
Tactic 1: The Pre-Commitment Conversation
Before making formal requests:
Have informal conversations with key teams to understand feasibility and get soft commitments.
"We're planning a network upgrade in Q3. It'll require [X] from your team. Is that feasible? What concerns do you have?"
Why this works:
You're including them early. They can raise concerns before you've committed to a timeline. They feel ownership because they helped shape the plan.
Contrast with:
Sending them a formal request with a timeline already set, then being surprised when they say it's not possible.
Tactic 2: The Stakeholder Ally
Identify someone in the other team who benefits from your project succeeding.
Maybe an engineer frustrated by the current state and eager to fix it.
Maybe a manager who sees political benefit in the project.
Work with them to navigate their team's dynamics:
"What's the best way to approach your manager about this?"
"When's the best time to request this from your team?"
"Can you help advocate for prioritizing this?"
Why this works:
Inside ally who understands their team's politics and can navigate it better than you can.
Tactic 3: The Escalation Preview
Before escalating, preview it with the team:
"I don't want to escalate this, but I'm getting pressure from my leadership about the delay. Can we find a path forward before I need to involve our managers?"
Why this works:
Signals seriousness without actually escalating. Gives them the opportunity to solve it before escalation happens.
Often produces action because nobody wants their boss dealing with it.
Tactic 4: The Flexible Timeline Trade
Offer flexibility on your timeline in exchange for commitment on theirs:
"If I can push our cutover from June to July, can you commit to delivering by June 15th? That gives you an extra month."
Why this works:
You're negotiating, not demanding. They get something (more time) in exchange for commitment.
Creates explicit agreement rather than vague "we'll try."
Tactic 5: The Visible Dependency Chain
Create visible documentation showing how delays cascade:
"Server team delivers June 1 → Application team configures June 5 → Testing June 6-10 → Cutover June 12."
"If the server team slips to June 8, cutover moves to June 19. If the app team needs more time, cutover moves to June 26."
Why this works:
Makes the impact of delays visible to everyone. Creates a shared understanding of dependencies.
Nobody wants to be the obvious bottleneck on a visible project.
Tactic 6: The "What Would It Take?" Question
When you get resistance or delays:
"What would it take to make [desired outcome] possible?"
Then actually listen and address what they say.
Why this works:
Shifts from "will you do this" to "how can we make this work." Collaborative instead of demanding.
Often reveals constraints you didn't know about that you can actually address.
Managing Upward When Dependencies Fail
Your boss doesn't care which team is blocking you. They care whether the project will be delivered. How do you manage upward when dependencies fail?
What NOT to Do
Don't throw other teams under the bus:
"We're delayed because [team] won't deliver."
Even if true, this makes you look like you can't work with others.
Don't hide the dependency:
"We're on track" when you're actually blocked.
When the delay becomes obvious, you'll have a credibility problem.
Don't be vague:
"Some dependencies are taking longer than expected."
Doesn't give your boss the information they need to help or adjust expectations.
What Actually Works
Be specific about the dependency:
"We're waiting on firewall policy updates from the security team. We requested June 1, and they've committed to June 8."
Explain what you've done:
"I've worked with their manager to prioritize this. The delay is due to their team being backlogged with incident response from last week's security event."
Describe the impact clearly:
"This delays our cutover from June 12 to June 19. Stakeholders have been notified. Equipment rental extends one more week, adding $2K to the budget."
State what you're doing about it:
"I'm working with them daily to ensure June 8 delivery. We've also identified an alternative approach if they slip further - we can do a partial implementation that doesn't require their policy changes, with full implementation in July."
Why this works:
You're being transparent about reality without blaming. You're showing you're actively managing it. You're giving your boss the information they need.
Your boss can then decide whether to escalate or accept your plan.
When to Ask Your Boss to Intervene
Appropriate escalation scenarios:
You've tried everything and genuinely can't make progress
The other team is completely non-responsive
There's a policy or organizational issue only leadership can resolve
Timeline is truly critical, and delays have a severe business impact
How to ask:
"I've been working with [team] for three weeks on [dependency]. I've tried [specific things]. We're still blocked. I think this needs leadership-level escalation. Would you be willing to talk to [their manager]?"
Not:
"[Team] won't help. Make them do it."
When You're the Team Everyone Depends On
Important perspective shift:
Sometimes you're not the one waiting on dependencies - you're the dependency blocking someone else's project.
How to be a good dependency:
Respond promptly to requests:
Even if you can't help immediately, acknowledge the request and give a realistic timeline.
Be honest about constraints:
"We can't do June 1, but June 8 is realistic. Here's why..."
Better than agreeing to June 1 and missing it.
Communicate proactively about delays:
Don't wait for them to ask for status updates. Tell them if the timeline changes.
Understand their urgency:
"Help me understand why this timeline matters. What happens if we slip?"
Sometimes there's real flexibility you don't know about. Sometimes there's a hard constraint you should understand.
The golden rule:
Treat other teams' requests the way you'd like them to treat yours.
The Organizational Patterns That Make This Easier
Some organizations make multi-team collaboration easier. Some make it nearly impossible.
What Good Looks Like
Clear ownership boundaries:
Everyone knows who owns what. When ownership is ambiguous, there's a documented process for resolving it.
Shared metrics across teams:
Teams are partially measured on cross-team collaboration success, not just their own team's metrics.
Dedicated integration roles:
Program managers or technical project managers whose job is coordinating multi-team work.
Regular cross-team forums:
Standing meetings where teams coordinate, not just ad-hoc collaboration when problems arise.
Escalation paths that work:
When teams can't resolve dependencies, there should be a clear escalation path to leadership, who will make decisions.
What Makes It Impossible
Competing priorities from leadership:
Different executives giving different teams conflicting priorities, then expecting teams to magically align.
No shared visibility:
Every team uses different tools, different status reporting, and different processes. Nobody can see the whole picture.
Metrics that discourage collaboration:
Teams are measured only on their own deliverables with no incentive to help others.
Organizational silos:
Teams that rarely interact except when forced by projects. No relationship foundation.
No consequences for being a bad dependency:
A team that consistently blocks others faces no accountability.
Organizational dysfunction that makes collaboration impossible connects to Changing Culture as a New Manager - sometimes the problem is systemic, not individual.
The Bottom Line: Influence Without Authority
Here's what becomes clear after navigating multi-team projects repeatedly:
Your success as a technical manager increasingly depends on your ability to get work done through people who don't report to you.
The higher you go in management, the more true this becomes.
Authority is the weakest form of influence.
Even when you have authority (over your own team), influence through relationships, persuasion, and collaboration produces better long-term results.
Multi-team projects fail more often due to political issues than to technical ones.
The technical work is usually straightforward. The hard part is aligning people across organizational boundaries.
What actually works:
Build relationships before you need them
Make it easy for others to help you
Frame requests in terms of their priorities
Understand and work with their constraints
Create shared accountability
Communicate upward honestly about dependencies
What doesn't work:
Demanding cooperation based on urgency
Escalating as a first resort
Blaming other teams publicly
Ignoring their constraints and priorities
Assuming your project is everyone's priority
The skills that matter:
Relationship building
Persuasion and influence
Understanding organizational dynamics
Managing up effectively
Navigating ambiguity
Patience with organizational friction
The uncomfortable truth:
You can do everything right and still get blocked by dependencies you can't control. That's organizational reality.
Your job is to maximize the probability of success while managing expectations about what's actually within your control.
The long-term investment:
Every multi-team project is an opportunity to build relationships and political capital.
Handle dependencies well, and next time those teams will be more willing to help.
Handle them poorly, and you create enemies who make future collaboration harder.
In multi-team projects, technical management becomes more about people than technology.
The sooner you embrace that reality, the better you'll navigate it.
📧 Navigating multi-team projects and organizational complexity? Subscribe to my monthly newsletter for practical perspectives on cross-team collaboration, building influence without authority, and getting work done across organizational boundaries. First Tuesday of every month. Sign up here
What's your biggest multi-team project challenge? How do you handle dependencies on teams you don't control? Share your experiences in the comments or connect with me on LinkedIn - we're all navigating this together.
Disclaimer: The views and experiences shared in this blog are based on common patterns observed across the network engineering community and do not represent any specific company, team, or individual.