Every year, thousands of organizations launch transformation programs. New strategy. New operating model. New capability roadmap. And the first thing every project team does is the same: they sit in a room and start building a vocabulary from scratch.
What do we mean by "capability"? How should we structure our business model? What are the building blocks of our value chain? How do we organize what we do into something a leadership team can discuss, debate, and decide on?
These are not new questions. They are the same questions that every similar organization has answered — often more than once. The team down the hall answered them last year. The organization across town answered them three years ago. Entire communities of practice have spent decades identifying the recurring patterns that define how organizations in your sector work.
And yet. Your team starts from a blank page. Again.
This isn't a failure of research. It's a structural gap. Most organizations don't know that maps already exist. Or they know, but they dismiss them as "not built for us." Or they start building their own because it feels more rigorous, more tailored, more authentic.
Meanwhile, the blank page consumes weeks. Definitions are debated. Structures are proposed, revised, and revised again. And by the time the team has a working vocabulary, half the energy allocated for actual strategic work has been spent on scaffolding that someone else already built.
The Difference Between a Model and a Map
There's a distinction that changes how you think about organizational design, and most people miss it.
A model describes a specific instance. Your org chart describes your organization. Your process flow describes your process. Your capability list describes your capabilities. The model is useful, but it's tied to your context. Nobody at another organization can use it as a starting point without significant rework.
A reference model does something different. It identifies what's common across many organizations like yours. It generalizes — filtering out what's unique to any single organization and preserving the structures that recur across the community.
Think of the difference between a personal sketch of your neighborhood and a published city map. Your sketch captures your route to work, the shortcut through the park, the coffee shop you like. It's accurate for you. Nobody else can use it.
The city map was built by studying the entire territory. It captures streets, landmarks, and boundaries that everyone shares. It doesn't know about your shortcut. But it gives anyone in the city a common starting point for navigating.
A reference model is the city map for your sector. It doesn't describe your organization specifically. It describes what organizations like yours typically look like, what capabilities they typically need, how value typically flows. It's a starting point — not a destination.
Why Starting from a Blank Page Is So Expensive
The blank-page approach feels thorough. It seems like building from the ground up would produce something more tailored, more accurate, more useful. In practice, it produces three predictable problems.
You rediscover what's already known. Entire communities of practice have spent years identifying the recurring capabilities, processes, and structures that define your sector. When your team builds from scratch, they're rediscovering patterns that were documented decades ago. The work is real. The learning is genuine. But it's redundant — and it delays the work that actually matters.
You embed blind spots. When you build your vocabulary internally, you can only see what you already know. The reference model might list a capability that your organization has never formalized — not because it's irrelevant, but because nobody inside ever named it. The outside perspective is the point. It reveals patterns you might not see from the inside.
You create something nobody else can use. An internally built vocabulary is specific to your organization. When you need to benchmark against peers, integrate after a merger, onboard new leaders, or coordinate across divisions, your private vocabulary becomes a barrier. Everyone else has to learn your language before they can contribute.
The reference model avoids all three. It captures what the community already knows. It surfaces patterns you might have missed. And it provides a shared vocabulary that anyone in the domain can use — meaning that the new executive, the external partner, and the consulting team all start from the same place.
Generalization: The Operation That Makes It Work
The intellectual operation behind reference models is worth understanding, because it explains both their power and their limitations.
Generalization takes many specific instances and identifies recurring patterns across them. Where a model says "here is how our organization works," a reference model says "here is how organizations like ours typically work."
This isn't averaging. It's pattern recognition at scale. A community of practitioners studies how dozens or hundreds of organizations in their domain operate. They identify the capabilities, structures, and relationships that recur. They filter out what's unique to individual organizations and preserve what's common. The result is a structured starting point that any organization in the domain can adopt and adapt.
The power of generalization is reuse. You don't start from zero. You start from the accumulated experience of a community that has navigated similar territory.
The limitation of generalization is the loss of specificity. A reference model will never describe your organization exactly. It captures what's common, not what's unique. The work of adapting the reference model to your context is still yours to do. But that adaptation work is fundamentally different from building from scratch. You're customizing a map rather than drawing the territory from memory.
Here's the subtlety that matters most: when your organization's reality differs from the reference model, there are two possible explanations. Either you're genuinely unique in that area and the pattern doesn't apply. Or the reference model has identified a pattern that you haven't recognized or adopted yet.
Both explanations are valid. But the impulse to say "that doesn't apply to us" should always be tested against the question: "Or does it apply and we just haven't done it yet?" The reference model's outside perspective is often more valuable where it challenges than where it confirms.
Five Ways to Manage Complexity (Without Notation)
Reference models aren't just lists of things an organization does. They're structured — organized using strategies that make complexity manageable without requiring anyone to learn formal modeling languages.
Five strategies show up in every well-designed reference model:
Abstraction filters out irrelevant detail. Instead of listing hundreds of specific financial activities, the model names "Financial Management" as a capability. The detail still exists in the real world. The model lifts the conversation to a level where strategic discussion is possible.
Generalization identifies recurring patterns across organizations. This is what makes a reference model reusable — it captures what's common, not what's unique.
Views present different perspectives for different audiences. A board member needs the strategic view. A program manager needs the operational view. A front-line team needs the integration view. A well-designed reference model supports multiple views of the same underlying architecture, without requiring multiple models.
Layering separates related but different domains. Business capabilities are one layer. The data those capabilities need is another. The applications that manage the data are a third. The technology that runs the applications is a fourth. Each layer has its own concerns, but they connect. Understanding the layers helps you recognize when a business question requires a data or technology answer.
Partitioning divides a large domain into manageable pieces. Instead of trying to reason about everything at once, you focus on one area — say, your learning and teaching capabilities — while understanding how it fits into the whole. Partitioning also enables distributed ownership: different parts of the organization can take responsibility for different sections of the model.
You don't need to master these strategies. You need to recognize them when you encounter them, because they explain why a well-designed reference model feels navigable while a poorly designed one feels overwhelming.
The Community Behind the Map
Here's something that separates a genuine reference model from a consultant's template or a vendor's framework: the community.
A reference model that's published once and never updated is a historical artifact. It captures what someone thought was true at a specific moment. Within a few years, it's out of date.
A reference model that's maintained by an active community — practitioners who use it, contribute to it, debate its structure, and evolve it based on real experience — is infrastructure. It improves over time. It incorporates lessons learned from organizations that have adopted and adapted it. It reflects current reality, not the reality of the year it was first published.
The best reference models in the world are not the ones with the most elegant structure. They're the ones backed by communities that meet regularly, govern the model as a living product, version it carefully, and treat updates with the same rigor they'd apply to any critical organizational asset.
When you're evaluating whether a reference model is worth adopting, the question isn't just "Is the content good?" It's "Is there a community behind it that will keep it good?"
Start from the Map. Make It Yours.
A reference model is not a prescription. It doesn't say "you must organize your business this way." It says "organizations like yours typically need these capabilities. Here is a structured way to think about them. Now adapt it to fit your context."
The adaptation is where your organization's uniqueness lives. The reference model provides the starting vocabulary. You add the specificity — the particular ways your organization delivers value, the capabilities that are central to your strategy, the integration patterns that make your operating model distinctive.
But you start from the map, not the blank page. And that starting point saves weeks of definitional work, eliminates the blind spots that come from building internally, and gives you a shared vocabulary that connects your conversations to a broader community of practice.
The next time your team sits down to define capabilities, or structure a business model, or design an operating framework, ask one question first: has someone already drawn this map?
If they have, use it. Adapt it. Make it yours. The organizations that start from existing maps move faster, see further, and align more easily than those that insist on drawing every line from scratch.
This post is drawn from Building the Common Language, a self-paced course that shows how reference models give organizations a structured starting point — and why the best vocabulary is one you adapt, not one you invent.