What does it mean that schema conflicts within organizations?

Different departments, functions, and levels within an organization often hold conflicting schemas — different mental models of what matters, how work should flow, and what success looks like. These conflicts are not personality clashes or communication problems. They are structural: each group's schemas were formed by different experiences, incentives, and professional training. Surfacing and reconciling these schema conflicts prevents the coordination failures that masquerade as interpersonal friction.

Example: An e-commerce company had a persistent conflict between its engineering and marketing teams. Engineering complained that marketing made unrealistic promises to customers and demanded features without understanding technical constraints. Marketing complained that engineering was slow, unresponsive, and disconnected from customer needs. Leadership tried team-building exercises, joint planning sessions, and even seating the teams together. Nothing helped. The CTO, Simone, ran a schema surfacing exercise across both teams. She asked each team to independently answer: 'What is the purpose of our product?' Engineering's consensus: 'To provide a reliable, scalable platform for online commerce.' Marketing's consensus: 'To help merchants grow their business online.' She then asked: 'What makes a good feature?' Engineering: 'Clean architecture, low technical debt, high performance.' Marketing: 'High customer adoption, measurable revenue impact, competitive differentiation.' The schemas were not wrong — they were different. Each team's schema was well-adapted to its function. But the schemas conflicted at every point of interaction. Engineering's quality schema deprioritized speed. Marketing's impact schema deprioritized technical quality. Neither team's schema was invalid. But neither team recognized that the other team was operating from a different — and equally legitimate — mental model. Once the schema conflict was surfaced, Simone could address it structurally: shared definitions of 'done,' joint prioritization using both technical quality and business impact criteria, and a translation layer (a product manager) who understood both schemas and could mediate between them.

Try this: 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?'