🐉 Crouching Tiger, Hidden Principal Engineer
was hired to fix code. I ended up fixing the communication between two departments that refused to talk. Welcome to the unofficial job of a principal — even if your badge says ‘contractor.’
🧑🚀 Context: I’m a Contractor, Not a Core Hire
I was brought in to solve technical problems: systems that didn’t scale, event pipelines that were fragile, and legacy architecture that couldn’t keep up.
And I did that. I built domain-driven structures, added command/event boundaries, made unit tests free, and shaped the technical strategy.
But somewhere along the way, I became the unofficial router between Product and Engineering.
Because they stopped talking to each other.
🧩 The Gap Nobody Talks About
Product and Engineering are supposed to collaborate. That’s the dream.
But in high-pressure startup environments, what actually happens is:
Misaligned priorities
Vague specs
Ghosted tickets
Friction on standups
People talking about each other, not to each other
It’s nobody’s fault. It’s just what happens when everyone’s trying to ship and survive.
So I stepped in. Not because I wanted to — but because I was the only one with context on both sides.
🧠 What Bridging Actually Looks Like
It’s not standing in meetings. It’s:
Translating business goals into clear technical tasks
Managing scope creep without hurting relationships
Protecting engineers from last-minute chaos
Pushing back with kindness when product throws curveballs
Explaining technical constraints without sounding like a blocker
It’s emotional architecture — holding the team together when communication is more broken than the code ever was.
🚫 Why It’s Exhausting
But this is also the hidden job of a Principal Engineer — whether it’s in the job description or not. Bridging communication gaps, protecting focus, and aligning chaos is part of the value I bring. It just doesn't always show up in Jira/Linear.
But without this glue:
Features don’t ship and/or the wrong features get built
Bugs get misprioritized
Engineers get demoralized
Product doesn’t trust delivery
Everyone’s frustrated — and nobody knows why.
So someone has to carry it — and more often than not, it's the person with the clearest context and the least official authority.
🧰 Tools That Help
Here’s what I lean on:
Architecture diagrams that product can read (mermaidjs)
Shared domain language (via commands/events) that both engineering and product can understand
Slack threads instead of ticket ping-pong
Internal blogs/docs that explain “why” behind technical tradeoffs
Trust capital earned through consistent delivery
It’s not magic. It’s just choosing clarity over silos.
🏁 TL;DR
I was hired to fix the codebase.
But I ended up fixing the communication loop and the codebase.
Sometimes leadership means knowing when to write code, and when to be the bridge no one else wants to build.
Even if you're just a contractor.
