What does it mean that organizational schemas are often implicit?

The most powerful organizational schemas are the ones nobody talks about — the assumptions so deeply embedded in how the organization operates that they feel like facts rather than choices. These implicit schemas determine behavior more reliably than any explicit policy, precisely because they operate below the level of conscious examination.

Example: A mid-size fintech company hired a new VP of Engineering to accelerate product development. The VP, Kenji, came from a fast-shipping consumer tech company and immediately noticed that every feature took three to four times longer than he expected. He examined the engineering process: code reviews, testing, deployment pipelines — all were efficient. The bottleneck was not technical. It was an implicit schema. Every feature required sign-off from the compliance team before development began, then again before QA, then again before deployment. When Kenji asked why, engineers said 'That is how we do things.' When he asked the compliance team, they said 'Engineering sends us everything for review.' When he asked the CEO, she said 'We are a regulated company — compliance review is essential.' But when Kenji examined the actual regulatory requirements, he found that fewer than 20% of features touched regulated functionality. The implicit schema — 'everything must be reviewed by compliance' — had expanded far beyond the regulatory reality. It had formed during the company's early days when the product was entirely financial transactions. As the product expanded into non-regulated features (notifications, dashboards, user preferences), the schema expanded with it — not because anyone decided it should, but because nobody questioned it. The schema was invisible because it felt like a fact about the business rather than a choice about process. Kenji's explicit questioning surfaced the implicit schema, and the team was able to create a triage system: compliance review for regulated features, streamlined process for everything else. Development velocity doubled within a quarter — not by changing technology or adding engineers, but by making an implicit schema explicit and then revising it.

Try this: Identify one implicit schema in your organization by looking for a behavior that 'everyone just does' without being able to articulate why. Common examples: Who gets invited to which meetings? What information is shared broadly versus held tightly? Which types of initiatives get funded without rigorous justification, and which require extensive business cases? Pick one pattern and interview three people at different levels about it. Ask each: 'Why do we do it this way?' If the answers are vague ('It is just how things work'), inconsistent ('I assumed it was a policy' versus 'I think the CEO prefers it'), or circular ('Because that is what everyone does'), you have found an implicit schema. Write it down as an explicit assumption: 'We assume that X.' The act of writing makes the implicit explicit — and once explicit, it can be examined.