Important post for every Techie 👩🏻‍💻

I've been lurking on Grapevine for months, and it's time I shared something different. Not another "How I 3x'd my TC" post but something that surprisingly changed my life more than any offer letter could.

Headphones on, camera off, speaking only when cornered in meetings. Classic "backend guy who actually builds stuff while PMs create JIRAs about creating JIRAs."

Every standup was psychological warfare. I'd give my update, then watch our PM derail the entire thing with "quick questions" about "go-to-market strategy." Meanwhile, actual technical dependencies sat burning. But hey, at least we had our fifth competitive analysis deck of the quarter, right?

Then came the day of our founder's review. Critical API migration presentation. Our tech lead's out, PM's ready with their 40-slide deck about "market opportunity" (for an internal API...).

That's when I did something stupid. In the silence after the PM finished their novel about TAM expansion, I unmuted: "Can I walk through the actual architecture we built?"

Hands shaking. Felt pukish almost. But here's the truth, I'd spent weeks architecting this while our PM was "gathering requirements" (read: creating more Kanban boards).

The founders started asking questions. Real, technical questions. Not "how does this affect our Q4 OKRs?" but actual system design questions. For once, we had a discussion about engineering, not "customer stories."

The PM started being listened to less and less over the next few weeks while people started coming to me for answers.

Suddenly, senior devs were DMing me for design reviews. EMs wanted my input on architecture. Even PMs (the good ones) started asking technical questions before creating roadmaps.

Some Counterintuitive Truths:

1. Being the quiet engineer isn't a weakness. It usually means you're the one actually building while others are "ideating"

2. Not every technical decision needs "user story mapping"

3. Sometimes the best product decision is telling the PM "no, that would break in production"

4. "Moving fast" doesn't mean skipping architecture reviews for faster "time to market"