Technical Trust Weekly

August 28th

The Whiteboard Flood

↓
​
​You nailed discovery. Then you drew everything and lost them.

You asked the right questions. You listened for what they actually meant, not what you assumed. You understood their terminology, their constraints, their exact problem.

You’re confident. More confident than usual. This one feels different.

You sit down at the whiteboard.

And you draw everything.

You sketch the architecture. You show how data flows from their systems into yours. You explain the transformation layer, the API contracts, the webhook patterns. You draw boxes and arrows. You add labels. You go deeper. You show the fallback mechanisms, the error handling, the retry logic.

You’re being thorough. You’re demonstrating mastery. You’re showing them you understand the complexity.

Then you look up.

They’re staring at the board like you just explained quantum physics.

One of them leans over to another and whispers something. Not a good whisper.

You kept talking. Maybe they just needed more time to understand.

By the end of the meeting, they thanked you politely. They said they’d discuss internally.

They never came back.

---

Here’s why it’s so tempting

You understand the problem now. You understand their constraints. You have authority and depth.

So you show it all.

You think: if they see how deeply I understand this, they’ll trust that the solution works.

But here’s what actually happens: the moment you show more than they asked to see, you shift from teacher to performer.

You’re not explaining their problem anymore. You’re demonstrating your intelligence.

And intelligence is abstract. Trust is concrete.

---

And here’s why it’s a trap

The trap is that you think more information = more confidence.

It doesn’t.

More information = more noise.

Your job isn’t to prove how much you know. Your job is to prove that you understand their problem.

The moment you start explaining things they didn’t ask about, you’re not clarifying their world anymore. You’re cluttering it.

And the more you clutter, the further they drift.

By the end of the whiteboard session, they can’t see the solution anymore. They’re just tired.

---

The asymmetry: You explained everything. They understood nothing.

The fix: Only draw what answers their question.

---

Notice the anatomy

The moment you pick up a marker, you have a choice:

Draw the minimum required to answer their question, or draw everything you know.

Most SEs draw everything. It feels comprehensive. It feels complete. It feels like you’re holding nothing back.

But you are holding something back: clarity.

The telltale sign that you’re about to flood the whiteboard is when:

• You’re thinking about the system, not the customer
• You’re drawing layers they didn’t ask about
• You’re explaining mechanisms instead of outcomes
• You’re drawing for yourself, not for them

Stop.

Erase half of it.

Start again.

Show only what they need to see to understand how their problem gets solved.

If they want to dive deeper, they’ll ask. And when they do, you answer that specific question, not the entire architecture.

---

The counterintuitive inversion

You think showing restraint makes you look like you don’t understand.

It does the opposite.

The experts who can explain a complex system in five minutes are more impressive than the ones who need fifty.

Knowing what to leave out is a form of mastery.

It’s also a form of respect. It says: I understand your time is valuable. I understand you came here to solve a problem, not to get a computer science degree.

The willingness to simplify is what separates confidence from arrogance.

---

Three contexts where the whiteboard flood lives

Architecture deep dives

You’re explaining how the system works under the hood. This is where it’s most tempting to draw everything. Resist it. Draw only the layers that matter to their decision. If they want to know about failover mechanisms or data replication, they’ll ask.

Technical objection handling

A skeptic asks a hard technical question. Your instinct is to prove them wrong by showing all the engineering that goes into correctness. Instead: answer their specific question. Prove their concern is addressed. Stop.

Early in the evaluation process

This is when they’re still forming opinions. Every box you draw becomes something they have to understand before they can trust you. Fewer boxes = faster path to confidence.

---

The pattern to remember

Complexity demonstrated is not complexity explained.

Drawing everything is not the same as making sense of it.

Your job isn’t to show them how smart you are.

Your job is to show them how simple their solution is.

Draw only what they need to see. If they ask for more, you draw more.

But start with the minimum.

Clarity beats comprehensiveness every single time.

---

Have you sat in a demo where the presenter drew everything and you got lost halfway through? Reply and tell me what would have helped you follow along. (Anonymized, always.)

— Dan
​