Skip to content
How to ThinkIn the Age of AI

Schema design as leadership work

~6 min read

Core Primitive

One of the most important jobs of leadership is designing and updating organizational schemas — the shared mental models through which the organization perceives, interprets, and acts.

Leaders who focus only on decisions and actions are managing the organization's output. Leaders who design schemas are managing the organization's cognitive infrastructure — the system that produces decisions and actions at every level, in every situation, whether the leader is present or not.

Leadership as cognitive architecture

The conventional view of leadership focuses on decisions and actions: leaders make strategic choices, allocate resources, set priorities, and solve problems. This view is not wrong, but it is incomplete. It describes leadership as making decisions for the organization. The schema design view describes leadership as shaping how the organization makes decisions — designing the shared mental models that determine how every member perceives, interprets, and acts in every situation.

Edgar Schein argued that the most consequential thing leaders do is create and manage culture — and that culture, at its deepest level, consists of the basic assumptions (schemas) that members share. "The unique and essential function of leadership," Schein wrote, "is the manipulation of culture." By "manipulation" Schein did not mean deception. He meant deliberate design: the intentional creation, revision, and reinforcement of the shared mental models that determine how the organization thinks and behaves (Schein, 2010).

This view of leadership is more leveraged than the conventional view. A leader who makes a decision resolves one situation. A leader who designs a schema shapes how the organization resolves all similar situations — including situations the leader never encounters, decisions made in meetings the leader never attends, and tradeoffs resolved by people the leader has never met. Schema design is leadership that scales because it operates on the organization's cognitive infrastructure rather than on its individual decisions.

What schema design looks like in practice

Schema design is not an abstract exercise. It manifests in specific, observable leadership behaviors.

Naming the schema. Leaders who design schemas give names to the mental models they want the organization to adopt. Reed Hastings at Netflix named the "context, not control" schema: leaders provide context (information, strategy, objectives) rather than control (approvals, directives, oversight). The name makes the schema memorable, discussable, and enforceable. When someone asks "Should I get approval for this?" the schema has a name that provides the answer: "We provide context, not control — you have the context, so you decide." Naming converts an implicit assumption into an explicit, shared mental model (Hastings & Meyer, 2020).

Modeling the schema. Leaders propagate schemas most powerfully through their own behavior. When a leader admits uncertainty ("I do not know — let us find out"), they model a schema that says "uncertainty is acceptable." When a leader celebrates a failed experiment ("This did not work, but we learned something important"), they model a schema that says "failure is data." When a leader overrides a team's decision without explanation, they model a schema that says "authority trumps evidence." Leadership behavior is the most powerful schema propagation channel because it is the most observed — members watch what leaders do far more carefully than they read what leaders write.

Encoding the schema in systems. Leaders who design schemas embed them in organizational systems — incentives, metrics, processes, and tools — that reinforce the schema continuously. A schema of "customer obsession" encoded in a system means: customer satisfaction is a primary metric in every department's scorecard, customer feedback is reviewed in every product meeting, and customer-facing roles are among the highest-status positions in the organization. Without system encoding, the schema exists only as a message, and messages decay while systems persist.

Protecting the schema under pressure. The schema's credibility is established not when following it is easy but when following it is costly. When the organization faces a quarter-end revenue shortfall and the schema says "do not discount below our minimum," the leader's choice to hold the price (at the cost of missing the quarter's target) establishes the schema as real. When the leader discounts to hit the number, the schema is revealed as aspirational rather than operative. Roy Vagelos's decision to give away Merck's river blindness drug Mectizan to all who needed it — at significant cost to shareholders — established Merck's "patients first" schema as operative, not just stated (Vagelos & Galambos, 2004).

The schema design cycle

Schema design is not a one-time exercise. It follows a cycle that mirrors the broader schema management practices of this phase.

Diagnose. Using the schema audit (The schema audit for organizations) and surfacing methods (Making organizational schemas explicit), identify the current operating schemas and assess their fitness for the organization's current and anticipated environment. Which schemas are current and adaptive? Which are outdated and costly?

Design. For schemas that need updating, design the replacement schema. The design should be specific enough to guide behavior, simple enough to remember, and distinctive enough to change the default. "Move fast and break things" is a well-designed schema (specific, memorable, distinctive) regardless of whether it is the right schema for a particular organization.

Communicate. Introduce the new schema through naming, storytelling, and example. Explain not just what the new schema is but why the old schema no longer serves the organization. The reasoning matters because it helps members understand the schema rather than merely comply with it — and understanding enables adaptation while compliance enables only rote following.

Encode. Embed the new schema in organizational systems: metrics, incentives, processes, hiring criteria, promotion criteria, meeting structures. The encoding ensures that the schema is reinforced through daily experience, not just through periodic messaging.

Model. Demonstrate the schema through leadership behavior, especially in high-stakes and high-visibility situations. Every leadership decision is a schema-reinforcing or schema-undermining event. Consistency between stated schemas and leadership behavior builds credibility. Inconsistency destroys it.

Monitor. Track schema propagation and adoption through the hallway test, decision audits, and the schema audit. Adjust the communication, encoding, and modeling based on what the monitoring reveals.

The Third Brain

Your AI system can serve as a schema design advisor. Describe the schema you want to design or update — the current schema, the desired schema, and the organizational context — and ask: "How should this new schema be communicated, encoded in systems, and reinforced through leadership behavior? What are the most common failure modes in this type of schema change, and how can they be avoided?"

The AI can also help you anticipate resistance to schema changes: "This schema change shifts from [old schema] to [new schema]. Who in the organization benefits from the old schema? How will they experience the change? What specific concerns will they raise, and how should those concerns be addressed?" Understanding the resistance landscape enables proactive design rather than reactive firefighting.

For ongoing schema design practice, use the AI to periodically review your leadership decisions through a schema lens: "Here are the ten most significant decisions I made this month. For each, what schema did the decision reinforce or undermine? Were the reinforcement patterns consistent, or did some decisions reinforce one schema while undermining another?" The analysis reveals whether your leadership behavior is propagating the schemas you intend or inadvertently propagating conflicting ones.

From design to health

Schema design is leadership work — the deliberate creation and maintenance of the shared mental models that shape organizational behavior. When this work is done well, the organization's schemas are current, aligned, well-propagated, and consistently reinforced. The result is an organization where behavior is coherent, adaptive, and aligned with the organization's purpose.

The next and final lesson of this phase, Healthy organizational schemas produce healthy organizational behavior, closes Organizational Schemas with the integrative insight: healthy organizational schemas produce healthy organizational behavior — and the quality of the organization's schemas is the single strongest lever leaders have for shaping the organization's outcomes.


Sources:

  1. Schein, E. H. (2010). Organizational Culture and Leadership (4th ed.). Jossey-Bass.
  2. Hastings, R., & Meyer, E. (2020). No Rules Rules: Netflix and the Culture of Reinvention. Penguin Press.
  3. Vagelos, P. R., & Galambos, L. (2004). Medicine, Science and Merck. Cambridge University Press.

Put it into practice

Exercise

List three decisions you have made as a leader in the past month. For each decision, ask: Was this decision about what to do in a specific situation, or was it about how the team should think about a category of situations? Decisions about what to do are operational decisions — they solve the immediate problem but do not change the system that produces problems. Decisions about how to think are schema decisions — they change the mental model that the team uses to approach all similar situations. For each operational decision you identified, ask: What schema decision could I make that would prevent the need for this operational decision in the future? What shared mental model, if established, would enable the team to make this decision correctly without my involvement?

More on putting it into practice

See it in action

Satya Nadella's transformation of Microsoft is a case study in schema design as leadership work. When Nadella became CEO in 2014, Microsoft's operating schemas were well-established: 'We are a Windows company' (identity schema), 'We win by controlling the platform' (strategy schema), 'Internal competition drives performance' (values schema), 'We know better than our customers' (customer schema). Nadella did not begin by changing Microsoft's products, org chart, or strategy document. He began by changing its schemas. He replaced 'We are a Windows company' with 'We are a cloud and AI company.' He replaced 'We win by controlling the platform' with 'We win by empowering others.' He replaced 'Internal competition drives performance' with 'Growth mindset drives performance.' He replaced 'We know better than our customers' with 'We learn from our customers.' Each of these was a schema change — a revision of the shared mental model through which Microsoft's 120,000 employees interpreted situations and made decisions. The schema changes preceded and enabled the operational changes: Azure's rise, Office 365's transformation, LinkedIn's acquisition, GitHub's acquisition. The operational changes would have been impossible under the old schemas — an organization that identified as a Windows company would not invest aggressively in cloud infrastructure that competed with its own platform. Nadella's leadership was schema design: he identified the outdated schemas, designed their replacements, and invested years in propagating the new schemas through the organization's systems, incentives, and culture.

Watch for the failure mode

Designing schemas through announcement rather than through reinforcement. A leader who announces 'We now value speed over perfection' has not changed the schema — they have stated an intention. The schema changes only when the organizational systems reinforce the announcement: when speed is rewarded in performance reviews, when fast-but-imperfect releases are celebrated rather than criticized, when the leader personally models speed-over-perfection in their own decisions. Schema design is 10% announcement and 90% reinforcement. The failure mode is treating the announcement as the work rather than as the beginning of the work.

Make it stick

Return to The schema audit for organizations, which introduced the schema audit. The audit diagnoses the current state of the organization's schema landscape. This lesson addresses the question that follows diagnosis: who is responsible for designing, updating, and maintaining the schemas? The answer is leadership. Schema design is not a project or an initiative — it is an ongoing leadership responsibility, as continuous as financial management or talent management. The connection to culture is the sum of organizational schemas is direct: if culture emerges from schemas, and schemas can be designed, then culture can be designed — not through culture programs but through deliberate schema design. Look forward to Healthy organizational schemas produce healthy organizational behavior, which closes Organizational Schemas with the integrative insight: healthy organizational schemas produce healthy organizational behavior.

Practice

Map Operational Decisions to Schema Changes in Notion

Analyze three recent leadership decisions to identify whether they were operational (solving immediate problems) or schema-level (changing how the team thinks). For each operational decision, design the schema change that would prevent needing to make that decision repeatedly.

15 minutesAdvanced
  1. 1Create a new Notion database called 'Schema Design Analysis' with columns for Decision, Date, Type (operational/schema), Impact Scope, and Schema Alternative. Add three rows for your most recent leadership decisions.
  2. 2For each decision row in Notion, write a detailed description of the situation and what you decided. Then use the Type dropdown to classify it: was this about what to do in one specific situation (operational) or about how the team should think about a category of situations (schema)?
  3. 3For any decision marked as operational in Notion, create a linked sub-page titled 'Schema Alternative' and write the mental model or principle that, if established, would have enabled the team to make this decision without you. Be specific about what shared understanding would need to exist.
  4. 4In each Schema Alternative sub-page in Notion, add a section called 'Implementation Plan' where you document how you would actually establish this schema: what team discussion, documentation, or training would embed this mental model into how the team operates.
  5. 5Create a Notion toggle list at the top of your database titled 'Schema Leadership Patterns' where you synthesize the common themes across your three schema alternatives. Identify 2-3 recurring types of situations where you're making operational decisions that could be solved by better organizational schemas.

Common questions about this lesson

More around this idea