Quick Framework
When teams disagree on priorities:
Engineering says: "Fix tech debt" (velocity impact) Sales says: "Close Enterprise customer with custom feature" Product says: "Build strategic features for growth"
Nobody is wrong. They're optimizing for different metrics.
Actionable Steps
1. Agree on Business Metric First
Is it: Revenue? Growth? Customer satisfaction? Pick one North Star.
2. Show How Each Priority Moves the North Star
Engineering's tech debt → enables faster shipping → higher velocity → more features shipped → higher growth
Sales' custom feature → closes $X revenue
Product's feature → $Y potential revenue
Now priorities are comparable.
3. Portfolio Approach
Allocate budget across priorities:
- 70% on strategic features
- 20% on custom/sales support
- 10% on tech debt
Explicit allocation prevents constant re-litigation.
Key Takeaways
- Agree on North Star metric first. Otherwise, teams optimize for different things and conflict is inevitable.
- Portfolio approach beats negotiation. Lock allocations quarterly.
- Shared dependencies are conflict amplifiers. Map them explicitly, or watch priority conflicts cascade.
The Hidden Cost of Multi-Squad Conflicts
Picture this: You're running a platform with 4 squads. Squad A (Payments) needs Backend Engineer Jenkins for a critical security audit (2 weeks). Squad B (Billing) needs Jenkins to fix a revenue-blocking bug in invoice generation (1 week). Squad C (Analytics) is waiting on Jenkins to unblock data pipeline work (3 weeks).
Jenkins is 1 person. Three squads. Three non-negotiable priorities.
What happens?
Without a conflict resolution system:
- Jenkins gets pulled between meetings
- Whoever yells loudest wins today (usually sales-facing work)
- Work context-switches 5x per day
- Actual productivity: 40% of calendar time
- Morale: "Nobody respects engineering"
- Result: All three projects slip by 2 weeks
With a conflict resolution system:
- Priority 1: Security audit (risk of breach > revenue bug > analytics delay)
- Jenkins works on audit for 2 weeks
- Squad B gets contractor support for 1 week
- Squad C delays 1 week with advance notice
- Result: Security audit ships on time. Controlled trade-offs.
The Anatomy of Multi-Squad Conflicts
Type 1: Shared Resource Conflicts
Two or more squads need the same specialized person simultaneously.
Example: Backend engineer needed by both Payments and Onboarding squads.
Economics of delay:
- Onboarding delay: $50K MRR lost after day 7
- Payments feature: $100K MRR if shipped this quarter, $0 if next quarter
- Contractor for Onboarding: $8K/week
Decision: Fund contractor, keep engineer on payments. Total cost: $8K. Benefit: $100K. Clear trade-off.
Type 2: Dependency Chains
Squad A is blocked on Squad B's work. Squad B's priority is lower.
Example: Platform team needs to deliver a new API before Mobile team can build the new feature.
Impact cascade:
- Platform delay → Mobile team idle → end-user feature delayed → revenue miss
Solution: Make dependency explicit in roadmap. Platform team visibility to downstream impact.
Type 3: Strategic vs. Tactical Conflicts
Product wants to build new features (strategic, high impact). Engineering wants to pay down tech debt (tactical, high impact on velocity).
Example: "Ship feature X now" vs. "Rewrite infrastructure, then ship feature X faster."
Resolution: Portfolio allocation. "60% new features, 40% tech debt" locks the conversation. No re-litigation mid-quarter.
The Conflict Resolution Framework: 4 Steps
Step 1: Map All Dependencies (Pre-Planning)
Before planning starts, identify:
- Which squads depend on which?
- What are the critical path items?
- Which shared resources are bottlenecks?
RACI Matrix for Dependencies:
| Task | Product | Engineering | Design | Platform | Owner |
|---|---|---|---|---|---|
| New onboarding flow | Consult | Execute | Lead | Consult | Design |
| API versioning | Consult | Lead | — | Support | Engineering |
| Mobile migration | Lead | Consult | Consult | Lead | Product |
Identify where columns have multiple "Lead" entries. Those are conflict zones.
Step 2: Establish Decision Framework
Agreed North Star: "Maximize ARR growth while maintaining platform stability"
Priority tiers for conflicts:
- Tier 1 (Revenue-blocking): If we don't fix this, we lose $X in MRR. Examples: Security vulnerabilities, billing bugs, onboarding blockers.
- Tier 2 (Strategic): High-impact feature shipped this quarter. ARR impact: $500K+.
- Tier 3 (Operational): Tech debt, infrastructure, nice-to-have features.
Conflict resolution rule:
- Tier 1 beats Tier 2 beats Tier 3
- Within same tier: Measured by ARR impact
- Shared resources allocated to highest-impact project first
Step 3: Quantify Impact for Each Project
Before conflict discussion, each squad prepares:
Impact Statement:
- Revenue impact if shipped this quarter
- Revenue impact if delayed to next quarter
- Customer impact (churn, satisfaction, etc.)
- Downstream impacts (dependencies)
Example:
- Squad A (Payments): "Security audit shipping = avoid $2M potential breach liability. Delay = 1 week accepted risk increase."
- Squad B (Billing): "Invoice bug = $150K/week MRR loss. Fix cost: 1 engineer for 1 week."
- Squad C (Analytics): "Data pipeline delay = analytics team idle. Impact: $0 direct loss, but 3 people unproductive."
Now the conversation has a shared language: risk/revenue/impact, not opinions.
Step 4: Make Trade-Offs Explicit
Once impacts are quantified:
If total demand > capacity:
Option A: Pull Jenkins to Payments security audit.
- Cost: Analytics team idle ($15K/week), Onboarding delay ($50K MRR loss)
Option B: Hire contractor for Onboarding bug fix.
- Cost: $8K/week contractor
- Benefit: Jenkins keeps working on strategic project (Payments) + security audit completes
Option B saves $42K net vs. Option A. Clear decision.
Document the trade-off:
- "We chose Jenkins on Payments because security audit prevents $2M liability. Onboarding bug fixed by contractor (cost: $8K, speed: full attention). Analytics delayed 1 week, and we're notifying stakeholders with advance notice."
- Stakeholder communication: "We have 3 priorities. Here's how we're sequencing them."
Real-World Case Study: Multi-Squad Conflict Resolution
Company: Scale-Up SaaS (4 engineering squads)
The Crisis (Pre-Framework):
Q3 Planning: Everyone has a critical priority.
- Squad A (Payments): "We need the payments optimization project. 50% revenue impact."
- Squad B (Onboarding): "Onboarding is broken. Customer activation is down 15%."
- Squad C (Platform): "API infrastructure is melting. We need database migration."
- Squad D (Analytics): "Analytics performance is unbearable. Customers are complaining."
All 4 need the same 2 senior backend engineers.
Old Approach (What They Used to Do):
- CEO declared Squad A highest priority
- Squad A got both engineers
- Squads B, C, D slipped by 2 months
- Onboarding activation didn't recover
- Platform infrastructure became a crisis later
New Approach (What They Did):
Step 1: Map Dependencies
- Squad B (Onboarding) depends on Squad C (Platform) for new API. They're blocked.
- Squad A (Payments) and Squad D (Analytics) are independent.
Step 2: Quantify Impact
- Squad A (Payments): "$200K ARR if shipped Q3, $0 if Q4"
- Squad B (Onboarding): "$50K/month ARR loss (continues until fixed)"
- Squad C (Platform): "Infrastructure debt adds 20% to all future projects"
- Squad D (Analytics): "Annoying, but not revenue-blocking"
Step 3: Decision
- Priority 1: Squad C (Platform) gets 1 senior engineer. Unblock downstream.
- Priority 2: Squad A (Payments) gets 1 senior engineer. Revenue-critical.
- Priority 3: Squad B (Onboarding) gets contractor support ($8K/week) to unblock faster than waiting for Squad C.
- Priority 4: Squad D (Analytics) delayed 1 month. Engineering team aware and planning accordingly.
Result:
- Platform migration: On time
- Onboarding: Fixed in 2 weeks (contractor), activation recovered, revenue loss avoided
- Payments: Shipped Q3, revenue captured
- Analytics: Delayed 1 month, but predictable
- Total cost: $32K contractor investment. Benefit: $250K+ ARR protected + $200K new revenue
Anti-Pattern: "Constant Priority Re-Litigation"
The Problem:
- Weekly: Squad A asks CEO to bump their priority
- Weekly: CEO caves and re-prioritizes
- Result: Whirlash. No squad finishes anything.
The Fix:
- Lock priorities quarterly
- "Additions require deletions" rule
- Emergency re-prioritization is allowed once per quarter maximum, with explicit trade-off statement
- Enforce the discipline
Prodinja Connection
Conflicts between squads often hide in misalignment nobody's tracking explicitly — a dependency that got a nod in a hallway conversation six weeks ago and was never revisited, a stakeholder whose priorities have quietly drifted from what the roadmap assumes. Prodinja's Stakeholders CRM is designed to let you log each squad lead or stakeholder as a relationship, and it computes a relationship health score alongside an "alignment-debt" score, so drift can show up as a number before it shows up as a missed deadline. Used well, it can turn "Squad A is blocked on Squad B's work" from a surprise raised in standup into something you saw coming — and lets you walk into the conflict conversation already knowing who's aligned, who's drifted, and roughly what resolving it will cost.
Key Takeaways (Expanded)
-
Map dependencies before planning. Explicitly identify shared resource bottlenecks and cascade impacts.
-
Quantify impact in business terms. Replace opinion-based conflicts with fact-based trade-offs. "Revenue loss vs. cost to fix" is clearer than "This is critical."
-
Use portfolio allocation for recurring conflicts. "40% new features, 20% tech debt, 40% support/maintenance" removes re-litigation.
-
Make trade-offs explicit and communicate them. Stakeholders accept delay better when they understand why and when it ends.
-
Re-prioritization should be rare and expensive. Once per quarter. Not weekly.