# Do Not Remove Coordination Before Replacing It ## Summary Removing visible coordination can look like efficiency. Sometimes it is. Many organisations carry unnecessary meetings, approval loops, reporting rituals, and status layers. But some coordination is load-bearing. It keeps priorities comparable, decisions connected, exceptions visible, and people from working from incompatible assumptions. The danger is removing the visible role or ritual while leaving the coordination need behind. ## The Owlery rule Do not remove a coordination mechanism until you can name, design, and verify how its function will be performed differently. ## What counts as a coordination mechanism? A coordination mechanism can be: - a meeting - a role - a manager - an architect - a delivery lead - an approval step - a planning ritual - a dependency review - a dashboard - an escalation path - an AI agent or automation - an informal person who “just knows how things work” The mechanism may be clumsy. The function may still matter. ## Field signals You removed coordination too early when: - decision latency increases - people recreate side meetings - escalations become more emotional - work waits for “someone to connect the dots” - teams optimise locally and drift apart - more exceptions appear in chat - accountability becomes harder to inspect ## Design moves Before changing the mechanism: - map the function with [[Coordination Function Map (25 min)]] - check the hidden work with [[Invisible Middle Work]] - clarify ownership with [[Decision Context Pack (10 min)]] - use [[Dependency Handshake (10 min)]] for one high-friction interface - create a safe tripwire using [[Tripwire Template (5 min)]] ## See also - [[Team Cognitive Load and Coordination Burden Map]] - [[Management Decision Delay Creates Organisational WIP]] - [[Boundary Spanners Need Protection]] - [[AI Should Support Knowledge Travel Not Replace Context]] - [[Overload and Starting More Map]]