Your job as an engineer is not to defend the plan
One of the biggest shifts in my career happened when I stopped treating every new, sudden request as a personal problem I had to solve, and started treating it as a trade-off I needed to explain
Early on, whenever a PM dropped a new task or an "urgent" bug into the middle of a sprint, my default reaction was: “How do I squeeze this in?” I’d work later, skip breaks, switch contexts like crazy, and just push harder. The unspoken assumption was that if I were just a "good enough" engineer, I should be able to make it work
But reality doesn’t care about your motivation. If a new requirement drops on Wednesday, and you try to absorb it through sheer stress just to save the original Friday deadline, you aren't fixing the problem. You are just making the lack of planning invisible. And you'll still feel guilty when Friday gets missed anyway. Now, I look at it differently. I don't try to fit it in; I just ask: “What drops off the plate because of this?”
It’s not pushback, and it’s not drama. It’s just basic transparency. If we add scope, the timeline moves. If you drag me into three more alignment meetings, I have less time to actually write code. These aren't opinions, they're just consequences. A lot of devs think that setting boundaries means constantly shouting "no" at management. It's usually much simpler: you don't refuse the work, you just explain its actual cost. Once that cost is out in the open, let the business decide if they actually want to pay it
Ironically, this creates way less conflict. You’re no longer fighting over priorities. You are just showing people how resources work. Projects rarely fail because someone had bad intentions; they fail because everyone pretended constraints didn't exist until production broke
(One more cat’s photo 😸)