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 defaulted: greenfield assumed (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.
• Set up Jira/Linear cross-team-blocked tagging automation and communicate tagging protocol to all team leads
• Run the dependency instrumentation for 4 weeks (2 sprints), producing a weighted dependency graph showing blocker frequency and duration per service-pair boundary
• After 4 weeks, validate Pareto assumption: confirm whether top 3 service-pair boundaries account for >50% of cross-team blockers. If not, reassess scope of micro-reorg
• Reassign 8-10 engineers to consolidate ownership of the top 3 identified service boundaries into single-team ownership
• Configure GitHub/GitLab CODEOWNERS files for all 4 shared libraries, assigning single owning teams with inner-source PR contribution model

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