People like to say this could have been an email. Sometimes that is true. In this case, it could have been a question to a teammate.
We already had project documentation. The business team had discussed requirements with the client. Specifications were available. Work was organised on Azure Boards. Several of us understood our assigned tickets.
One teammate asked the project manager a question. The PM did not know the answer. Rather than first checking whether somebody on the team could help, the PM called a meeting involving about six people.
As I remember it, an email ended with:
“No work is to be done until we meet!”
It still landed like a full stop on the afternoon.
Stop work, then wait for calendars
What followed was the usual scheduling dance. Some people were available immediately. Others could join later. Being told to stop work and then waiting for everyone’s availability was, to put it mildly, irritating. Calendars are calendars. The mismatch between “stop everything” and “when can you all make it?” was still absurd.
Eventually the meeting happened.
What the meeting actually did
People explained their work and their assigned tickets, even though those assignments were already visible on the board. Then the original question came into view, and colleagues who knew the answer helped. That was the useful part of the call. It took several people to get there.
As I remember it, everyone left with the same work and the same understanding they had beforehand. No requirements changed. No assignments changed. No implementation decisions changed. The meeting had assembled a committee to rediscover a fact that already lived with a teammate.
I do not know the PM’s motives. What I object to is the route they chose: turning a local question into a whole-team event.
The quieter damage
The person who originally asked the question felt bad about what it had turned into. Afterwards, she took questions to teammates rather than that PM. Intent is not required for the effect.
Asking for help was not the problem. How the question was handled was.
That distinction matters. If people learn that a simple question can summon six colleagues and a stop-work order, they do not become more independent. They become more careful about who they ask. Careful, in this case, meant avoiding the person whose job included coordinating the work.
What I would have preferred
I do not expect a PM to know every technical detail, or to have read every ticket before asking for help. What I object to is escalating a question to the entire team before checking who could answer it. Something as simple as “Does anyone know the answer?” or “Can someone help with this?” would have been enough to start. Those are alternatives I wish had been tried, not lines the PM actually said.
What developed afterwards suited the work better. We talked directly with the relevant people in another room and reported status back to the PM. That was not concealing work. It was not excluding the PM from decisions. It was solving the problem with the people who had the context, then keeping the coordinator informed.
Meetings can still help when people need to resolve conflicting requirements or make a shared decision. This was not that meeting. This was a question with an answer already sitting nearby.
A smaller route
If I am routing a question now, the sequence I want is short. Find out what the question actually is. Ask who can answer it. Involve the people needed. If a decision comes out of it, write that decision somewhere the team can find it.
Several people had to interrupt their work. The meeting repeated information already on the board. Colleagues answered the original question. And the person who asked became less comfortable approaching that PM.
None of that required a dramatic villain. It only required a question to take the longest possible route to the nearest answer.
