Nov 12, 2024 · Leadership+Design · 5 min read
Language problems disguised as leadership problems
When teams use the same words but mean different things, what looks like an execution problem is actually a semantic one.
My first month at MOSTLY AI, every feature debate turned into the same argument.
Enterprise customers wanted granular control over synthetic data generation. Free users wanted "just give me data fast." Product kept saying we needed to "serve both users."
But product meant "build two separate flows." Engineering meant "smart defaults with optional overrides." Design meant "progressive disclosure of complexity."
Same goal. Three completely different products.
We spent two weeks arguing about feature priority before realizing we weren't disagreeing about solutions. We were solving different problems while using the same words.
THE REAL PROBLEM
Most teams don't fail because they lack talent
They fail because they don't share meaning.
Product teams are full of smart people using the same words while meaning different things. We say MVP, quality, scalable, iteration, alignment, ownership and assume agreement because the language sounds familiar.
Familiarity creates the illusion of shared understanding. That illusion is expensive.
What looks like an execution problem is often a semantic one. And most leadership problems in product organizations are, at their core, language problems.
WHERE IT STARTS
Leadership begins before structure
Leadership does not start with org charts, rituals, or process. It starts with who stabilizes meaning inside a system.
In many teams, progress slows not because decisions are hard, but because no one is fully certain what is being decided. Meetings feel busy yet unproductive. Conversations circle. Alignment feels temporary.
People leave meetings thinking they agreed, only to discover later they agreed on different things.
This is where leadership actually shows up. Not in having the final say, but in making sure everyone is having the same conversation.
When shared meaning is unstable, teams hesitate. When meaning is stable, teams can disagree productively and still move forward.
THE SYMPTOM
Execution is rarely the root problem
When teams miss deadlines or struggle to ship, the default reaction is to fix execution. Add more process. Add more documentation. Add more meetings.
But execution issues are usually symptoms.
The deeper issue is that people are optimizing for different outcomes while using the same language. Because the disagreement is implicit, it never gets resolved. It turns into friction, delays, defensive behavior, and quiet frustration.
The team doesn't feel misaligned. It feels slow.
THREE BREAKS
Where language actually breaks down
Language problems tend to show up in three predictable places.
Definitions
Words like quality, MVP, scalable, risk, done, or success are overloaded. They sound objective but hide different assumptions.
Decision Frames
People argue because they think they are making the same decision, when in reality they are making different ones. One person is deciding direction. Another is debating execution. A third is worried about long-term implications.
System Boundaries
Unspoken assumptions about what is in scope and what is not create anxiety. Teams argue because no one has explicitly said what the decision does not cover.
These breakdowns are rarely dramatic. They hide behind polite agreement and vague language.
IN THE WILD
What this looks like in practice
This problem shows up in small, almost invisible moments.
Quality
In one team, quality meant visual polish and interaction smoothness. For engineering, quality meant stability and test coverage. For product, it meant shipping without risk.
Everyone agreed quality was important. They disagreed on what failing looked like.
The result wasn't conflict. It was hesitation. Decisions stalled because no one wanted to be the person who compromised quality, even though each role was protecting something different.
The breakthrough didn't come from a new process or a leadership mandate. It came from a short conversation that aligned on one sentence: For this release, quality means predictable behavior over completeness.
That sentence didn't remove disagreement. It made decisions legible.
MVP
A team spent weeks debating scope while claiming alignment on shipping an MVP. But MVP meant different things.
To product, it was the smallest thing that validates demand. To design, the smallest experience that doesn't damage trust. To engineering, the smallest thing that won't create long-term debt.
Same acronym. Three mental models.
Once those models were made explicit, the disagreement stopped being emotional. It became a trade-off conversation instead of a values clash.
We'll Iterate
This one is subtle.
When teams say "we'll iterate," they often mean later, if we have time. Or in the next sprint. Or after launch. Or never, but it sounds responsible.
Iteration becomes a linguistic escape hatch. A way to postpone discomfort without admitting it.
Design leadership, in this case, is asking a single clarifying question: What specifically will change in the next iteration, and what signal will trigger it?
Silence usually answers the question.
THE FIX
A practical language alignment discipline
You don't fix this with workshops or glossaries alone. You fix it by inserting small, repeatable acts of clarification into everyday work.
Stabilize definitions before debating solutions
If a word is doing heavy lifting in a conversation, it deserves a shared definition. Especially when it appears in decision-making contexts. You don't need perfect definitions. You need explicit ones.
Name the decision frame explicitly
Many meetings feel political because people are solving different problems. Ask whether you are deciding direction or execution. Speed or correctness. Something reversible or irreversible. Changing the frame often resolves disagreement without compromise.
Draw system boundaries out loud
Design leaders often intuitively understand what is not being solved, but don't say it. Say it anyway.
This solution does not solve onboarding.
This decision does not optimize for edge cases.
This release does not scale globally.
Boundaries reduce anxiety. They give teams permission to move forward.
THE LIMITS
What language can't fix
Not everything is a language problem.
If a team lacks trust, authority, or resources, clearer language won't magically solve that. But without shared language, even well-resourced teams will feel slow, political, and brittle.
Language is not a replacement for structure. It is the foundation structure sits on.
THE RESPONSIBILITY
Why this is a design leadership responsibility
Design leaders are trained to notice mismatches between intent and interpretation. To work with abstract concepts before they become concrete. To translate between systems without flattening nuance.
This is not about facilitation. It is about meaning-making.
The most effective design leaders don't dominate decisions. They stabilize the language so decisions can happen. They don't just design interfaces. They design shared understanding.
CLOSING THOUGHT
Teams move slowly because they think they agree when they don't
Shared language doesn't eliminate tension. It changes tension from confusion into trade-offs.
And that shift is often the difference between a team that feels stuck and one that can actually move.
