A great manager once told me: "Product managers don't care about technical debt; they care about feature velocity." If you want to justify fixing technical debt or doing a complex migration, you have to tie it back to how it impacts their roadmap. "Doing this now means future features will take two days instead of two weeks." Speak their language, and the alignment happens naturally.

The most exhausting days are definitely the communication heavy ones. I’ve found that building trust early makes a massive difference. If you only ever talk to stakeholders when things are broken or when you're saying "no," they start to see engineering as a bottleneck. Sharing small, proactive updates and involving them in the technical wins helps build a partnership, so they trust your judgment when you eventually do have to push back.

My go-to framework for pushing back is the "Yes, and..." approach combined with trade-offs. Instead of saying a deadline is impossible, I say, "We can absolutely hit that date, but to do so safely, we will need to cut scope on these two items, or accept that we will need a dedicated two-week sprint afterward to clean up the technical debt." Giving them ownership of the trade-off removes the friction and makes it a collaborative decision.

This is the ultimate transition from a junior to a senior engineer. The mindset shift happens when you stop communicating in technical limitations and start communicating in business risk. Instead of explaining the mechanics of a database migration, I frame it around data integrity and system downtime. When stakeholders understand that rushing a feature might cause a outage that affects users, the timeline conversation changes completely.