The CHEF Model: How Business Information Systems Hide What Matters
The Unintended Consequences of Embedding Best Practices
Organizations built systems to capture what they know. They ended up with systems that prevent them from knowing anything new.
That is not a dramatic claim. It is a description of what most organizational information environments have become — and why the problem is harder to see than it should be.
How It Happened
Nobody designed it this way. It accumulated.
A CRM to manage customer relationships. A financial system to track money. A project management tool. A communication platform. An HR system. A security stack. A data warehouse to connect them. An analytics layer on top of that. AI summaries on top of that.
Each decision made sense at the time. Each addition solved a real problem. The vendor made a compelling case. The competitor was already using it. The demo showed exactly the capability that was missing.
What nobody calculated was the cumulative effect. The complexity that compounds with every new integration. The dependencies that form between systems in ways nobody maps and most people don’t know exist. The total cost that nobody adds up honestly — not just the licenses, but the integration work, the training that repeats every time something changes, the consultants who arrive when the complexity exceeds what the internal team can handle, the workarounds built around systems that almost fit but don’t quite. The fragility that builds as the system gets optimized for normal conditions and loses any capacity to handle abnormal ones.
This is the CHEF model — Complex, Hidden Dependencies, Expensive, Fragile. Not a design philosophy. A diagnosis of what the ecosystem has become.
Nobody Knows How It Works
Leonard Read wrote an essay in 1958 called “I, Pencil” — narrated from the perspective of a pencil describing everything that goes into its own making. No single person on earth knows how to make a pencil from scratch. The knowledge is distributed across thousands of people and processes — logging, mining, refining, manufacturing, shipping — none of whom understand the whole.
The CHEF environment is the same problem applied to organizational information systems. The people who configured the CRM are gone. The consultant who built the integration retired. The vendor who wrote the original software has been acquired twice. The logic behind half the workflows exists only in the memory of people who may or may not still be at the organization.
You cannot redesign what you cannot understand. The CHEF environment, by distributing knowledge of itself across vendors, consultants, and departed employees, makes genuine reform nearly impossible from the inside. The pencil knows more about itself than the organization knows about its own systems.
The Map Is Not the Business
Iain McGilchrist describes a particular failure of the map-making mind — the tendency to mistake the representation of a thing for the thing itself. The map is precise, bounded, manageable. The territory is alive, changing, infinite. The pathology is when the map stops being a tool for navigating the territory and starts being a substitute for it.
CHEF environments do this systematically. The dashboard is not the business. The configured workflow is not the process. The best practice encoded in a system is a description of what worked somewhere, under conditions that no longer fully exist, frozen at the moment someone decided it was worth capturing.
This produces two specific traps.
The first is the End of History Bias. The CRM was configured for the business as it was. The dashboard was designed to measure what mattered then. The assumption baked into every configuration decision is that current conditions are roughly permanent. They aren’t. But nothing in the CHEF environment is designed to notice when they change.
The second is the Best Practices Are Forever Bias. What worked in one context, at one moment, for one organization gets codified as a universal principle. Best practices are always historical. The moment they get embedded in systems and certified against, they start drifting from the reality that produced them. The practice outlives the conditions that justified it. The system keeps measuring compliance with it anyway.
Both biases share the same root — the representation gets treated as more real than the reality it was meant to represent. The system’s model of the business displaces the business itself. David Deutsch calls knowledge growth the beginning of infinity — unbounded, never complete, always provisional. The CHEF environment is the organizational attempt to close that infinity down, to declare the important questions answered and the relevant variables captured. It works until reality produces something the system wasn’t designed to represent. Which it always eventually does.
What It Costs
The most visible cost is financial — the licenses nobody uses, the integrations nobody maintains, the consultants nobody planned for. Organizations that audit their actual SaaS utilization against what they’re paying for consistently find a significant proportion of features that nobody uses but everybody pays for. That number compounds annually.
The less visible cost is what the system does to organizational learning.
In the 1990s, practitioners working at the intersection of lean manufacturing and product development tried to build a Knowledge Turns metric — organizational knowledge health measured the way manufacturing measures inventory turns. Not how much information the organization has, but how efficiently it converts experience into understanding and action.
The idea faded because the measurement problem was genuinely hard. Inventory turns works because inventory is physical and its movement observable. Knowledge isn’t. You can count documents, training hours, patents. None of those are knowledge turning. They’re proxies that can look healthy while organizational understanding degrades.
The CHEF environment produces exactly that — reports full of numbers that tell you something is happening and nothing about why. The causal map, the connection between what the organization does and what results, gets distributed across systems until nobody can trace it. The system is good at producing information. It is poor at producing learning. And because the first is measurable and the second isn’t, the reporting always looks fine.
If You Were Starting Today
Here is a clarifying question worth asking about any established information environment: if you were building this from scratch today, would you build it this way?
Almost certainly not.
Nobody designing an organizational information system from scratch would say — let’s start with thirty years of accumulated vendor decisions, bundle economics, and integration debt, add a security layer on top, and call that our knowledge infrastructure. The CHEF environment isn’t an architecture. It’s a residue. And residue is hard to defend once you say it plainly.
The honest answer to the starting-from-scratch question also reveals what the system is actually optimized for — which is usually vendor retention, license revenue, and the path of least resistance at each decision point. The organization’s needs shaped the early decisions. The vendor’s needs shaped everything after.
The Only Question That Gets at the Root
You cannot fix a CHEF environment by adding more tools to manage the complexity, more integrations to bridge the hidden dependencies, more reporting to make the expense visible. That is the logic that built it.
The upstream question is the only one that matters: what does this organization actually need to understand, and what is the minimum system needed to support that understanding?
It is also the question that almost no technology evaluation process ever asks — because it requires honest assessment of what the organization can actually do, not what the vendor’s demo suggested was possible. And because asking it honestly usually reveals that a significant proportion of what the current environment produces is not connected to any genuine organizational question. Data captured because it can be. Reports generated because the tool generates them. Meetings scheduled because the calendar made it easy.
Organizations built systems to capture what they know. The systems got good at that. What they didn’t build — and what the systems actively work against — is the capacity to know something new.
That capacity doesn’t come from a better system. It comes from asking better questions of the systems you already have. Starting with: if we were building this today, what would we leave out?