Process is an organizational schema

The code the organization runs on

Software engineers understand that code is not just instructions — it is a model of how the programmer believes the system should work. The code embeds assumptions about inputs, outputs, error conditions, performance characteristics, and user behavior. When those assumptions change, the code must be updated or it becomes a bug: a correct solution to a problem that no longer exists.

Organizational processes are the code that organizations run on. A deployment checklist, a hiring workflow, an incident response procedure, a budget approval chain — each is a codified set of assumptions about how work should flow, who should be involved, what risks exist, and what quality means. And like software code, organizational processes become bugs when the assumptions they embed no longer match reality.

Brian Pentland's research on organizational routines at Michigan State University established that routines have two aspects: the "ostensive" aspect (the abstract pattern that members understand) and the "performative" aspect (the actual enactment of the routine in specific situations). The ostensive aspect is the schema — the mental model of how the work should flow. The performative aspect is the practice — how people actually do the work. Pentland found that these two aspects frequently diverge: the official process says one thing, and the actual practice does another. The divergence usually means that the practitioners have implicitly updated their schema while the official process has not (Pentland, 2003).

How processes encode schemas

Every step in a process encodes one or more assumptions. These assumptions can be categorized:

Risk assumptions. A process step that requires approval before proceeding encodes the assumption that the action is risky enough to warrant oversight. A process that requires sign-off from three levels of management before a purchase over $10,000 embeds the assumption that managers at each level add value to the purchase decision and that the cost of the approval overhead is less than the cost of the risk being mitigated. Whether these assumptions are true is an empirical question — but most organizations never ask it.

Capability assumptions. A process that assigns specific tasks to specific roles encodes assumptions about who is capable of what. A process that routes all customer escalations through a manager embeds the assumption that individual contributors cannot resolve escalations effectively. A code review process that requires senior engineer approval embeds the assumption that senior engineers catch errors that other reviewers miss. These capability assumptions may have been accurate when the process was designed but may not reflect the current team's skills and experience.

Sequencing assumptions. A process that requires steps to occur in a specific order encodes the assumption that the sequence matters. Design before development, testing before deployment, planning before execution — each sequential dependency embeds an assumption about what information or outputs are needed at each stage. Agile methodologies challenged many traditional sequencing assumptions, demonstrating that iteration (build-test-learn-repeat) can be more effective than sequential phases (design-build-test-deploy) in environments where requirements are uncertain.

Quality assumptions. A process that includes inspection, review, or testing steps encodes assumptions about where defects are introduced and how they are best caught. W. Edwards Deming challenged the inspection-based quality schema — the assumption that quality comes from catching defects after they are produced — and argued for a process-based quality schema: designing processes that prevent defects from occurring. The inspection schema and the prevention schema lead to fundamentally different processes, and the choice between them is a schema choice, not a process choice (Deming, 1986).

The lifecycle of process schemas

Process schemas follow a predictable lifecycle: birth, adaptation, fossilization, and — in healthy organizations — renewal.

Birth. A process is created in response to a specific need: a failure that must not recur, a new capability that must be operationalized, or a growth inflection that requires coordination that was previously unnecessary. The process is designed for the current context, and its embedded schemas reflect current reality. At birth, the process is well-adapted.

Adaptation. As the environment changes, practitioners informally adapt the process. They skip steps that add no value, add unofficial steps that address new needs, and develop workarounds for process elements that do not fit current reality. Martha Feldman's research on organizational routines found that this informal adaptation is constant and essential — practitioners are not deviating from the process but evolving it in response to changing circumstances. The process-as-practiced diverges from the process-as-documented, and the practiced version is usually more adapted to current reality (Feldman, 2000).

Fossilization. Over time, the gap between the documented process and the practiced process widens. New members learn the documented process but quickly discover that "nobody actually does it that way." The documented process becomes a ritual — followed when auditors are watching, ignored when they are not. The schemas embedded in the documented process are fossils: perfectly preserved models of a reality that no longer exists. Richard Nelson and Sidney Winter called these fossilized processes "organizational genes" — replicating faithfully regardless of whether they still serve the organism's fitness (Nelson & Winter, 1982).

Renewal. In healthy organizations, fossilized processes are periodically examined, and the embedded schemas are surfaced and re-evaluated. The renewal process mirrors the schema surfacing methods from Making organizational schemas explicit: extract the assumptions, test them against current reality, and redesign the process based on updated assumptions. In unhealthy organizations, fossilized processes accumulate indefinitely, creating layers of procedural sediment that consume increasing amounts of organizational energy while delivering decreasing amounts of organizational value.

Process debt

The concept of technical debt — the accumulated cost of shortcuts and deferred maintenance in software systems — has an organizational analogue: process debt. Process debt accumulates when organizations add processes without removing obsolete ones, when processes are adapted informally without updating the official documentation, and when processes designed for one context persist into a different context.

Process debt manifests as organizational drag: the feeling that "everything takes too long" and "there is too much overhead" without anyone being able to identify the specific source. The source is the accumulated weight of process schemas that no longer match reality — approval chains designed for a less trusted team, review cycles designed for a less capable toolchain, documentation requirements designed for a less mature product.

Like technical debt, process debt is not always visible in the moment. Each individual process step seems reasonable. The burden becomes apparent only in aggregate — when the total time consumed by process overhead significantly exceeds the time spent on the work the processes are supposed to enable. And like technical debt, process debt compounds: each new process adds to the overhead, and the overhead makes it harder to invest time in reviewing and retiring obsolete processes, which increases the debt further.

The remedy for process debt is the same as for technical debt: periodic review and deliberate retirement. Organizations need a regular practice of examining their processes, surfacing the embedded schemas, evaluating those schemas against current reality, and retiring or redesigning processes whose schemas are no longer valid. This is not process optimization — making existing processes more efficient. It is process re-evaluation — asking whether the process should exist at all given the assumptions it embeds and the current context it operates in.

The Third Brain

Your AI system can serve as a process archaeologist — analyzing existing processes to surface the schemas they embed. Describe a process to the AI step by step and ask: "What assumptions does each step encode about risk, capability, sequencing, and quality? Which of these assumptions might have been true when the process was designed but are no longer true?" The AI's analysis can reveal embedded schemas that practitioners have become so habituated to that they no longer recognize as assumptions.

The AI can also help redesign processes from schema-first principles. Instead of starting with the existing process and modifying it incrementally, start with the schemas you want to encode: "We assume that our engineers can deploy safely with automated guardrails. We assume that code review adds value for complex changes but not for trivial ones. We assume that quality is best ensured through monitoring and rapid rollback rather than pre-deployment inspection. Design a deployment process that embeds these schemas." The resulting process will be fundamentally different from an incremental modification of the existing process — because it starts from different assumptions.

For ongoing process health, use the AI to perform periodic process audits: "Here is our current [process name]. Here is how our environment has changed in the last year: [description]. Which embedded assumptions in this process are most likely to be outdated? What would the process look like if it were designed from scratch for today's environment?" This audit reveals the process debt that accumulates silently and creates the case for process renewal before the debt becomes crippling.

From process to values

Process schemas encode the organization's model of how work should flow. But beneath the process lies a deeper layer of organizational schema: values. Values schemas encode what the organization believes matters — what it considers good, right, and important. Values determine which processes get created, which get enforced, and which get ignored.

The next lesson, Values are organizational schemas, examines how values function as organizational schemas — and why the gap between stated values and operating values is one of the most consequential schema misalignments an organization can experience.

---

Sources:

1. Pentland, B. T. (2003). "Sequential Variety in Work Processes." Organization Science, 14(5), 528-540.
2. Deming, W. E. (1986). Out of the Crisis. MIT Press.
3. Feldman, M. S. (2000). "Organizational Routines as a Source of Continuous Change." Organization Science, 11(6), 611-629.
4. Nelson, R. R., & Winter, S. G. (1982). An Evolutionary Theory of Economic Change. Harvard University Press.