Prioritizing Multiple Urgent Tasks

When everything feels urgent I still need a ranking function — my rule is that production incidents and anything risking data loss always go first, full stop. After that I sort by how many customers are affected and how hard a rollback would be if we guess wrong. That two-axis filter — impact times reversibility — turns a panicked backlog into a sequenced plan in minutes instead of letting the loudest stakeholder win by default.

I also communicate immediately when the priority stack changes. If I pause a Kafka feature for a payment OOM, I message the PM with a revised ETA and a one-line explanation instead of going quiet and hoping nobody notices. A concrete example: I stopped sprint work mid-story for a memory leak on the checkout path, traced it to an unbounded Caffeine cache that was silently eating heap under peak load, fixed it in a few hours, then returned to the feature with an agreed one-day slip the PM had already communicated to stakeholders. Nobody was surprised, and the trust I built by being transparent made the next negotiation easier.

The through-line I emphasize is that I negotiate scope when time is tight, never test discipline or rollback strategy. Cutting corners on safety is borrowing against a future incident at a terrible interest rate. The tip I close with: if you find yourself doing two urgent things simultaneously, you are actually doing neither well — escalate for a second engineer instead.