A good way to partition the complainers into serious and unserious groups is to ask for a written plan. Unserious complainers backoff quickly, while serious complainers will be glad someone is taking their suggestion seriously.
A good way to partition the complainers into serious and unserious groups is to ask for a written plan. Unserious complainers backoff quickly, while serious complainers will be glad someone is taking their suggestion seriously.
It's a sure was to demotivate a serious complainer. He knows the vote will be turned against him.
The only was to give him confidence is to promise that the plan will be judged objectively, not democratically.
Objectivity in tech is more often than not in the eye of the beholder.
If it is really a good idea, it will attract the attention of other serious people and become common knowledge in the organization. The shift in common knowledge is the most important change because the problem goes from something that many think they have to live with, to something that has a solution. At that point it becomes something to prioritize against everything else.
This does present some risk to leaders, it's much easier to seem incompetent when there are solutions available that are not being put to use. Leaders need to specifically address why known solutions aren't being implemented yet, and rationalize the decision.
Knowing how to fix the problem shouldn't be a hard prerequisite to raising an issue. I've seen situations where everyone on the team is aware of a problem, but the only people with authority to solve it are sitting around waiting for it to work itself out without their intervention.
Of course the natural thought is "raising an issue constructively isn't complaining", but there's a kind of viewpoint bias on both sides of this. Sometimes people who are too wedded to some idea or way of doing things view any criticism at all in a reflexively negative light, just as some people tend to air grievances as a hobby without a constructive outcome in mind.
Complaint: tickets created by the QA team for developers, even seemingly trivial ones, stagnate in Jira for months and sometimes years without anyone looking.
Written plan: Hire somebody who will be actually responsible for planning and prioritization. Hire more developers, so that the existing ones are not overloaded.
Reality: "This is not a realistic plan. There is a budget, and you are not the one who makes hiring decisions, so shut up and stop creating tickets unless there is something really serious".
So - is the complainer above serious, or not?
(all of the above is pure fiction)
This can be good but I've seen it weaponized before by an incompetent cto to deflect and delay any change. He would ask for written proposals on the most minute details until people just gave up trying to fix anything.