They Can’t Read Your Mind – Communicate Proactively

The Phantom Refactor and the Confused Teammate You just spent four hours untangling a horrifying mess in the checkout flow. You didn’t touch the logic - just “cleaned things up.” Now it’s testable, composable, and finally worthy of your self-respect. You push it, mention “minor refactor” in the commit message, and go to lunch. Thirty minutes later, your teammate pings you: “Hey, did something change in OrderService? My branch is broken and I don’t know why.” You sigh. Obviously it changed. It was a nightmare. But you didn’t think anyone else was touching it. You didn’t think anyone needed to know. And there it is. The senior engineer’s curse. You’re not wrong. But you’re not helpful either. The Myth of the Obvious Once you’ve internalized patterns, tradeoffs, and architecture lore, you stop needing to explain them to yourself. That’s great. It means you’ve leveled up. But it also means your instincts are now invisible to the people around you. You think you’re being efficient. Quietly fixing things. Heroically pushing through blockers. But to your team? You’ve gone radio silent. You’re now the “surprise dragon” who periodically flies overhead and changes the terrain. That’s not senior. That’s spooky. The Cost of Silence Here’s what happens when you don’t narrate your decisions: People second-guess themselves trying to reverse-engineer your intentions. Work gets duplicated—or worse, invalidated—because no one knew what you were doing. Teammates hesitate to ask questions because you seem like you’ve got it all figured out. Junior devs miss out on learning because your process looks like magic. Reviews turn into detective work. You become a bottleneck, not because you’re blocking—but because no one knows where you are on the map. Remember The Best Engineers Don’t Block – They Unblock? This is that. Communication is the oil that keeps the whole machine from seizing. Don’t Make Them Guess. Narrate the Movie. Start treating your work like a director’s commentary. Don’t just build the thing- talk about what you’re building, why, and what others might need to know. You're not adding fluff. You're adding infrastructure. Clarify assumptions. Don’t assume the ticket is obvious. Spell out what you’re assuming it means. Surface decisions. Did you change direction halfway through the sprint? Say so. Narrate thinking. “I’m trying X, because Y. If that fails, I’ll pivot to Z.” This is gold to anyone watching (or joining later). Leave paper trails. PRs. Slack. Standup. Doc comments. Bread crumbs for everyone—especially future you. You don’t need to write essays. Just open the curtain. Give people a glimpse inside the mind of the engineer behind the keyboard. Psychological Safety Is a Two-Way Street You want your teammates to ask dumb questions? Great. But they won’t if you’re always broadcasting “I got this, stay out of my way” energy. In Ask Dumb Questions Early, we talked about lowering the cost of curiosity. You do that by making your own thinking visible. Show that decisions are made, not ordained. Invite others into the process—not just the result. Context Is a Team Sport You already know that Your Code Isn’t the Problem. Your Context Is. But here’s the twist: context is contagious. If you hoard it, your team flails. If you share it, your team flows. Stop being a lone node in a distributed system. Broadcast your state. Sync early, sync often. And don’t wait for a timeout. Don’t Be Mysterious When Clarity Would Help You're not the boss of the meeting. You're the teammate in the pull request. The engineer pushing the branch that rewrites the rules. The ghost refactorer. In those moments? Speak up. Not to impress. Not to control. Just to illuminate the path you’re already carving through the codebase. Because when you don’t - Someone else pays the cost of your silence. And let’s be honest: If your brilliance only works when no one else is around - Maybe it’s not that brilliant.

Apr 20, 2025 - 11:42

They Can’t Read Your Mind – Communicate Proactively

The Phantom Refactor and the Confused Teammate

You just spent four hours untangling a horrifying mess in the checkout flow. You didn’t touch the logic - just “cleaned things up.” Now it’s testable, composable, and finally worthy of your self-respect. You push it, mention “minor refactor” in the commit message, and go to lunch.

Thirty minutes later, your teammate pings you: “Hey, did something change in OrderService? My branch is broken and I don’t know why.”

You sigh. Obviously it changed. It was a nightmare. But you didn’t think anyone else was touching it. You didn’t think anyone needed to know.

And there it is. The senior engineer’s curse.

You’re not wrong. But you’re not helpful either.

The Myth of the Obvious

Once you’ve internalized patterns, tradeoffs, and architecture lore, you stop needing to explain them to yourself. That’s great. It means you’ve leveled up. But it also means your instincts are now invisible to the people around you.

You think you’re being efficient. Quietly fixing things. Heroically pushing through blockers.

But to your team? You’ve gone radio silent. You’re now the “surprise dragon” who periodically flies overhead and changes the terrain.

That’s not senior. That’s spooky.

The Cost of Silence

Here’s what happens when you don’t narrate your decisions:

People second-guess themselves trying to reverse-engineer your intentions.
Work gets duplicated—or worse, invalidated—because no one knew what you were doing.
Teammates hesitate to ask questions because you seem like you’ve got it all figured out.
Junior devs miss out on learning because your process looks like magic.
Reviews turn into detective work.
You become a bottleneck, not because you’re blocking—but because no one knows where you are on the map.

Remember The Best Engineers Don’t Block – They Unblock? This is that. Communication is the oil that keeps the whole machine from seizing.

Don’t Make Them Guess. Narrate the Movie.

Start treating your work like a director’s commentary. Don’t just build the thing- talk about what you’re building, why, and what others might need to know.

You're not adding fluff. You're adding infrastructure.

Clarify assumptions. Don’t assume the ticket is obvious. Spell out what you’re assuming it means.
Surface decisions. Did you change direction halfway through the sprint? Say so.
Narrate thinking. “I’m trying X, because Y. If that fails, I’ll pivot to Z.” This is gold to anyone watching (or joining later).
Leave paper trails. PRs. Slack. Standup. Doc comments. Bread crumbs for everyone—especially future you.

You don’t need to write essays. Just open the curtain. Give people a glimpse inside the mind of the engineer behind the keyboard.

Psychological Safety Is a Two-Way Street

You want your teammates to ask dumb questions? Great. But they won’t if you’re always broadcasting “I got this, stay out of my way” energy.

In Ask Dumb Questions Early, we talked about lowering the cost of curiosity. You do that by making your own thinking visible. Show that decisions are made, not ordained. Invite others into the process—not just the result.

Context Is a Team Sport

You already know that Your Code Isn’t the Problem. Your Context Is. But here’s the twist: context is contagious.

If you hoard it, your team flails. If you share it, your team flows.

Stop being a lone node in a distributed system. Broadcast your state. Sync early, sync often. And don’t wait for a timeout.

Don’t Be Mysterious When Clarity Would Help

You're not the boss of the meeting. You're the teammate in the pull request. The engineer pushing the branch that rewrites the rules. The ghost refactorer.

In those moments?

Speak up. Not to impress. Not to control. Just to illuminate the path you’re already carving through the codebase.

Because when you don’t -

Someone else pays the cost of your silence.

And let’s be honest:

If your brilliance only works when no one else is around -
Maybe it’s not that brilliant.