I was actively working with a developer on a priority bug fix scheduled to go live in production the next day. The fix required close coordination and real-time validation from my end. At the same time, I was asked to join a call for another task — a new functionality that’s also going live soon.
In such cases, how do you decide what to prioritize?
Do you pause a nearly-complete critical task for a new one with visibility? Or do you focus on wrapping the current task to avoid delay in deployment?
The answer nobody like is “it depends”
If I feel that the meeting will interfere with the ability to get the next day production issue done, I would ask them to postpone if possible, or record the meeting so I can catch up later.
If that is not acceptable, I would go to my immediate supervisor and ask, explain the situation, and get them to make a decision.
If It won’t interfere, I would just attend the call.
I prioritise my work based on who is going to shout at me loudest if I don’t do the thing they want. In the case of a draw, I do the thing I least don’t want to do, in the hope that I won’t need to do the thing I most don’t want to do. Today, I prioritised watching the cricket.
I’m in the same boat—and honestly, juggling conflicts is just part of life as a test lead.
The client wants another walk-through of my data-pipeline test strategy to another group —right when I’m knee-deep in actually running the tests. Slides are useful, but they’ll care a lot more if the release ships on time. Because I’ve got a strong relationship with our PO, he’s backing my decision to bump the extra presentation to the next sprint. That way we keep both promises: the client still gets their briefing, and the release schedule stays intact.
@ansha_batra
Recently, I was working closely with a developer on a high-priority bug fix targeted for production the next day. It required us to coordinate on an ongoing basis, with constant validation on my side to stay on track. Right in the middle of it, a request came in for me to join a call concerning another task a new feature that was slated to go live soon too and was quite visible.
These moments require a brief pause for clear-minded judgment. One glances quickly at the immediate impact, stage each task is in, and risk involved. Since the bug fix was nearing completion and directly related to a production release, I opted to stay with it through. Delaying would have run the risk of either production delay or an actual issue, which we definitely wanted to avoid.
Once that was wrapped up, I jumped into the new feature discussions, catching up, while coordinating the follow-through.
For me, it’s all about weighing cost of delay and clearly communicating with all stakeholders involved so that nothing of critical importance falls through the cracks. Finding a balance between urgent and impact helps in prioritizing the right way.
Answers to below questions can help in making a decision
How long is the call 30 min / 60 min?
Can it be postponed by 24 hours? Try to request for it.
Can it be taken at a time when you would like to take a break from the production issue task post lunch or in the evening if it has to be done today?
Inform the people about this critical task you are involved in and highlight its important and the various task that you have to do.
So they understand and postpone the other task which is yet to go live compared to something customer is worried about now.
But if still they ask you to take the call, it’s there call as we cannot control everything.
Thanks for sharing, Preeti
I totally get your approach, though for me it’s a bit tricky as I’m the only QA here, so things like delegation are more wishful thinking than a real option
And when both tasks feel equally urgent, weighing “importance” can feel like flipping a coin under pressure. Your point about checking if I’ll block someone else by stepping away is something I’ll keep in mind more consciously
Your point about going to the supervisor hit home. I usually just try to manage everything myself and end up stressing out. I think next time, I’ll try asking instead of silently struggling. Thanks for the reminder!
Okay
Prioritising based on who’s going to shout loudest is both painfully true and strangely comforting. And cricket? Fair play. If you’re going to delay something, at least do it for something worth it!
Totally get what you mean abou t deciding between a meeting and getting the actual work done is always tricky.
Really liked that your PO backed you up, that kind of support makes such a big difference. And honestly, reading your reply felt comforting…like okay, I’m not the only one juggling this stuff. Thanks for sharing
Really appreciated how you didn’t just share what you did, but why, that kind of clarity is rare and grounding.
We often get pulled into urgency mode and forget to zoom out, breathe, and think clearly. I also liked how you mentioned looking at the stage each task is in and weighing the risk of delay. That shift in thinking from just reacting to actually evaluating is something we should all try to practice more consciously.
And yes, we’re testers after all! Deep in one task, and the next second we’re handed another. Context switching is basically part of the job description at this point
Totally agree we can’t control everything, especially deadlines and changing priorities. Sometimes we just have to go with the flow and do our best.
That line from video really stuck with me, we don’t make the final call, but we help the team see what’s coming.
And yeah, moving the call to post-lunch or asking for a bit more time is such a smart way to manage things. A little flexibility can really help. Thanks for sharing
The task conflicts I believe highly dependant upon how good are we with “context switching” and coming back to it. Now not only that, but the team we are working with. Context switching can be challenging for some teams or an individual.
As a QA I reckon context switching is the norm cause we often pulled into something urgent. So, how can we decide how to prioritise or pause the nearly completed critical task or wrapping it up causing delay in other tasks?! is a very valid concern.
I have always resolved such conflicts using below questions:
The weightage of the both tasks: time already spent on task 1 vs time needed to spend on task 2.
The strategic front: is task 1 more aligned with business needs or task 2?
The availability of the team of task 2: Eg: While wrapping task 1, but the team for task 2 is only available now and they wont later. In this case I might pause task1 and start task2 to take notes and might shift back to task1- cause why not?
Time sensitive: which task can afford delay? task 1 or task 2?
Last but not least: “Asking question - simple & classic” - if we are not in deciding position ie: we don’t have enough context on task 2 yet, we can always ask from POs, Leads, Manager. It will take the burden of decision making off us and we can continue both tasks simultaneously.
Communicate: We need to communicate whatever as only QA or team we have decided to do and timeline of the tasks completion.
This will not only give us clarity as a QA also to entire team on how we are managing both critical tasks at once!
@ansha_batra have been in a similar position before, so here’s how I would handle it:
Firstly, I would ask to either reschedule or record the Task 2 call.
My main focus would be on Task 1, as it is a priority fix and is scheduled to go live the next day. I would complete the testing and provide sign-off — that would be one task completed.
If any issues arise during testing and the developers are looking into them, I can then join the Task 2 call, which I would have already asked to be rescheduled or recorded.
Since the new task you mentioned doesn’t have a confirmed go-live date and is only stated to be going live “soon,” it can wait. New functionality typically requires dedicated time to fully understand and focus on, so I would prioritize accordingly.
@aimantirmizi I like how you broke it down with practical questions especially the part about availability of the other team and being okay to pause and switch back. That flexibility (and asking questions!) is something I really need to remind myself of more often.
@maithic Your point about prioritizing based on go-live urgency and using that “developer debugging window” to attend other tasks so smart! Definitely going to keep that in mind next time. Also, yes to asking for recordings a simple step but a real lifesaver.
Really grateful for both your perspectives gave me clarity and a sense of calm I didn’t realize I needed!
I think the most important thing here is I don’t chose the priority on my own. The reality I would probably face is the business is going to want both anyway. So sharing that burden may mean someone else can pick up one while you work on the other and also there is understanding and awareness across the team of the decision.
However, if you really are on your own with deciding the priorities (and thats not good) then you have to focus on the task that has the most important outcome. A customer is going to be disappointed if you’re late with either, so if the bug is badly impacting user experience, then rather a late feature than continuing to frustrate the customer.
In my case, I didn’t decide the priority alone either, but in that moment, I had to act fast without much time to align. The bug fix had already consumed significant effort and needed final validation for a next-day prod deployment. Switching context mid-way would have risked delays and possibly rework later.
What I realized is that sometimes visibility can pressure us into pausing something almost done, even when it’s mission-critical. But you’re right, impact should guide decisions. If a bug is actively affecting user experience or blocking the release, then staying focused to wrap that up makes more sense.
Ideally, these moments should spark a quick team conversation just a short sync to realign and redistribute if needed. But when that’s not possible, I think it’s about trusting your instinct and experience to weigh: Which task, if delayed, will hurt the customer/team the most.
gave me clarity and a sense of calm I didn’t realize I needed!