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:
-
Being the quiet engineer isn't a weakness. It usually means you're the one actually building while others are "ideating"
-
Not every technical decision needs "user story mapping"
-
Sometimes the best product decision is telling the PM "no, that would break in production"
-
"Moving fast" doesn't mean skipping architecture reviews for faster "time to market"
One interview, 1000+ job opportunities
Take a 10-min AI interview to qualify for numerous real jobs auto-matched to your profile 🔑
Classic case of an engineer who thinks architecture is everything. Cool story bro, but who's going to maintain this beautiful system when you rage-quit because the PM asked for basic user metrics? This is why we can't have nice things in tech
As a PM with an engineering background - this attitude is exactly why products fail. You built an amazing API? Great. Did you consider scale? Integration patterns? Adoption metrics? Or were you too busy feeling superior about your 'real engineering' work? This post screams junior dev energy
They hate him because he told the truth lmao. Been in tech 15 years, and I've never seen a product fail because the architecture was too good. Seen plenty fail because PMs pushed garbage requirements without understanding technical debt.
Coming from FAANG - this whole thread is giving me startup PTSD.
When your API serves millions of users, you NEED both solid architecture AND market validation. But please, continue fighting about who's more important
I see both sides here, honestly. As a data person, I watch both sides clash every other day! PMs want features for customer acquisition, engineers want clean code and scalable architectures.
Doesn’t success depend on striking a balance? PMs should involve devs in early discussions, but engineers should consider business impact too. Not everything is black and white @MavenHunter
So... should I cancel my PM certification courses? 😅
Nearly 2 decades in the industry and I sorely miss stories like this. Every PM and manager is obsessed with delivering the “best customer experience” that they forget about building actual scalable platforms. Literally every feature I build today feels like a bug fix!
Found the junior dev