You've been in this meeting. Every leader has.
A strategic opportunity lands. A crisis hits. A major decision is due. The leadership team convenes. Ideas are pitched. Proposals are made. Smart people, good intentions, genuine energy.
Forty-seven ideas go up on the whiteboard. And then the meeting stalls — not because the ideas are bad, but because there's no shared framework for evaluating them. No common vocabulary for describing what the organization can deliver. No structured way to compare this opportunity against that one, or to assess which capabilities exist and which would need to be built.
The loudest voice wins. Or the most politically connected. Or the one with the best slide deck. Not the best idea. The best-presented one.
This isn't a failure of intelligence. It's a failure of infrastructure. The organization lacks the shared vocabulary that would allow those forty-seven ideas to be compared, connected, and converted into coordinated action.
The product of building that vocabulary isn't a plan. It isn't a document. It's something more valuable: an organization that knows how to think.
Where Are You Starting From?
Before deciding what to do, it helps to be honest about where you stand. Organizations exist at different levels of maturity when it comes to shared vocabulary, and the right next step depends on the starting point.
No shared models at all. Each department, each project, each initiative builds its own language from scratch. Cross-functional conversations begin with "What do we mean by...?" and sometimes never get past that question. This is the forty-seven-ideas meeting. Smart people, good intentions, no shared framework for organizing their thinking.
Informal shared vocabulary. Some terms are used widely — "capability," "service," "value stream" — but different groups define them differently. There may be structured models in specific pockets (a financial reporting framework, a program classification), but they're not connected to each other or to strategic decisions.
Formal models in some domains. The organization has a capability model for IT, or a process framework for operations, or a data model maintained by an analytics team. But these models exist in silos. They don't connect to each other, and they're not used in cross-functional governance.
Integrated reference architecture. Multiple models connect across domains and are used in governance. Strategic choices are traceable to capability investments, which are traceable to operational outcomes. This is rare. Organizations that reach this level have built the infrastructure for collective thinking.
Most organizations — most — are at the first or second level. This is normal. The goal isn't to leap to the top in a single bound. It's to move one level up and let that step prove its value before taking the next one.
Which Tool Fits the Problem?
If you're introducing a shared vocabulary for the first time, the question isn't "which tool is best?" It's "which tool fits the problem the organization is feeling right now?"
If the problem is strategic direction, start with the business model. Nine boxes on a whiteboard that show how the organization creates, delivers, and captures value. It's the lightest-weight entry point: fits on a single page, uses language executives understand, and can produce genuine insight in a single workshop. When the problem is "our business model is broken" or "we don't know how this opportunity fits our strategy," the business model is the fastest path to clarity.
If the problem is execution gaps, start with a capability map. When the organization's strategy says one thing and its operations say another — when different divisions perform at different levels of maturity, or when strategic commitments are made with no identified capabilities behind them — the capability map shows the structural reality. It requires more effort than the business model, but it produces more precise diagnostics.
If the problem is fragmented experience, start with a recipe card. When the people you serve experience chaos — not because anything is broken, but because nothing is connected — the recipe card shows which capabilities should be combining to produce a coherent outcome and where the integration is missing.
If you don't know what the problem is yet, start with the business model. It's the broadest view and the best diagnostic starting point when the problem hasn't been clearly defined.
One critical consideration: the first tool you introduce will set the tone for everything that follows. If the first experience is positive — the conversation improves, insight surfaces, a real decision is informed — the organization will be receptive to more. If the first experience feels academic, irrelevant, or disconnected from any decision that matters, resistance will build. Choose the first tool with care. It's not just a diagnostic. It's a proof of concept for an entire approach.
Lead with Pain, Not Methodology
This is the section that determines whether anything actually happens.
Walk into a leadership meeting and say "We should adopt reference models because they are a best practice in business architecture," and you will get polite nods and no action.
Walk into the same meeting and say "Last month, we spent three weeks trying to agree on which capabilities we needed for the new program. We had this exact same conversation for the previous program. Each time we started from scratch because we have no shared vocabulary for describing what this institution does. A capability map would give us that vocabulary and cut three weeks of rework from every initiative." Now you have attention.
The difference is framing. The first version presents methodology. The second presents pain.
Effective framing follows a simple structure.
Name the specific pain. Not "we lack alignment" — that's too abstract. Instead: "The merger integration team spent six weeks reconciling different definitions of the same capabilities across the two organizations before any substantive integration work could begin." Concrete. Measurable. Felt by people in the room.
Connect the pain to the solution. Explain how a specific type of shared vocabulary addresses this specific problem. "If we had mapped both organizations' capabilities against the same reference in the first week, six weeks of reconciliation would have been reduced to one week of structured comparison."
Propose a bounded first step. Not "let's adopt reference models across the organization." Instead: "I'd like to use a reference capability map in our next program review. It will take one additional hour. If it helps, we continue. If it doesn't, we stop."
The bounded first step is what makes the difference between a pitch that gets rejected and one that gets tried. Nobody is being asked to commit to a multi-year program. They're being asked to try one thing, once, and judge the result.
Design the Proof, Not the Program
A first initiative should be designed as a proof of value: small enough to be low-risk, specific enough to produce a visible result, and connected enough to a real decision that the result matters to someone with authority.
Five parameters define a good proof of value.
Scope: One domain, one value chain, or one strategic question. Not the entire organization. Pick the domain where the pain is most acute and the stakeholders most receptive.
Stakeholders: Six to twelve people who represent the domain's key perspectives. Plus the senior leader who will judge whether the initiative was worth continuing.
Deliverable: The specific artifact that will demonstrate value. Not "a model" but "a capability heat map for our core value chain showing the top three gaps against our strategy." Something that can be used in a governance conversation.
Timeline: Four to eight weeks. Longer than that, the organization loses interest before the result arrives. Shorter, the result may be too shallow to be convincing.
Success criteria: Defined in advance. Not "we produced a model" — that's output. Instead: "The model surfaced gaps that the leadership team had not previously identified, and the team committed to addressing the highest-priority gap." Success is demonstrated when the shared vocabulary produces insight that changes a decision.
If the proof works, the path forward opens naturally. The sponsor has seen value. The participants have experienced the difference. The organization has a partial vocabulary that's already useful. Expand the scope, formalize the governance, move from consultation to adoption.
If it doesn't work, the answer isn't to push harder. It's to diagnose why: wrong scope, wrong tool, wrong stakeholders, wrong timing. Adjust and try again, or wait until conditions change.
The Vocabulary Is the Infrastructure
Every organization manages its finances. Every organization has an org chart. Every organization has a strategic plan. These are foundational — infrastructure that everyone uses, not specialist tools maintained by one team.
The shared vocabulary for what the organization does, what it's capable of, and how value flows should be treated the same way. Not as a methodology project. Not as an architecture initiative. As infrastructure.
Infrastructure that everyone uses to have better conversations. Infrastructure that makes forty-seven ideas comparable instead of incommensurable. Infrastructure that turns governance from opinion-based debate into evidence-based assessment. Infrastructure that lets the organization respond to opportunities in weeks instead of months.
The organizations that build this infrastructure don't do it because it's a best practice. They do it because they've experienced the cost of not having it. They've watched the same definitional debates consume the first weeks of every initiative. They've seen the same capability gaps identified and re-identified across successive projects without ever being systematically addressed. They've lived through the meeting where everyone leaves thinking they agreed and then discovers they each meant something different.
Those organizations decide, eventually, that maintaining the shared language is worth the modest, persistent investment it requires. And they discover that the investment pays off not in the big strategic moments — though it does — but in every conversation, every meeting, every decision where the room can start from shared understanding instead of starting from scratch.
The vocabulary isn't the strategy. But without it, every strategy conversation is harder, slower, and more prone to misalignment than it needs to be.
This post is drawn from Building the Common Language, a self-paced course that shows how to diagnose your organization's starting point, select the right shared vocabulary tool, and build the case through pain rather than methodology — because the organizations that know how to think are the ones that invested in the language for thinking together.