{
  "assumption_density": 0.1111111111111111,
  "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"
  ],
  "confidence": 0.82,
  "id": "1038dbdf-9d22-486e-ac55-56a3ff4ac7c7",
  "next_action": "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.",
  "question": "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.",
  "question_fit_score": 0,
  "rejected_alternatives": [
    {
      "path": "Full hybrid model: 3 platform teams + 6 feature teams organized by business capability (b001)",
      "rationale": "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 \u003c15% dependency target is more ambitious but the execution risk is disproportionate to the improvement over b003's \u003c20% target."
    },
    {
      "path": "Embed partial platform responsibilities in existing project teams (b002)",
      "rationale": "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."
    },
    {
      "path": "2-week diagnostic before any action (b004)",
      "rationale": "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."
    },
    {
      "path": "Switch to continuous deployment / trunk-based development instead of topology change (b005)",
      "rationale": "Killed round 2. Misframes the problem — development practices don't solve cross-team ownership boundary issues. Dependencies persist regardless of deployment cadence."
    }
  ],
  "reversal_conditions": [
    {
      "condition": "Dependency instrumentation reveals dependencies are evenly distributed across \u003e8 service boundaries with no clear Pareto concentration",
      "flips_to": "Full topology redesign to platform/stream-aligned model (similar to b001) because targeted micro-reorg cannot address diffuse dependency patterns"
    },
    {
      "condition": "Organization grows to 100+ engineers or secures tooling budget for Backstage/internal developer platform",
      "flips_to": "Dedicated platform teams (3-4 teams of 5-8 engineers each) become viable without starving stream-aligned teams of headcount"
    },
    {
      "condition": "Cross-team dependency rate remains above 25% after the 4-month micro-reorg, triggering the escalation threshold",
      "flips_to": "Full topology redesign with explicit transition plan accepting the 3-6 month velocity dip"
    }
  ],
  "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"
  ],
  "url": "https://vectorcourt.com/v/1038dbdf-9d22-486e-ac55-56a3ff4ac7c7",
  "verdict": "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.\n\nStep 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.\n\nTarget: 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.\n\nKey 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.\n\nThis 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.",
  "verdict_core": {
    "recommendation": "Execute a targeted micro-reorg affecting 8-10 engineers to consolidate ownership of the top 3 highest-dependency service boundaries, NOT a full topology switch to platform/stream-aligned teams.",
    "mechanism": "Because at 60 engineers with $0 tooling budget, a full reorg requires 5-8 engineers dedicated to platform alone, leaving insufficient headcount for viable stream-aligned teams across 12 services, while a targeted consolidation of the 3 service boundaries responsible for ~60-70% of cross-team blockers (Pareto distribution) directly eliminates the structural cause of dependencies without the 40-60% velocity drop and 15-25% senior attrition risk of a full reorg.",
    "tradeoffs": [
      "Does not address the remaining ~10-15% of cross-team dependencies outside the top 3 boundaries",
      "Leaves the broader project-based team structure intact, which may need revisiting if dependency rate doesn't drop below 20%",
      "Inner-source model for shared libraries creates merge bottleneck on owning teams"
    ],
    "failure_modes": [
      "Pareto assumption fails: dependencies are evenly distributed across many boundaries rather than concentrated in 3, making targeted reorg insufficient",
      "Reassigned engineers lose domain context from their original teams, creating new dependency vectors",
      "Inner-source CODEOWNERS enforcement creates PR review bottleneck if owning team lacks capacity",
      "Measurement artifact: Jira/Linear tagging undercounts dependencies if teams work around blockers informally"
    ],
    "thresholds": [
      "8-10 engineers reassigned (17% of org)",
      "Reduce cross-team dependency rate from 30% to \u003c20% within 4 months (8 sprints)",
      "Escalation trigger: if still above 25% after 4 months, proceed to full topology redesign",
      "Top 3 boundaries expected to account for 60-70% of all cross-team blockers",
      "40-60% deploy velocity drop avoided vs. full reorg",
      "15-25% voluntary senior attrition risk avoided vs. full reorg"
    ]
  },
  "verdict_type": ""
}