The Curse of Knowing What You Know

I’ve watched a version of this play out more than once. A staff engineer presents a redesign in an architecture review. Twenty minutes in, two reviewers are nodding; three are quiet.

He reads the quiet as agreement. It isn’t.

Two weeks later, it returns with five questions any of those three reviewers would have asked—if they had the prerequisite context. Three months of design met twenty minutes of audience—and weeks of rework followed.

Nothing about this looks like a communication failure from the inside. That’s the problem.

He can’t see how the questions could arise—because he can’t remember not knowing what he now knows. The gap has a name, and it gets installed deeper every quarter you stay in your role.

The Tappers and the Listeners

In 1990, Stanford grad student Elizabeth Newton ran a now-classic study. Subjects tapped the rhythm of well-known songs—“Happy Birthday,” “The Star-Spangled Banner”—on a tabletop while listeners tried to name them. Tappers predicted listeners would guess correctly about half the time. The actual rate was 2.5%.

Tappers heard the melody in their heads; listeners heard knocking. Each tapper was certain the song was obvious—because for them, it was.

This is the curse of knowledge: once you know something, you can’t accurately model what it’s like not to know it. In engineering orgs, it shows up as a leader frustrated that a team “isn’t getting it”—and a team frustrated with a leader who skips the parts that would make the decision make sense.

Seniority Installs It

Every step up the ladder adds context you don’t realize you’ve absorbed. The EM sits in the planning conversation where scope got cut before the team ever saw the original. The director sees the financial constraint that killed the migration. The VP carries the political memory of the org that tried this two years ago and failed.

You communicate from inside that context. You name decisions and skip the journey. The conclusion arrives without the reasoning behind it. When people ask questions you answered months ago, it feels like resistance—not a knowledge gap.

The capability you were promoted for—pattern recognition, compression, judgment—is the same capability that now breaks transmission.

How It Leaks Out

Once you look for it, the fingerprints are everywhere:

• Design docs that specify the what without the why, because the why feels too obvious to write down.

• Roadmap reviews that describe trade-offs at the resolution they were made, not the resolution the audience needs.

• OKRs written at the altitude leadership negotiated, not the altitude the team has to execute at.

This isn’t individual failure—it’s structural. A transmission problem that worsens with seniority.

It Looks Like a People Problem

From the leader’s seat, the curse looks like a people problem—the team isn’t aligned, they lack urgency, juniors don’t grasp the scope. Each diagnosis triggers a predictable intervention: more all-hands, better OKRs, tighter performance management. The mechanism stays invisible.

Even strong communicators hit this wall. Fluency hides the failure.

The diagnostic question isn’t did I explain it well?

It’s what context made this conclusion obvious to me—and have I made that context available—not summarized, available—to the people I expect to act on it?

What Actually Helps

The fix isn’t humility theater or “explaining better.” It’s a small set of mechanisms that compensate for a bias you can’t will away.

Make rejected alternatives part of the design. A design doc that presents only the chosen approach compounds the curse—reviewers must reverse-engineer your reasoning before they can challenge it. Require an “Alternatives Considered” section with at least two rejected options and why each lost. Not “performance”—the load profile, the benchmark, the threshold. Rejections teach more about the constraint space than the recommendation.

Treat “operator error” as a finding, not a conclusion. When an incident review lands on “the on-call missed it,” that’s not a root cause—it’s the curse of knowledge in the postmortem. Investigators now have the full timeline; the operator at 2 a.m. had whatever the dashboard showed and the runbook said. Ask what the system surfaced at the decision point—and what it hid. The answer usually points to a runbook or dashboard written for a simpler system. If you keep landing on operator error, you’re not investigating; you’re confessing.

Send it to someone one level less marinated. Before a design doc or proposal goes wide, hand it to a senior engineer with enough context to engage—but not enough to fill in your gaps. The questions they ask are the ones everyone else has but won’t raise in the larger room.

Design Around the Asymmetry

Leaders who handle this well don’t pretend they share the team’s context.

You can’t unknow what you know. The curse isn’t a flaw in your communication—it’s a side effect of becoming the person the org needed. The work isn’t to roll back expertise; it’s to stop assuming it’s transmitting just because you’re using words.

If your team keeps not getting it, the question isn’t whether they’re listening.

It’s whether what reached them was the song—or just the tapping.