How do I apply the idea that process is an organizational schema?

The most direct way to practice is through a focused exercise: Choose one process your team follows routinely. Write down the process steps, then extract the assumptions embedded in each step. For each step, ask: 'What does this step assume about the risk, the people, the technology, or the environment?' For example, a code review process might embed these assumptions: 'We assume that reviewers will catch bugs' (is that what reviews actually catch?), 'We assume that two reviewers are better than one' (is there evidence for this?), 'We assume that review should happen before merge' (could post-merge review work better in some cases?). For each assumption, assess: Is this assumption still true? Was it ever tested, or was it inherited from a previous context? If the assumption is outdated, what would the process look like without it?

Common pitfall: Two symmetric failures. The first is treating processes as sacred — refusing to modify a process because 'it has always been done this way' or because the process was designed by someone with authority. This treats the process as a fixed instruction rather than a living schema, ensuring that the process becomes increasingly misaligned with the environment it is supposed to serve. The second failure is treating processes as disposable — constantly changing processes without understanding the schemas they embed. A process that seems bureaucratic may encode a hard-won lesson about a risk that is no longer visible precisely because the process mitigates it. Removing the process without understanding the embedded schema can reintroduce the risk. The discipline is to surface the schema first, evaluate the schema against current reality, and then modify the process based on the schema evaluation.

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