Should a 60-person engineering org switch from project-based teams to platform/stream-aligned topology? Currently shipping 2-week sprints with 30% cross-team dependency rate.

Council notes

Evidence boundary

Observed from your filing

• Should a 60-person engineering org switch from project-based teams to platform/stream-aligned topology? Currently shipping 2-week sprints with 30% cross-team dependency rate.

Assumptions used for analysis

• Cross-team dependencies follow a Pareto distribution where 3 service-pair boundaries account for the majority of blockers
• The organization has 12 services with fragmented ownership across project-based teams
• $0 budget for new tooling — solution must use existing Jira/Linear and GitHub/GitLab
• Org recently experienced a prior reorg that took 8 months to settle, making full reorg politically and practically costly
• 8-10 engineers can be reassigned without critically understaffing their current project teams
• existing stack synthetic default (not observed): greenfield assumed [synthetic] (not_addressed)

Inferred candidate specifics

These details were introduced by the Council during analysis. They were not supplied in your filing.

• Do NOT execute a full switch to platform/stream-aligned topology. Instead, perform a targeted partial restructuring affecting 8-10 engineers (17% of org), consolidating ownership of the top 3 service boundaries with the highest measured cross-team dependency rates. Step 1: Instrument dependency tracking via Jira/Linear ticket tagging for 4 weeks to produce a weighted dependency graph. Step 2: Identify top 3 service-pair boundaries (Pareto: likely 60-70% of all blockers). Step 3: Reassign 8-10 engineers to consolidate each boundary under single-team ownership. Step 4: Assign each shared library a single owning team using inner-source model enforced via GitHub/GitLab CODEOWNERS. Target: reduce cross-team dependency rate from 30% to below 20% within 4 months. Escalation trigger: if still above 25% after 4 months, proceed to full topology redesign. Key failure mode: Pareto assumption fails — if dependencies are evenly distributed rather than concentrated in 3 boundaries, targeted reorg is insufficient and full redesign becomes necessary sooner. This avoids the 40-60% deploy velocity drop during a 3-6 month full transition, avoids the 15-25% senior attrition risk of a second full reorg, and requires $0 new tooling.
• Create a Jira/Linear automation rule that adds a 'cross-team-blocked' tag to any ticket where the blocker is assigned to a different team, and deploy it across all 60 engineers' boards this sprint to begin the 4-week dependency instrumentation phase.
• b003 had the highest confidence (0.92), survived all 3 adversarial rounds with strengthening votes from multiple models, named specific headcounts, tooling, thresholds, and failure modes. b001 (0.70) offered a valid long-term vision but carried disproportionate execution risk for the stated constraints ($0 budget, 60 engineers, recent reorg memory). b003 was never seriously contested — it absorbed and subsumed the diagnostic value of b004 while providing concrete action.
• Full hybrid model: 3 platform teams + 6 feature teams organized by business capability (b001)
• At 60 engineers, dedicating 5-8 engineers per platform team (15-24 total) leaves insufficient headcount for 6 viable feature teams. The 4-quarter timeline and full reorg scope carries the velocity and attrition risks that b003 specifically avoids. b001's <15% dependency target is more ambitious but the execution risk is disproportionate to the improvement over b003's <20% target.
• Killed round 1. Zero specificity — no headcount, no thresholds, no tooling, no measurable success criteria. Adding platform responsibilities to existing teams increases cognitive load without changing ownership boundaries, which is the root cause of the 30% dependency rate.
• Killed round 3. Strictly dominated by b003, which already includes a 4-week instrumentation phase as step 1 AND acts on the results. The 30% dependency rate is already a strong enough signal to act — additional diagnosis without action is analysis paralysis.
• Switch to continuous deployment / trunk-based development instead of topology change (b005)

Unknowns blocking a firmer verdict

• The Pareto assumption (top 3 boundaries = 60-70% of blockers) is plausible but unvalidated for this specific org — the 4-week instrumentation phase will confirm or refute this
• The 40-60% velocity drop figure for full reorgs is attributed to 'industry benchmarks from Thoughtworks and DORA' but not linked to a specific publication — treat as directionally correct but imprecise
• Inner-source model effectiveness depends heavily on the owning team's review capacity; no threshold given for when this becomes a bottleneck
• b001's longer-term vision of platform teams may still be correct at a larger org size or if dependencies don't concentrate as expected — the escalation trigger at 25% after 4 months serves as the decision gate for this

Operational signals to watch

Branch battle map