A CTO proposes reorganizing every team around microservices boundaries company-wide within one quarter to 'fix' Conway's Law problems. As a principal engineer, what would make you push back on the timing or scope of that plan?

## Why a principal pushes back There are several independent reasons to push back on a fast, company-wide, one-shot reorganization, and a principal engineer should be able to articulate them as concrete costs and risks, not just gut discomfort with change. ## The four objections 1. **The first is disruption concentration.** Any team reorganization has a real, measurable cost: people lose daily proximity to former teammates, tacit knowledge that lived in informal relationships (who knows the weird edge case in this billing code, who to ask about that flaky test) gets scattered or lost outright, and new teams need weeks to months to rebuild the trust and shared context that let them move fast. Doing this to every team simultaneously means the entire company's delivery velocity dips at the same time, which is exactly the wrong moment to also be executing a technically risky microservices migration that needs stable, high-context teams to get right. A staged rollout — reorganizing one or two domains first — contains that velocity dip to a smaller blast radius and lets the organization learn from the first attempt before repeating it elsewhere. 2. **The second is boundary uncertainty.** The inverse Conway maneuver assumes you know the target architecture well enough to organize teams around it durably. For a mature, slow-changing domain (say, a well-understood billing ledger), that assumption often holds. For a young or fast-evolving domain — a new product line still finding its shape, or a domain where the business itself is actively deciding how to segment its offering — the 'correct' service boundary is genuinely unknown and likely to be wrong in six to twelve months as the product evolves. Locking a team's boundary to a guessed architecture in a volatile domain means paying the reorg cost, discovering the guess was wrong, and then paying it again to fix it — worse than not reorganizing that domain yet and accepting some Conway's-Law-driven messiness there until the domain stabilizes enough to commit to boundaries. 3. **The third is uneven pain distribution** — not every service or team actually has a Conway's Law problem worth solving right now. A rarely-changed, single-team-owned internal service that works fine has no coupling debt to pay down; reorganizing around it anyway is pure cost with no corresponding benefit. A principal engineer should push the CTO to identify where the actual pain is concretely measurable — services with contested on-call history, unusually slow deploy cadence relative to change volume, or repeated 'whose bug is this' incidents — and prioritize the reorg where evidence, not architectural idealism, shows the current org structure is actively causing damage. 4. **The fourth is capacity and change-management realism:** a quarter is an aggressive timeline for a full reorg plus the actual technical migration work it's meant to enable, and squeezing both into the same window risks doing neither well — teams spend the quarter in reorg limbo (new manager, new codebase, unclear ownership) rather than either stabilizing under the old structure or productively executing the new one. Sequencing — reorg first, let teams stabilize for a defined period, then execute the heaviest migration work — tends to produce better outcomes than parallelizing both under time pressure, even though it's slower calendar-wise. ## The other side of the trade-off The trade-off a principal has to weigh explicitly, though, is that staged reorgs also have a cost: - prolonged periods where some domains are reorganized and others aren't create inconsistency (two different operating models coexisting, cross-team friction between 'new model' and 'old model' teams); - and moving too cautiously can let a genuinely painful coupling problem fester for another year while waiting for 'enough evidence.' The right answer isn't 'never reorganize broadly' — it's **sequencing by measured pain and boundary confidence**, with an explicit plan for extending the model once the pilot area validates it, rather than either extreme (reorganize everything at once on a guess, or never commit to any organizational change and let Conway's Law's problems compound indefinitely). ## How to operationalize the pushback A concrete way to operationalize the pushback: ask the CTO to name the two or three services with the worst current symptoms, using data — - incident MTTR - deploy frequency versus commit volume - on-call page volume - contested ownership incidents — and propose the inverse Conway maneuver there first, with a defined checkpoint (e.g., one or two quarters) to evaluate before deciding whether and how to extend it company-wide. This reframes the conversation from 'reorg everyone now because Conway's Law says so' to 'apply the lever surgically where the data shows it's needed, learn from it, then scale the successful pattern' — which is both lower-risk and more likely to produce organizational buy-in, since teams see a working proof point rather than a company-wide mandate justified by theory alone.