How do I apply the idea that schema conflicts within organizations?

The most direct way to practice is through a focused exercise: Identify one recurring cross-functional conflict in your organization. Ask each side to independently answer three questions: (1) 'What is the goal of our work together?' (2) 'What does quality look like?' (3) 'How should priorities be set?' Compare the answers. The divergences are schema conflicts — structural differences in mental models, not interpersonal disagreements. For each divergence, ask: Is there a way to honor both schemas? What shared schema could replace the conflicting ones? Document the conflict and the proposed resolution. Share it with both teams and ask: 'Does this accurately describe the disagreement? Would this resolution address the underlying issue?'

Common pitfall: Treating schema conflicts as one side being right and the other wrong. When engineering and marketing disagree, the typical organizational response is to decide which team's perspective is correct and force the other to conform. But schema conflicts between functions usually reflect different but legitimate perspectives: each function's schema is adapted to its specific context. The engineering quality schema is legitimate in the context of system reliability. The marketing speed schema is legitimate in the context of market competition. The failure is not that one schema is wrong but that both schemas cannot be applied simultaneously without conflict. The resolution is not to pick a winner but to create a shared schema that integrates both perspectives — a 'trade-off framework' that both teams can use to navigate the tension.

This practice connects to Phase 82 (Organizational Schemas) — building it as a repeatable habit compounds over time.