Power is not persuasion—it’s the feedback mechanisms that bend outcomes over time.


Previous · Part 13
Critical Mass: The Tipping Point Where Growth Stops Needing You

Next · Part 15
When Input Becomes Noise: The Law of Diminishing Returns
This builds on Part 13: Critical Mass: The Tipping Point Where Growth Stops Needing You
Continue with Part 15: When Input Becomes Noise: The Law of Diminishing Returns
Coordination Problems: The Hidden Tax on Group Success
A weird thing happens when you put competent people into a group.
Even if every individual benefits from the group’s success, the group can still stall, fracture, or underperform. The culprit is rarely lack of goodwill. It’s coordination—especially when success requires many small, interdependent actions.
The core mismatch: shared benefits, private effort
Think about a group where everyone cares about the outcome. Great. That removes one enemy: indifference.
But it doesn’t remove the deeper challenge: each person only controls a slice of the path to the outcome. The group’s success is a function of how well their slices connect.
So you get a structure like this:
- Benefits are collectively realized
- Costs and effort are individually paid
- Progress is jointly required
That combination is where coordination problems breed.
Three coordination failure modes (and what they look like)
1) Unclear roles: “Someone should do this…”
Most groups don’t fail because tasks don’t exist. They fail because tasks aren’t owned.
Without clear ownership, everyone assumes someone else has the mental model already.
Symptoms:
- Endless discussion without decisions
- “We should” language instead of “I will” language
- Deadlines arrive like surprises
2) Misaligned timing: “I’ll wait until it’s safe”
Even when roles are clear, coordination can fail if timing is uncertain.
When the cost of acting early is higher than the cost of waiting, people drift into hesitation. They start waiting for:
- confirmation
- prior steps to complete
- reduced risk
Symptoms:
- Work begins in parallel… and stops at interfaces
- People ask for “one more check” indefinitely
- Momentum oscillates instead of building
3) Different models of “what success means”
Two people can both want success and still pull in opposite directions because they define success differently.
In groups, definitions are rarely argued loudly. They’re encoded in assumptions:
- quality standards
- acceptable tradeoffs
- what “good enough” means
- what to optimize for under constraints
Symptoms:
- Rework cycles
- “I thought we meant the other thing”
- Hidden criteria discovered only at review time
Why coordination is harder than it looks
Coordination is expensive because it requires information and synchronization.
Every time a group needs to coordinate, someone must answer questions like:
- Who decides?
- What counts as done?
- What depends on what?
- When do we reassess?
- What happens if plans fail?
If those answers aren’t embedded in the system (process, tooling, norms, incentives), they’ll be negotiated repeatedly. Negotiation doesn’t scale.
The structural trap: interdependence without a coordinator
A group can suffer even when all incentives line up—because interdependence creates bottlenecks.
If success depends on multiple links fitting together, then:
- each link must be ready
- interfaces must match
- handoffs must be timely
In practice, there’s usually an “unpaid coordinator” in the room—someone doing invisible glue work. If that person burns out, the whole system wobbles.
A practical coordination lens: “Interfaces first”
When you don’t know why a group is failing, stop asking “Why aren’t people working harder?” and start asking:
What are the interfaces where work must connect?
Interfaces are:
- handoffs between roles
- dependencies between tasks
- shared resources (time, data, attention)
- decision checkpoints
If coordination fails, the interface is usually where it breaks.
Diagram: Individual effort leads to Task completion; Task completion leads to Interface matching\nhandoff / dependency; Interface matching\nhandoff / dependency leads to Integration; Integration leads to Outcome; Shared benefits leads to Individual effort; Private costs leads to Individual effort; Unclear roles/timing/definitions leads to Interface matching\nhandoff / dependency.
Diagram: Individual effort leads to Task completion; Task completion leads to Interface matching\nhandoff / dependency; Interface matching\nhandoff / dependency leads to Integration; Integration leads to Outcome; Shared benefits leads to Individual effort; Private costs leads to Individual effort; Unclear roles/timing/definitions leads to Interface matching\nhandoff / dependency.
The fix: make coordination a property of the system
You don’t want people to “try harder.” You want the group to move through predictable coordination patterns.
That means making the coordination primitives explicit and lightweight.
Make ownership real (not ceremonial)
Ownership is not title. It’s a commitment:
- someone is responsible for advancing the interface
- someone is responsible for updating everyone else
- someone can say “this is blocked” without shame or delay
Create timing rails
Timing rails are lightweight sequencing rules:
- when work starts
- when input is requested
- when integration occurs
- what happens if inputs slip
If the group can’t answer “when should this be ready,” it will always default to waiting.
Align definitions before execution
Before people build, they need a shared definition of what “built” means.
That can be done with:
- acceptance criteria
- examples of “good” and “not good”
- tradeoff rules (what gets prioritized under constraint)
- a decision rubric
Tabs: How coordination breaks differently across groups
If your group feels stuck, focus on ownership and deadlines first. Most coordination failures are ambiguity + waiting.
A quick field test (use it on your next stalled project)
Final takeaway: Coordination isn’t chemistry. It’s engineering.
Groups fail even when everyone benefits from success because interdependence turns uncertainty into drift. The antidote is structure—ownership, timing rails, and aligned definitions—so that coordination happens as a property of the system, not a test of willpower.
If this resonates, see how to apply it to your own work with the interactive Dispatch agent.
Be first to like this dispatch



