What does it mean that process is an organizational schema?

Standard operating procedures, workflows, and routines are not just instructions — they are codified organizational schemas that embed assumptions about how work should flow, who should be involved, and what quality means. When processes are treated as fixed instructions rather than living schemas, they become organizational fossils: perfectly preserved structures from an environment that no longer exists.

Example: A DevOps team at a cloud infrastructure company had a deployment process that required a change advisory board (CAB) review for every production deployment. The CAB met weekly, reviewed proposed changes, and approved or rejected each one. The process had been designed eight years earlier when deployments were infrequent (once per month), high-risk (manual, with no rollback capability), and consequential (a single monolithic application serving all customers). The environment had changed completely. Deployments were now continuous (multiple per day), low-risk (automated, with instant rollback), and isolated (microservices affecting individual features). But the CAB process persisted. The engineer, Diana, calculated the cost: the weekly CAB meeting consumed forty person-hours (eight reviewers, five hours including preparation). Deployments queued for an average of 3.2 days waiting for CAB approval. The approval rate was 98.7% — nearly everything was approved, suggesting that the review added minimal value. The process was a schema — a codified mental model that said 'production changes are high-risk events requiring centralized approval.' The schema was accurate in 2018. It was false in 2026. But because the schema had been encoded into a process rather than held as an explicit assumption, it persisted unchallenged. When Diana surfaced the embedded schema — 'We assume that production changes are high-risk events requiring centralized approval' — the team could evaluate it against current reality and redesign the process accordingly. They replaced the weekly CAB with automated deployment guardrails: canary deployments, automated rollback triggers, and real-time monitoring. Deployment frequency increased 5x. Incident rate decreased. The embedded schema had been the constraint, not the technology.

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