Home › Systems › Concepts
Boundaries
Systems / Concepts · Added Apr 2026
Every system is defined by where you draw its edge. Move the edge, and the system changes.
What It Means
A boundary decides what's inside a system and what's outside — what you optimise for, what you ignore, what counts as a side effect. Boundaries aren't found in nature; they're drawn by the observer. A team, a codebase, a market, a body — each exists only because someone chose where to stop.
Why It Matters
- The boundary determines which feedback loops you see. A bug is "ours" or "theirs" depending on where you cut.
- Optimising inside a tight boundary often creates problems just outside it — cost savings in one team become costs in another.
- Problems that look unsolvable usually need a boundary redrawn, not a harder push inside the current one.
The Ways to Get It Wrong
- Too strict. Silos form. Teams optimise their own metrics while the whole degrades. Bugs live on the seams no one owns.
- Too loose. Nothing is anyone's responsibility. Scope sprawls, focus dissolves, decisions take forever.
- Wrong place. The boundary cuts through a tight feedback loop — e.g. splitting design and engineering mid-product — and communication cost explodes.
- Permanent. A boundary that made sense at 10 people is wrong at 100. Boundaries need to move as the system grows.
How to Apply
- When a problem keeps recurring, ask whether the boundary is in the right place, not whether people are trying hard enough.
- Draw boundaries around tight feedback loops, not across them.
- Revisit boundaries when scale, scope, or strategy changes. Last year's right line is this year's bottleneck.
- Make boundaries explicit. Implicit ones become battlegrounds.
Related