I was part of the problem.

The authentication feature had been haunting our team for a week. Every standup, someone mentioned it. Every planning discussion circled back to it. The phrases accumulated like sediment: “edge cases,” “token refresh flows,” “session management across services.” I nodded along. I contributed concerns. I mentioned that one OAuth2 implementation that had burned me three years ago.

Then someone shared a FigJam link. A flow diagram. A sequence diagram. A working proof of concept built in three days.

The room went quiet.

The feature wasn’t complex. It had never been complex. What I’d spent a week worrying about took three days to build. And the diagram didn’t reveal a simpler solution. It revealed that the complexity had never existed in the system at all.

It had existed in us.

Phantom Complexity

There’s a pattern I keep seeing in software teams. It’s not about bad communication or missing skills. It’s about what happens when smart people discuss a system without drawing it.

Each person in the conversation holds a mental model. That model contains the feature, yes, but also ghosts: past systems that were hard, edge cases from previous jobs, assumptions inherited from half-remembered architecture decisions. When I said “authentication,” I wasn’t describing a feature. I was summoning every authentication system that had ever burned me.

The problem is that these ghosts are invisible. The conversation proceeds as if everyone is discussing the same system, but they’re not. One person imagines OAuth2 flows with refresh token rotation. Another pictures a simple JWT check. A third worries about session invalidation across microservices because that’s what bit them two years ago.

Without a diagram, these mental models never collide. They coexist in the room, each person nodding at different phantoms.

The complexity isn’t in the system. It’s in the gap between mental models.

And that gap generates phantom requirements, phantom edge cases, phantom difficulty. A haunted house that exists only in the conversation.

The Exposure Nobody Wants

A diagram forces the ghosts into the open.

If diagrams are this effective, why aren’t they the first thing that happens?

Because drawing is exposure.

A conversation lets you stay vague. You can express concern about “edge cases” without specifying which ones. You can nod at “complexity” without committing to a position. You can contribute to the discussion without revealing whether you actually understand the system.

I know this because I did it for a week.

Every time I mentioned “token refresh flows,” I was performing expertise I didn’t have. The OAuth2 system that burned me? Different architecture entirely. Irrelevant to what we were building. But raising the concern made me sound thoughtful. It made me sound senior.

A diagram ends that performance. The moment you put boxes and arrows on a screen, you’ve committed to a model. That model can be wrong. It can be questioned. It can reveal that the thing you’ve been confidently discussing was based on assumptions you never examined.

This is uncomfortable. So teams default to talking.

There’s also a subtler dynamic, one I’m not proud to name: complexity is a form of protection. If a feature seems hard, it justifies more time, more resources, more meetings. A three-day proof of concept is, in a certain light, an indictment. It suggests that the week of discussion was unnecessary. That the planning was theater. That the people who sounded most concerned understood the least.

We don’t discuss to understand. We discuss to delay understanding.

Nobody says this out loud. But it’s why the room went quiet.

The Move-On Reflex

And then something predictable happened: everyone moved on. Next agenda item. No pause. No one asked the obvious question.

Why did we spend a week afraid of something that took three days to build?

The team had just watched assumed complexity evaporate. A diagram and a POC had done in three days what conversation had failed to do in seven. This should have been a reckoning. Someone might have asked: “What if we started with a diagram next time?” or “Why did we assume this would be hard?”

Instead: next topic.

This is how organizations stay stuck. Not through malice or stupidity, but through the move-on reflex. The moment of clarity happens, and then it’s gone. No one captures it. No one institutionalizes the lesson. The next feature will generate its own phantom complexity, and the same pattern will repeat.

I’ve watched this happen a dozen times since. The moment where the truth becomes visible, followed immediately by the collective decision not to look at it.

The discomfort of examining the pattern is greater than the cost of repeating it.

What We’re Actually Avoiding

The phantom complexity isn’t really about features. It’s about something we don’t want to confront.

Drawing a diagram means committing to a position. That position can be wrong. And being wrong in public, visibly wrong, wrong in a way that gets screenshotted and referenced in future meetings, feels dangerous in ways that being vague never does.

But here’s what I’ve learned: the teams that build fastest aren’t smarter. They’re braver. They’re willing to be wrong early, when it’s cheap, rather than vague forever, when it’s expensive.

The engineer who shared that FigJam link didn’t have more experience than the rest of us. They had less fear. They drew what they thought was true and let the room correct it. Three days later, we had working code.

I spent a week protecting myself from being wrong. That protection cost more than being wrong ever would have.

Vagueness feels like safety. It’s actually debt.

Every week spent discussing instead of drawing is a week where wrong assumptions compound. The phantom complexity grows. The ghosts multiply. And when someone finally does the work, the gap between imagined difficulty and actual difficulty becomes an accusation that nobody wants to hear.

Six months later, that engineer was leading our architecture discussions. Not because they were smarter. Because while the rest of us were performing thoughtfulness, they were shipping. The gap between talking about complexity and resolving it had become the gap between their trajectory and mine.

The Structural Fix

Saying “draw more diagrams” changes nothing. It becomes advice, then aspiration, then forgotten.

What works is structural enforcement. A simple rule: no alignment meeting starts without a diagram.

Not a polished architectural artifact. Not documentation. A rough visual of what the proposer thinks they’re discussing. Boxes, arrows, labels. Ugly is fine. The point isn’t aesthetics. The point is forcing the mental model into a form that can be compared, questioned, and corrected.

Some teams make it a gate: whoever calls a meeting about system design must share a diagram 24 hours before. Others dedicate the first ten minutes to each participant sketching their understanding before discussion begins.

The initial reaction is always friction. Engineers complain it’s overhead. Product managers say they don’t know how to draw technical diagrams. Everyone has reasons why this meeting, specifically, doesn’t need one.

Then something shifts. Meetings get shorter. Disagreements surface in the first five minutes instead of the last five. Features that seemed complex reveal themselves as straightforward before anyone writes code. The phantom complexity never accumulates because the diagram exorcises it early.

The ghosts can’t survive the light.

The Question That Stays

That meeting still bothers me.

Not because we wasted a week. Time gets wasted. That’s normal. What bothers me is how easily I participated in the performance. How natural it felt to raise concerns I hadn’t examined, to nod at complexity I didn’t understand, to contribute to a conversation that was moving us away from the truth rather than toward it.

The diagram didn’t make anyone smarter. It didn’t improve our communication skills. It did something more basic: it forced the collision of mental models before implementation, when discovering we were picturing different systems was still cheap.

But forcing that collision requires something most teams avoid: the willingness to be specific, to commit, to be wrong in public rather than vague in private.

The complexity was never in the system. It was in us. And a diagram doesn’t simplify the problem. It reveals there was no problem to simplify.

The next meeting you sit through, watching concerns accumulate without resolution, ask yourself: are you discussing the system, or protecting yourself from having to be specific about it?

The diagram won’t just reveal what the system is. It will reveal who was ready to build and who was still hiding.

Most of us already know. We just don’t want to see it on a diagram.

—Viz