Before changing a team schema, map what it supports — decisions, coordination, and what would break
Before attempting to change a shared team schema, map what the current schema supports—which decisions it enables, what coordination it simplifies, and what would break if it disappeared—to understand its load-bearing function.
Why This Is a Rule
This is Chesterton's Fence (Chesterton's Fence: understand why it was built before you tear it down) applied to shared team schemas. A team's current way of thinking — "we prioritize features over bug fixes," "we use story points for estimation," "we make decisions by consensus" — looks like an arbitrary convention from the outside. But it was built to solve problems, and it currently supports decisions and coordination that depend on it.
Mapping the load-bearing function before changing reveals three things: Decisions enabled (what can the team decide quickly because this schema provides a shared framework?), Coordination simplified (what coordination patterns rely on this schema as common ground?), and Breakage on removal (what would go wrong if this schema disappeared overnight?).
If the schema supports important decisions and coordination, the replacement must handle those same functions. A new estimation framework that replaces story points must also enable the sprint planning, capacity allocation, and stakeholder communication that story points currently support — or those functions will break.
When This Fires
- Before proposing any change to how a team thinks about recurring processes
- When the current schema seems "obviously wrong" (probably load-bearing in ways you don't see)
- During organizational change when shared frameworks are being replaced
- Any time a team's "way of doing things" is being questioned
Common Failure Mode
Replacing a schema without understanding its function: "Story points are meaningless, let's stop using them." But story points currently enable sprint planning (how much fits?), stakeholder communication (when will it be done?), and team capacity discussion (are we overloaded?). Removing them without replacing these functions creates a coordination vacuum.
The Protocol
Before changing a shared schema: (1) Map decisions enabled: "What decisions does the team make using this schema as the framework?" (2) Map coordination simplified: "What coordination is easier because everyone shares this schema?" (3) Map breakage: "What would go wrong within one week if this schema disappeared?" (4) Any replacement must handle all three functions. If the replacement can't → the current schema is more load-bearing than it appeared, and the change needs more design work before implementation.