The Fight for Meaning

Why the hardest work is invisible, and why skipping it always costs more

Friday's meeting, at the point of deciding first actionable steps, my collaborator said it plainly:

“I don’t believe modelling is a necessary first step. It’s slow. It’s difficult. It will just change anyway.”

It was said warmly, but the message was clear: meaning work; the work of agreeing on what things mean and how they fit together, is seen as optional. In the rush to deliver, it feels like a luxury.

This isn’t an isolated view. It’s one of the most consistent patterns in any organisation trying to modernise: the instinct to start building before agreeing on meaning. To favour now and fast over slow and steady.

I’ve seen this tension play out in meeting rooms, project kick-offs, and budget debates across sectors. And the reasons for skipping the work are remarkably consistent.

The Common Excuses for Skipping Meaning Work

1. “It will change anyway.” Why model something that’ll be out of date in six months? The reality: change is precisely why you model. Without a model, changes break things invisibly. With a model, you can see the ripple effects before you commit. Updating a living model is cheaper than untangling a codebase full of hidden assumptions.

2. “We have a business glossary, that’s enough.” The glossary says what “Customer” means, so we’re covered. The reality: a glossary is vocabulary; a model is grammar. You can know the words and still fail to form a coherent sentence. A glossary tells you who owns the term, not how it relates to anything else.

3. “The data domains already have models.” We’ve got diagrams for every domain, why redraw them? The reality: most domain models are static noun lists. Without a semantic layer, “Customer” in Domain A isn’t guaranteed to match “Customer” in Domain B, even if they’re spelled the same.

4. “We’ll figure it out in the build.” The developers will sort it out as they go. The reality: without a model, “adjusting” means rewriting integrations, rebuilding pipelines, and reconciling broken reports. The sooner the rules are visible, the less they cost to enforce.

5. “We’ll fix it later.” Let’s just get the MVP out first. The reality: later never comes. By then, “fixing” means unpicking technical debt and political agreements at the same time.

6. “It’s too slow / we don’t have time.” We can’t spend weeks in workshops. The reality: a tightly scoped model sprint can take hours, not months. The “delay” is a myth born from bad process, not the work itself.

7. “The business won’t understand it.” They’ll see boxes and lines and check out. The reality: models don’t need to be arcane diagrams. They can be clear, conversational maps. Avoiding them because of “complexity” often hides the fact that the current system is complex — it’s just invisible.

8. “We’ve always done it this way.” We just start building, it’s worked for years. The reality: that only works until the complexity threshold is crossed. Agile without shared meaning just means you’re sprinting in different directions.

9. “Our vendor’s tool already enforces the model.” The CRM/ERP has its own structure, we don’t need another. The reality: vendor models are built for their product, not your whole ecosystem. Without a conceptual model, you inherit their constraints, even when they don’t fit.

10. “We’ll learn faster by doing.” Real understanding comes from building. The reality: yes, but without a model, each team learns in isolation; and rediscovers the same truths. Modelling captures shared learning once so no one pays the same tuition twice.

Why meaning work feels like a delay, and why it isn’t

Upfront modelling is visible time. Rework is invisible until it explodes. It’s easy to measure the days spent agreeing on meaning; it’s much harder to measure the months lost to reconciling mismatched systems later.

People overestimate the time modelling takes, and underestimate the cost of inconsistency. The paradox is simple: the fastest teams are the ones that slow down at the start.

The real fight

The fight for meaning isn’t about defending “modelling” as a discipline. It’s about protecting adaptability.

Without agreed meaning, every change is a structural gamble. Every integration is a hand-crafted translation. Every metric is a debate.

With agreed meaning, change is deliberate. Integration is plug-and-play. Metrics are boringly consistent.

Closing conviction

Skipping the fight for meaning is like skipping the foundation in a building project. You can save a week now and lose the whole structure later.

The real race isn’t to launch fastest, it’s to adapt fastest. That race is won by the teams that start with meaning.