Ghosts in the System: Why Naming Dysfunction Isn’t Fluff. It’s Infrastructure

A recent comment on one of my posts made me pause. It said something like:

“Naming a problem can feel like solving it - but often just hides the real issue.”

I started replying. Then I stopped.

Because the question underneath was real: Does naming a dysfunction actually help? Or is it just a distraction from the work?

I turned it into this instead.

You Know the Symptoms

If you’ve worked in product long enough - especially in complex orgs - you've seen it:

• A backlog that moves, but feels hollow
• A roadmap that’s packed, but drifts from strategy
• A sprint that delivers… but no one remembers why the work was prioritized

You might call it “feature soup.” Another team says “alignment issues.” Someone else calls it “strategy disconnect.”

👉 Same dysfunction. Different names.

And that’s not a coincidence. It’s the cost of not having shared language.

If We Can’t Name It, We Can’t See It

Here’s the key insight:

If a dysfunction has no name, it remains invisible. And what’s invisible becomes unfixable.

This isn’t semantics. It’s system design.

Language is the first form of structure. It gives a problem edges. Turns intuition into something traceable - a known issue, not just a feeling.

Why This Matters (And It’s Not Just Theory)

This shows up everywhere:

• Affect labeling → Naming emotions reduces their intensity. In teams: Naming frustration prevents escalation.
• Organizational sense-making → Shared language helps teams “make sense” of complexity. Without it: Teams treat symptoms, not systems.
• Problem framing → The way a problem is defined shapes how it gets solved.
• Linguistic relativity → Language shapes perception. Without terms like “strategy drift,” people feel misalignment but struggle to act on it.

Naming ≠ Solving. But It Starts the System Thinking.

Let’s be precise:

Naming a dysfunction won’t fix it. But it makes it visible, diagnosable, and discussable.

That’s the unlock.

What Naming Unlocks

1. Structured Dialogue Teams move from vague reactions to structured reasoning: “We’re unclear on priorities.” → “This smells like prioritization theater again.”

2. Cross-Role Alignment PMs, engineers, designers, leadership — same label, shared lens. Now you’re not debating if something’s broken. You’re discussing why.

3. Cognitive Traceability Named dysfunctions leave footprints: In retros, in planning, in roadmap reviews. You can track patterns, observe recurrence, and spot improvement.

From Observation to System Insight

We’ve seen the same dysfunction show up under different names:

• “Hollow PBIs”
• “Empty tickets”
• “Jira shells”

Different teams. Different terms. Same structural failure.

And when dysfunction hides behind different names, teams don’t recognize it. They normalize it.

Shared Language Changes the Game

Without Shared Language → With Shared Language

• Vague complaints in retros → Clear recognition of repeatable patterns
• Personalized blame → Systemic framing of failure
• Superficial fixes → Structural diagnosis
• Context loss in turnover → Durable organizational memory
• Rituals without purpose → Framed, intentional decisions

Final Takeaway

Shared vocabulary isn’t a luxury. It’s reasoning infrastructure.

Naming dysfunction doesn’t solve it - but creates visibility, alignment, and traceability.

Without language, your team is just reacting. With it, you can start designing.

So if your team feels stuck, don’t jump straight to solutions. Start here:

🟡 Name what’s happening

🟡 Make the invisible visible

🟡 And then get to work - together