This question was migrated from Software Engineering SE.

Software project, small team (<5 people). Line of business Web application, mostly maintenance work. JIRA for the issue tracker.

A developer has several issues in their queue - A, B, C. The developer says, at a meeting, that she's working on A. There's a shared understanding that A, B, and C are on the same level of urgency. The project manager (PM) then asks: what about B (sic)?

Question, would a good PM ask such a question? In my deeply internalized opinion, when the PM asks a subordinate about a task, the hidden subtext is - why is it not done yet? Otherwise, why ask. The issues don't allow for efficient multitasking - there's no natural pauses in them. If the person is working on A, the person can't be expected to work on B at the same time. Neither A nor B are closed in JIRA, so the PM has a way of knowing the dev didn't work on B before starting on A. The tasks are multiday ones. So I think the PM's question was either clueless or mean.

The PM had enough information to conclude that the dev is not and was not working on B. So the way I read it, either the PM couldn't make such a conclusion (clueless) or wanted to put some undue pressure on the dev (mean).

Disclaimer: I'm neither the PM in the story nor the developer. I was on that meeting, though.

  • 9
    What did the developer answer? Why do you assume there was some hidden judgmental subtext instead of the PM just asking "What is the current state of B?" so they can manage the allocation of tasks (i.e. do their job). If B hasn't been started yet, it could be given to another developer. If it is almost done, it might be better to wait for A to be completed then have the developer who started B finish it.
    – ColleenV
    Oct 6, 2021 at 17:42
  • 3
    IIRC, the developer said something along the lines of "I'm on A, when I'm done with that, I'll start on B". Oct 6, 2021 at 17:59
  • 3
    Thanks for clarifying your question. However, I still think you are making a bad assumption. Just because the information exists somewhere in a ticketing system doesn't mean that a person can't ask the person standing right in front of them for the status of a task just to be sure they have the most up to date information and they've remembered the details correctly. Meetings are long enough without everyone having to fully explain why they're asking a question that might be answered if they dug through documentation or remembered every detail from previous meetings.
    – ColleenV
    Oct 7, 2021 at 18:23

7 Answers 7


A PM is allowed to ask about a task. They are even allowed to ask why a task isn't done yet. That isn't "out of line", that is their job.

But asking why something isn't done yet isn't the same as implying that the task should be done already. There are many reasons why the task might not be done where the PM can help: Maybe the issue is blocked waiting for something or someone else. Or maybe the shared understanding of the priorities isn't really shared.

But even if that isn't the case, a totally fair answer to the question is "That's what I plan to work on once A is done - and there really isn't any way to do these two at the same time" - there is no way for the PM to know this without asking.

Unless something significant is missing from the discussion, I don't see how the "PM's question was either clueless or mean". Everyone is busy, everyone just wants to get their work done and go home, and no one can look inside another person's head. If a PM's job is to keep a project running along smoothly, they need to know more that what they can see in Jira, and so they need to ask questions.


When I have several tasks that are equally important, often I will work on a second one when I temporarily have a block on the first. Or, even though multi-tasking is less efficient, I will try to do so. It is not clueless or mean to ask about all tasks, when all are important. Jira may or may not show interim progress.

It is reasonable for the PM to want to know if any work has also been done on B, even if it is just thinking about how it relates to A. It is reasonable for the developer to respond that they haven't yet started on B.


hidden subtext is

Avoid this thinking at all costs. You are putting your values onto another person's actions. Until there is good reason to think otherwise, take statements at face value, not with extra intentions thrown in. We could come up with dozens of reasons why the PM asked the question, but the most likely is that they need to update the start and end dates on the project plan for it.

PM: "What about B?"

Worker: "Not started yet, I expect to get to it on Thursday after A is done."

That's it, no hidden agendas, just plain statements said without malice.


First assume the PM hasn’t done anything wrong. Which means the best response is to simply check that the B task is up to date in your ticketing system.

“This is correct and up to date. Work on B hasn’t started yet.”

If the PM wants more than that let them make what that is clear. Avoid assuming people mean the worst.


So let's say that the developer had answered:

Actually to even start on B, I need access to the FooBar system. I've raised a ticket with support yesterday but haven't heard anything back yet, which is why I picked up A first.

Let's say task A will take 3 days to complete and the would-be blocker will take 2 days for the PM to resolve.

  • By asking about it up-front, they can chase it up/escalate etc. & make sure that by the time the dev is ready to pick up Task B, her access is ready and waiting. She can then spend all her time on tickets & wastes no time being blocked.

  • On the other hand, if they waited until the dev started work on B, the dev would be sitting blocked (unnecessarily) until the issue gets resolved.

Being pro-active in these types of things is how a good PM can bring the most value to the team in my opinion.

  • Plausible scenario in general, not the case here. Oct 7, 2021 at 19:49

I would just say "I will do B as soon as I am finished with A. Do you have any questions about B?"

Possible answers from the PM could be:

  • They want me to give a time estimation for B so they can better schedule the project.
  • They are not sure about the priorities anymore and want me to interrupt my work on A to finish B first. Switching between tasks has a cost for developers which project managers should be aware of, but there could be a good reason for that. So if they insist...
  • They want to change something about the details of B and want my input.
  • They want to assign B to someone else and want to make sure I didn't start it yet so there is no duplicate effort.
  • They just want to make sure B gets mentioned at all in the meeting so that everyone remembers that B still exists. Kinda condescending, especially when it's on the Kanban board. But reminding everyone of the current state of the project is what PMs are for.

From here, it doesn't seem that it was mean and was simply the PM trying to establish if the status on JIRA was the current position, in case work had started and not been updated.

What would bother me however is the work allocation from this example and prioritisation level. One person out of 5 has 3 tickets all of the same importance. If all three had the same level of importance and urgency and required updates to the PM, why was these not distributed to others in the team?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .