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.
Execute a targeted micro-reorg affecting 8-10 engineers to consolidate ownership of the top 3 highest-dependency...
Decision
82%
Execution
—
Uncertainty
—
This verdict was re-examined after censor review.
Decision
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.
Next actions
Set up Jira/Linear cross-team-blocked tagging automation and communicate tagging protocol to all team leads
infra · immediate
Run the dependency instrumentation for 4 weeks (2 sprints), producing a weighted dependency graph showing blocker frequency and duration per service-pair boundary
backend · immediate
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
product · before_launch
Reassign 8-10 engineers to consolidate ownership of the top 3 identified service boundaries into single-team ownership
backend · before_launch
Configure GitHub/GitLab CODEOWNERS files for all 4 shared libraries, assigning single owning teams with inner-source PR contribution model
infra · before_launch
Track cross-team dependency rate monthly post-reorg; if still above 25% after 4 months (8 sprints), escalate to full topology redesign planning
product · ongoing
This verdict stops being true when
Dependency instrumentation reveals dependencies are evenly distributed across >8 service boundaries with no clear Pareto concentration → Full topology redesign to platform/stream-aligned model (similar to b001) because targeted micro-reorg cannot address diffuse dependency patterns
Organization grows to 100+ engineers or secures tooling budget for Backstage/internal developer platform → Dedicated platform teams (3-4 teams of 5-8 engineers each) become viable without starving stream-aligned teams of headcount
Cross-team dependency rate remains above 25% after the 4-month micro-reorg, triggering the escalation threshold → Full topology redesign with explicit transition plan accepting the 3-6 month velocity dip
Full council reasoning, attack grid, and flip conditions included with Pro
Council notes
Socrates
RECOMMENDATION: First diagnose whether the 30% cross-team dependency rate is actually causing business impact before ...
Vulcan
Pilot a pseudo-stream-aligned approach by embedding partial responsibilities for reducing cross-team dependencies wit...
Daedalus
RECOMMENDATION: Do NOT execute a full switch to platform/stream-aligned topology. Instead, perform a targeted partial...
Loki
Swap the key constraint from 2-week sprints (batch-oriented) to continuous deployment with trunk-based development: D...
Assumptions
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
Operational signals to watch
reversal — Dependency instrumentation reveals dependencies are evenly distributed across >8 service boundaries with no clear Pareto concentration
reversal — Organization grows to 100+ engineers or secures tooling budget for Backstage/internal developer platform
reversal — Cross-team dependency rate remains above 25% after the 4-month micro-reorg, triggering the escalation threshold
Unresolved uncertainty
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
Branch battle map
Battle timeline (3 rounds)
Round 1 — Initial positions · 3 branches
Branch b002 (Vulcan) eliminated — Branch b002 is architecturally vacuous. 'Pilot a pseudo-s...
Socrates proposed branch b004
SocratesRECOMMENDATION: First diagnose whether the 30% cross-team dependency rate is act…
Round 2 — Adversarial probes · 3 branches
Loki proposed branch b005
Branch b005 (Loki) eliminated — This branch fundamentally misframes the problem by sugges...
LokiSwap the key constraint from 2-week sprints (batch-oriented) to continuous deplo…
Round 3 — Final convergence · 2 branches
Branch b004 (Socrates) eliminated — b004 recommends a 2-week diagnostic before any action. Th...