Calling someone a complainer is corporate-speak for “they noticed the fire before leadership did.” The people who raise flags get sidelined, the cheerleaders get promoted, and then everyone wonders why the product sucks.
A good manager doesn’t suppress complaints. They treat them as free QA. But that requires humility, which is in even shorter supply than good engineers.
I'm not a manager and have no aspirations at all to be one, but I have worked with plenty of "complainers".
Usually what complainers complain about has nothing to do with why they are unhappy. Way too often frustration with people is pointed at circumstance rather than trying to productively sort out the conflicts between the individuals.
And here is where management usually fails. A person complains about unrealistic time plans or how crappy a product will be, so management jumps into action and invent over elaborate processes around securing deadlines and quality, rather than splitting up the dysfunctional team that can't / refuses to cooperate and therefore is always late and produces sub-par quality. And the team will still be late and produce bad quality, and the complainers will still complain.
> so management jumps into action and invent over elaborate processes around securing deadlines and quality, rather than splitting up the dysfunctional team that can't / refuses to cooperate
Yes, I've seen this!
Then they fire the dysfunctional team, but the problem was the incompetent management.
Spoken like from someone who never managed teams. There may be valid complaints but there may be also just difficult characters.
To answer the original question: It's a bit like in romantic relationships. Trying to change personalities of others is a tough game (usually not worth it).
This is true in some cases…but there are other people who just complain because they want attention.
Good managers listen and try to understand the difference between a person complaining because they’re closer to the problem and a person complaining because they are the problem.
> there are other people who just complain because they want attention.
I would say that people who complain generally do it because they are not happy. Nobody purposely do it as a way to get attention. Nobody says "I will make sure to bother everybody so that they hate me, because I love it".
Doesn't mean they are not the problem: sometimes they are, sometimes they aren't. So I join you on:
> Good managers listen and try to understand the difference between a person complaining because they’re closer to the problem and a person complaining because they are the problem.
I have seen people complain because they somehow hated their coworkers (they had a very different view of what "good code" meant). A good manager would look for a solution, like moving them in different teams. A bad manager doesn't act (it's useless to listen if you don't act on it).
Also individual contributors often fail to grasp the big picture, what seems like an insurmountable issue to them is irrelevant or not a priority in the grand scheme of things. Or it's a pain point for them - but dealing with it will hurt the project overall. Can't even count the number of development/design/product bike shedding discussions, wasted effort on covering edge cases, etc. on features/products that get scrapped once they get tested by users.
This is why I hate managing people - I hate having to deal with all the egos and trying to empathize with everyone to try to get a sense of where they are coming from just to judge what's important or not, and weighing political impact of different calls. Code is simple by comparison.
A lot of this can be solved just by telling that to the developers. Sometimes I feel like I'm in some sort of secret don't-let-your-right-hand-know-what-your-left-hand-is-doing style organization. I was trying to meet [artificial] deadlines and putting effort into handling every corner case while a project was doomed due to external factors (lawsuit).
My most productive time is when a manager is honest and willing to explain how the whole thing fits together.
This is the hardest part of dealing with a chronic complainer: they think they are the only one "noticing a fire" and "getting sidelined" for raising flags.
Often there isn't actually a fire, they're complaining about trivialities. Everybody already knows about the fire because they've complaining about at every meeting for three months. Or the thing they are complaining about can't be changed. They're actually getting sidelined because they interrupt company allhands to ask the CEO irrelevant questions, wasting the time of 50 people and no one likes them anymore.
I view dealing with chronic complainers as mentoring them to stop self-sabotaging themselves.
Sometimes I find that there is a question of preferences. Take 3 architects, they will come up with 3 different architectures. There is "style" in architecture. Some people will complain because the chosen architecture is not their preferred one, and they see everything that is not their preferred choice as "bad".
I feel like establishing a hierarchy may make sense here: "This person is the architect, you are not. You may disagree and make technical arguments to them, but at the end of the day, they take the decision and you have to follow it". Of course it means that the architect has to actually listen to the technical arguments, and not go "I'm the architect, I'm better, just shut up".
I think it is really hard for certain people to admit that there are multiple ways that lead to the goal and that those other ways (not their preferred ones) are probably just as valid. And when the choice is made not to take their preferred way they turn into net negatives because now they are going to prove their way was better by sabotaging the alternative. This can wreck projects quite handily.
The best managers build consensus and try to avoid people digging in behind 'their' solutions. This is hard work.
This is one of the hardest things to teach new developers doing code reviews: your way isn't better, it's just different. And, sometimes it may be somewhat better but not worth changing for working code. This is especially true when talking about clarity vs succinct.
I have a lot of patience for disagreements and alternative solutions. But at some point you need to "support the group" and not re-litigate at every opportunity.
I see that as the difference and when it becomes complaining and toxic.
> Complaining is not a character flaw; it is a response shaped by context, past experiences, and unmet needs such as recognition, belonging, or agency. When leaders interpret complaint only as negativity, they risk silencing the very signals that reveal what people care about. By seeing complaints as expressions of care in disguise, leaders can move beyond irritation and instead use inquiry to uncover underlying concerns, redirect energy, and invite ownership. In this way, what begins as frustration can become the raw material for contribution and engagement.
Sometimes it is. I was complaining a lot, but then someone had enough and explained to me that it isn't productive (complaining about every minor annoyance) and makes people not like me. Now I'm not complaining so much, only when I know how to change something or that it really needs to be changed. My life got a little better.
I'm not making a claim one way or another. I merely quoted the article in response to this claim by OP:
> Calling someone a complainer is corporate-speak for “they noticed the fire before leadership did.”
Just so I'm being crystal clear: I was pointing out that the article already addressed OP's statement.
I should also point out that your own comment doesn't refute the article. You just followed the article's advice for yourself rather than for a subordinate (which is fine).
I strongly disagree. Noticing the fires is often trivial. Complaining... It depends. Complaining constructively is fine. Complaining for the sake of complaining gets annoying very fast.
Also... People that spend a lot of time complaining are usually that aren't capable of making things happen anyway. They can only see the limitations.
I avoid those people I noticed they just bring down my mental focus.
There are plenty of people who complain because its baked into their personality. Those people can also work at a bad place and have a target rich environment so to speak.
The only sure fire way to avoid this label being applied unjustly is always bring solutions, not complaints. Document your solutions and let it rest if leadership doesn't agree.
This is typically what I see. There ARE chronically negative people, but more often “complainers” are the smart people who don’t rely on passive voice and jargon to get ahead or, having been ignored for years by the passive voice jargon cheerleaders while their concerns came true, are bitter and punching the clock.
Most of the time, complainers are a exhibiting a personality trait (or learned behavior as the article says); let's call those "unserious complainers". Some of the time (maybe 10% IME), the person complaining knows how to fix a problem, and is confused why no one is taking them or their suggestion seriously. It could be that the problem has existed for so long that the team has a cognitive blindness, or the team is swamped and has no capacity to think strategically.
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.
That's a great call but it should be paired with a promise: you present your great plan and then we'll put it to a vote. Otherwise you are just trying to get rid of them with busywork.
I've found that it's enough to just widely circulate it. As you point out, it's important to have some guarantee, so that the writing seems worth it.
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.
Well, that's part of politics. To get people on board the complainer will then have to try to build some consensus. If you start out from the premise that the vote would be turned against him then he should simply leave for a company that is worthy of his talents instead.
Objectivity in tech is more often than not in the eye of the beholder.
I think many long-time managers can recall some time were they really just put up busywork for them to not have to deal with that team member. It's not the best solution but sometimes it eases political conflicts.
I wouldn't recommend this. As I mentioned in a reply to a different post: A good idea, widely visible, must be addressed by leadership. Failing to do so makes you look incompetent as a leader. That doesn't mean it has be implemented immediately, but it needs to be referenced in the larger plan, along with a rationale.
> Some of the time (maybe 10% IME), the person complaining knows how to fix a problem,
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".
> A good way to partition the complainers into serious and unserious groups is to ask for a written plan
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.
There's rude, but precise Russian saying: "Initiative f*ks the initiator". This approach is a good way to ensure that there will not be initiative people in the team.
Not everything needs to be done yesterday. I've "executed" plans where leadership basically flips flops on their position. The team started putting all these hare brained ideas behind feature flags.
I once worked for a small consultancy which did business by fishing for contracts, then doing the absolute to-the-letter minimum to fulfill them, irrespective of damage to the customer’s business or the company reputation. We would deliver working software that was absolutely awful to actually use for anything.
Often, clients would literally tell us to f*ck off when they realized we would not do anything that wasn’t in the contract verbatim, no matter how trivial.
To me, it was insanity. I would have preferred actually solving customer issues in a partnership fashion, and day-to-day work was nightmarish due to the constant conflict of values. Raising an issue about this got me branded a complainer.
The company slowly gathered enough references to attract some bigger clients (realistically: via backroom deals and kickbacks) and was eventually acquired, and some time later the executives were politely told to pack their things and get out.
They got what they wanted: a hefty paycheck and a load of shares from the acquiring company. The entire company was an acquisition scam from the get-go.
Depends on what they are complaining about and how they are doing it. In general, I would ask them how they would fix the problems they're complaining about. The first two steps to fixing any problem are to identify any analyze it. This might be their (unideal) way of doing that.
Many years ago in my software engineering course, my professor said that he would add to Fred Brooks' concept of a "surgical team" and said that he found that many successful engineering teams had a "team mother": the person that helped quell disagreements, remembered birthdays, cheered the successes no matter how small, kept tabs on how folks were doing emotionally, etc. Years later in my professional career, I found this to be true and met a few people like this on my teams -- not the best engineers, but additive to a great team.
I think that successful teams may have a place for a "team canary" (?): someone that is going to speak up about points of friction where most others might just end up with apathy and learn to deal with the inefficiency or friction (a "that's just how it is" attitude). Sometimes, complaints are a sign of genuine friction. Complainer may not feel like they have the authority/allotted bandwidth to remove the point of friction. When this happens, give this person some ownership of the friction points and see what happens.
I had worked with a guy which is smart, or at least persuasive, since him was hired somehow. He after started working with the team, him complaining about the project proposal, about the bad code decisions and had serious discussions with the product owner. After I talked with the PO, I opened a meeting with the complainer to extend my hand and say that I was opened to listen, him thanks me but preferred to stay a little away. The CTO proposed that since him spotted a bad code (it really was), him had time to analyze better and fix! In the end him lost 2 or 3 weeks fixing the code, wasn't able to finish and request resignation directly to the HR with the reason that the team and the project was bad, probably criticized the CTO. I had to take the code him left and finish the fix!
I think some of the most important problems get hidden if there is a culture where you expected to also want a specific solution before you complain. People avoid reporting difficult, complex problems without obvious solutions. Maybe they just see somethings as "the way things are" at that org or that leadership doesn't want to hear their needs.
Better to have a free, easy ability to complain about things, and if there is a good manager hanging around somewhere, they can synthesize the complaints and discover if there are solutions possible at the org level, which individual contributors might not know about or even be functionally able to own.
>The project plan is flawed. The deadlines are unrealistic. Leadership is out of touch.
Fascinating examples. I have never in my professional career heard anybody refer to these as "complaining". "Complaints", yes, but in English that has does not have the same connotation.
I scanned the article to see if "check whether any of their compaints are valid" but didn't see it anywhere. Sometimes maybe the person complaining might be right..
Unproductive complaints are... frustrating if you're on the receiving end of them, because they are basically (and unproductively) asking for help / solutions. But if it's just complaints, they also have the impression that the problem is not in their "sphere of influence"; coffee, for example, is usually handled by a facilities department. It's easy to complain about coffee to your boss, but it's confrontational if you actually pull the issue into your sphere of influence and go to the facilities department to complain.
It opens you up to vulnerability. You speak to people you don't usually speak to; you get confronted with the realities of that particular issue; office coffee for example is often a factor of budget vs cost, long-term supply and support contracts with coffee machine companies, and of course personal taste. Are you going to take on some responsibility for all that?
Of course, the other part is that you get hired for one job, stepping outside of that role to pursue something not directly impacting said job is often frowned upon. I say often because it's a bit of both, the best people will take on more and different things than what they were hired for.
Anyway. Complainers can / should get a training about "circle of influence/control", also because I doubt that work stuff is the only thing going on in their life, it can help them outside of work too. Knowing what you can change and what is outside of your control is great for your peace of mind and general attitude.
The article really does a great job of setting up Survivorship Bias and then completely drops the ball.
Of course chronic complainers complain about stuff out of their control. They've fixed (at least in thier eyes) the items within their control. Asking them "what would they do" is but itself entirely ineffective unless anybody is going to act on it.
> Example: A team member repeatedly complains about timelines. Each time, the manager extends them. Soon, complaining becomes the default negotiation strategy.
Well, are the timelines too short? Is the team member complaining, or are they pointing out actual problems with the proposed timeline? And if the complaining gets the timeline extended to something reasonable, is there a problem with it being a negotiation tactic if it works?
> Learned helplessness: complaint as despair
> Leadership move: Restore agency through small wins.
This feels like when we'd let our five year old pick out what clothes she wanted to wear. Shouldn't the leadership move here be to try to solve the source of the despair?
This article focuses on dealing with the team member, and not the sources of the complaints. Sure, some people are just negative downers. But the first three examples on the page seem like actual external problems that the complainers are noticing and voicing concern about.
(And if you think it's bad to have complainers, wait until the complainers realize that no change is forthcoming, and either stop engaging at all, or go find work somewhere better.)
It seems as if the leadership in this situation hasn't even considered that they may be in the wrong and the points brought up maybe valid. So many teams set unrealistic deadlines or expectations based on dates plucked from the air and then wonder why work can't be completed on time.
How does this font achieve the awful "shifting baseline" effect?
I assume that it is using a ton of ligatures, because consecutive letters always look different, but is that the only thing going on or is there something even more pernicious happening?
The one time I visited Google for a round of interviews, they assigned the complainer to take interviewees to lunch. It was enough to keep any interest I had in Google at bay forever.
In my experience, people complain because they don't feel heard or they feel ignored (different feelings). Some people are also wired to complain; it's therapeutic to them. Both are coachable.
Am I the only one who doesn’t care if the team has one individual with such traits? Like, if it slows down execution, well, I’m not into squeezing the last drop of speed of everyone. Also, people like that always give you the chance to show how good you are (supposedly): you can support them with potential fixes, you can support the team by saying perhaps that the complaint is not a big deal because data says so, whatever.
It’s like those people who are racist: they always make me feel better with myself because I don’t hold such beliefs. If everyone would be a saint, I would feel a bit down (because I’m not one).
It's fine if you can ignore them and don't have to work with them. If you do it's really draining. Constant negativity is not fun to be around.
I have only worked with one person in my life who was really like this though, so maybe you're just lucky and haven't experienced a truly committed negative Nancy.
Calling someone a complainer is corporate-speak for “they noticed the fire before leadership did.” The people who raise flags get sidelined, the cheerleaders get promoted, and then everyone wonders why the product sucks.
A good manager doesn’t suppress complaints. They treat them as free QA. But that requires humility, which is in even shorter supply than good engineers.
I'm not a manager and have no aspirations at all to be one, but I have worked with plenty of "complainers".
Usually what complainers complain about has nothing to do with why they are unhappy. Way too often frustration with people is pointed at circumstance rather than trying to productively sort out the conflicts between the individuals.
And here is where management usually fails. A person complains about unrealistic time plans or how crappy a product will be, so management jumps into action and invent over elaborate processes around securing deadlines and quality, rather than splitting up the dysfunctional team that can't / refuses to cooperate and therefore is always late and produces sub-par quality. And the team will still be late and produce bad quality, and the complainers will still complain.
> so management jumps into action and invent over elaborate processes around securing deadlines and quality, rather than splitting up the dysfunctional team that can't / refuses to cooperate
Yes, I've seen this!
Then they fire the dysfunctional team, but the problem was the incompetent management.
Spoken like from someone who never managed teams. There may be valid complaints but there may be also just difficult characters.
To answer the original question: It's a bit like in romantic relationships. Trying to change personalities of others is a tough game (usually not worth it).
This is true in some cases…but there are other people who just complain because they want attention.
Good managers listen and try to understand the difference between a person complaining because they’re closer to the problem and a person complaining because they are the problem.
> there are other people who just complain because they want attention.
I would say that people who complain generally do it because they are not happy. Nobody purposely do it as a way to get attention. Nobody says "I will make sure to bother everybody so that they hate me, because I love it".
Doesn't mean they are not the problem: sometimes they are, sometimes they aren't. So I join you on:
> Good managers listen and try to understand the difference between a person complaining because they’re closer to the problem and a person complaining because they are the problem.
I have seen people complain because they somehow hated their coworkers (they had a very different view of what "good code" meant). A good manager would look for a solution, like moving them in different teams. A bad manager doesn't act (it's useless to listen if you don't act on it).
Also individual contributors often fail to grasp the big picture, what seems like an insurmountable issue to them is irrelevant or not a priority in the grand scheme of things. Or it's a pain point for them - but dealing with it will hurt the project overall. Can't even count the number of development/design/product bike shedding discussions, wasted effort on covering edge cases, etc. on features/products that get scrapped once they get tested by users.
This is why I hate managing people - I hate having to deal with all the egos and trying to empathize with everyone to try to get a sense of where they are coming from just to judge what's important or not, and weighing political impact of different calls. Code is simple by comparison.
A lot of this can be solved just by telling that to the developers. Sometimes I feel like I'm in some sort of secret don't-let-your-right-hand-know-what-your-left-hand-is-doing style organization. I was trying to meet [artificial] deadlines and putting effort into handling every corner case while a project was doomed due to external factors (lawsuit).
My most productive time is when a manager is honest and willing to explain how the whole thing fits together.
This is the hardest part of dealing with a chronic complainer: they think they are the only one "noticing a fire" and "getting sidelined" for raising flags.
Often there isn't actually a fire, they're complaining about trivialities. Everybody already knows about the fire because they've complaining about at every meeting for three months. Or the thing they are complaining about can't be changed. They're actually getting sidelined because they interrupt company allhands to ask the CEO irrelevant questions, wasting the time of 50 people and no one likes them anymore.
I view dealing with chronic complainers as mentoring them to stop self-sabotaging themselves.
Sometimes I find that there is a question of preferences. Take 3 architects, they will come up with 3 different architectures. There is "style" in architecture. Some people will complain because the chosen architecture is not their preferred one, and they see everything that is not their preferred choice as "bad".
I feel like establishing a hierarchy may make sense here: "This person is the architect, you are not. You may disagree and make technical arguments to them, but at the end of the day, they take the decision and you have to follow it". Of course it means that the architect has to actually listen to the technical arguments, and not go "I'm the architect, I'm better, just shut up".
I think it is really hard for certain people to admit that there are multiple ways that lead to the goal and that those other ways (not their preferred ones) are probably just as valid. And when the choice is made not to take their preferred way they turn into net negatives because now they are going to prove their way was better by sabotaging the alternative. This can wreck projects quite handily.
The best managers build consensus and try to avoid people digging in behind 'their' solutions. This is hard work.
This is one of the hardest things to teach new developers doing code reviews: your way isn't better, it's just different. And, sometimes it may be somewhat better but not worth changing for working code. This is especially true when talking about clarity vs succinct.
> This is especially true when talking about clarity vs succinct.
Don't get me started on that one. And its close cousin, correctness vs speed.
I have a lot of patience for disagreements and alternative solutions. But at some point you need to "support the group" and not re-litigate at every opportunity.
I see that as the difference and when it becomes complaining and toxic.
From the article:
> Complaining is not a character flaw; it is a response shaped by context, past experiences, and unmet needs such as recognition, belonging, or agency. When leaders interpret complaint only as negativity, they risk silencing the very signals that reveal what people care about. By seeing complaints as expressions of care in disguise, leaders can move beyond irritation and instead use inquiry to uncover underlying concerns, redirect energy, and invite ownership. In this way, what begins as frustration can become the raw material for contribution and engagement.
> Complaining is not a character flaw
Sometimes it is. I was complaining a lot, but then someone had enough and explained to me that it isn't productive (complaining about every minor annoyance) and makes people not like me. Now I'm not complaining so much, only when I know how to change something or that it really needs to be changed. My life got a little better.
I'm not making a claim one way or another. I merely quoted the article in response to this claim by OP:
> Calling someone a complainer is corporate-speak for “they noticed the fire before leadership did.”
Just so I'm being crystal clear: I was pointing out that the article already addressed OP's statement.
I should also point out that your own comment doesn't refute the article. You just followed the article's advice for yourself rather than for a subordinate (which is fine).
Not a manager, I'm an IC.
I strongly disagree. Noticing the fires is often trivial. Complaining... It depends. Complaining constructively is fine. Complaining for the sake of complaining gets annoying very fast.
Also... People that spend a lot of time complaining are usually that aren't capable of making things happen anyway. They can only see the limitations.
I avoid those people I noticed they just bring down my mental focus.
There are plenty of people who complain because its baked into their personality. Those people can also work at a bad place and have a target rich environment so to speak.
The only sure fire way to avoid this label being applied unjustly is always bring solutions, not complaints. Document your solutions and let it rest if leadership doesn't agree.
This is typically what I see. There ARE chronically negative people, but more often “complainers” are the smart people who don’t rely on passive voice and jargon to get ahead or, having been ignored for years by the passive voice jargon cheerleaders while their concerns came true, are bitter and punching the clock.
Most of the time, complainers are a exhibiting a personality trait (or learned behavior as the article says); let's call those "unserious complainers". Some of the time (maybe 10% IME), the person complaining knows how to fix a problem, and is confused why no one is taking them or their suggestion seriously. It could be that the problem has existed for so long that the team has a cognitive blindness, or the team is swamped and has no capacity to think strategically.
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.
That's a great call but it should be paired with a promise: you present your great plan and then we'll put it to a vote. Otherwise you are just trying to get rid of them with busywork.
I've found that it's enough to just widely circulate it. As you point out, it's important to have some guarantee, so that the writing seems worth it.
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.
Vote? By the same people who created this mess in the first place?
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.
Well, that's part of politics. To get people on board the complainer will then have to try to build some consensus. If you start out from the premise that the vote would be turned against him then he should simply leave for a company that is worthy of his talents instead.
Objectivity in tech is more often than not in the eye of the beholder.
I think many long-time managers can recall some time were they really just put up busywork for them to not have to deal with that team member. It's not the best solution but sometimes it eases political conflicts.
I wouldn't recommend this. As I mentioned in a reply to a different post: A good idea, widely visible, must be addressed by leadership. Failing to do so makes you look incompetent as a leader. That doesn't mean it has be implemented immediately, but it needs to be referenced in the larger plan, along with a rationale.
I think that's unfair.
> Some of the time (maybe 10% IME), the person complaining knows how to fix a problem,
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.
Reality check.
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)
> A good way to partition the complainers into serious and unserious groups is to ask for a written plan
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.
As an obscure stand-up comedian once said, "initiative has to be punished with following it up".
There's rude, but precise Russian saying: "Initiative f*ks the initiator". This approach is a good way to ensure that there will not be initiative people in the team.
Yeah, that's a later vulgarization of what Zhvanetsky said.
> Complaints slow execution.
Not everything needs to be done yesterday. I've "executed" plans where leadership basically flips flops on their position. The team started putting all these hare brained ideas behind feature flags.
Wish we had this complaining guy.
I once worked for a small consultancy which did business by fishing for contracts, then doing the absolute to-the-letter minimum to fulfill them, irrespective of damage to the customer’s business or the company reputation. We would deliver working software that was absolutely awful to actually use for anything.
Often, clients would literally tell us to f*ck off when they realized we would not do anything that wasn’t in the contract verbatim, no matter how trivial.
To me, it was insanity. I would have preferred actually solving customer issues in a partnership fashion, and day-to-day work was nightmarish due to the constant conflict of values. Raising an issue about this got me branded a complainer.
The company slowly gathered enough references to attract some bigger clients (realistically: via backroom deals and kickbacks) and was eventually acquired, and some time later the executives were politely told to pack their things and get out.
They got what they wanted: a hefty paycheck and a load of shares from the acquiring company. The entire company was an acquisition scam from the get-go.
Depends on what they are complaining about and how they are doing it. In general, I would ask them how they would fix the problems they're complaining about. The first two steps to fixing any problem are to identify any analyze it. This might be their (unideal) way of doing that.
Many years ago in my software engineering course, my professor said that he would add to Fred Brooks' concept of a "surgical team" and said that he found that many successful engineering teams had a "team mother": the person that helped quell disagreements, remembered birthdays, cheered the successes no matter how small, kept tabs on how folks were doing emotionally, etc. Years later in my professional career, I found this to be true and met a few people like this on my teams -- not the best engineers, but additive to a great team.
I think that successful teams may have a place for a "team canary" (?): someone that is going to speak up about points of friction where most others might just end up with apathy and learn to deal with the inefficiency or friction (a "that's just how it is" attitude). Sometimes, complaints are a sign of genuine friction. Complainer may not feel like they have the authority/allotted bandwidth to remove the point of friction. When this happens, give this person some ownership of the friction points and see what happens.
I had worked with a guy which is smart, or at least persuasive, since him was hired somehow. He after started working with the team, him complaining about the project proposal, about the bad code decisions and had serious discussions with the product owner. After I talked with the PO, I opened a meeting with the complainer to extend my hand and say that I was opened to listen, him thanks me but preferred to stay a little away. The CTO proposed that since him spotted a bad code (it really was), him had time to analyze better and fix! In the end him lost 2 or 3 weeks fixing the code, wasn't able to finish and request resignation directly to the HR with the reason that the team and the project was bad, probably criticized the CTO. I had to take the code him left and finish the fix!
I think some of the most important problems get hidden if there is a culture where you expected to also want a specific solution before you complain. People avoid reporting difficult, complex problems without obvious solutions. Maybe they just see somethings as "the way things are" at that org or that leadership doesn't want to hear their needs.
Better to have a free, easy ability to complain about things, and if there is a good manager hanging around somewhere, they can synthesize the complaints and discover if there are solutions possible at the org level, which individual contributors might not know about or even be functionally able to own.
I see raising issues in a postmortem or retro different from complaining, but I generally agree.
For most practical problems, the answer is usually, "well, it depends. There are no clear solutions, only tradeoffs"
>The project plan is flawed. The deadlines are unrealistic. Leadership is out of touch.
Fascinating examples. I have never in my professional career heard anybody refer to these as "complaining". "Complaints", yes, but in English that has does not have the same connotation.
I scanned the article to see if "check whether any of their compaints are valid" but didn't see it anywhere. Sometimes maybe the person complaining might be right..
Unproductive complaints are... frustrating if you're on the receiving end of them, because they are basically (and unproductively) asking for help / solutions. But if it's just complaints, they also have the impression that the problem is not in their "sphere of influence"; coffee, for example, is usually handled by a facilities department. It's easy to complain about coffee to your boss, but it's confrontational if you actually pull the issue into your sphere of influence and go to the facilities department to complain.
It opens you up to vulnerability. You speak to people you don't usually speak to; you get confronted with the realities of that particular issue; office coffee for example is often a factor of budget vs cost, long-term supply and support contracts with coffee machine companies, and of course personal taste. Are you going to take on some responsibility for all that?
Of course, the other part is that you get hired for one job, stepping outside of that role to pursue something not directly impacting said job is often frowned upon. I say often because it's a bit of both, the best people will take on more and different things than what they were hired for.
Anyway. Complainers can / should get a training about "circle of influence/control", also because I doubt that work stuff is the only thing going on in their life, it can help them outside of work too. Knowing what you can change and what is outside of your control is great for your peace of mind and general attitude.
Are they just right and your timelines are wrong? Have you considered they have a valid point and are not a boot licker so willing to speak up?
The article really does a great job of setting up Survivorship Bias and then completely drops the ball.
Of course chronic complainers complain about stuff out of their control. They've fixed (at least in thier eyes) the items within their control. Asking them "what would they do" is but itself entirely ineffective unless anybody is going to act on it.
> Example: A team member repeatedly complains about timelines. Each time, the manager extends them. Soon, complaining becomes the default negotiation strategy.
Well, are the timelines too short? Is the team member complaining, or are they pointing out actual problems with the proposed timeline? And if the complaining gets the timeline extended to something reasonable, is there a problem with it being a negotiation tactic if it works?
> Learned helplessness: complaint as despair
> Leadership move: Restore agency through small wins.
This feels like when we'd let our five year old pick out what clothes she wanted to wear. Shouldn't the leadership move here be to try to solve the source of the despair?
This article focuses on dealing with the team member, and not the sources of the complaints. Sure, some people are just negative downers. But the first three examples on the page seem like actual external problems that the complainers are noticing and voicing concern about.
(And if you think it's bad to have complainers, wait until the complainers realize that no change is forthcoming, and either stop engaging at all, or go find work somewhere better.)
It seems as if the leadership in this situation hasn't even considered that they may be in the wrong and the points brought up maybe valid. So many teams set unrealistic deadlines or expectations based on dates plucked from the air and then wonder why work can't be completed on time.
For wathever reason, some people are just better at analysing complex situations, systems and outcomes.
So when a proposal is tabled, they will point out non obvious shortcomings and unintended concequences.
This is not 'complaining'.
Neither does this mean you immediatly have to keel over and ditch the plan. Plenty of times something can succeed against all odds.
But smart management will take into account the information provided, rather tjan labeling it as something to ignore without furter thought.
How does this font achieve the awful "shifting baseline" effect?
I assume that it is using a ton of ligatures, because consecutive letters always look different, but is that the only thing going on or is there something even more pernicious happening?
The one time I visited Google for a round of interviews, they assigned the complainer to take interviewees to lunch. It was enough to keep any interest I had in Google at bay forever.
Sketchnote Bold is the new Comic Sans!
(Not complaining, just observing. I shipped a top selling title that used Comic Sans exclusively!)
https://www.mcsweeneys.net/articles/im-comic-sans-asshole
https://news.ycombinator.com/item?id=11466122
That first link is on point in calling out "uptight armchair typographer cock-hats."
Comic Sans' only sin was being such a good font that it became "too popular".
Really, Helvetica and Times Roman should get at least as much criticism, but they get a pass for being suitably boring.
In my experience, people complain because they don't feel heard or they feel ignored (different feelings). Some people are also wired to complain; it's therapeutic to them. Both are coachable.
That font!
I guess that the person who complained that it is hard to read was treated as an issue and told they are slowing the execution.
That enormous sticky header!
Not comic sans at least.
Slightly OT but the font on that site is terrific. I don’t think I’ve ever seen something cursive (ish) that’s so legible.
> Why people complain: Psychological lenses
They left off one critical reason:
The person is a problem solver and is correct
Am I the only one who doesn’t care if the team has one individual with such traits? Like, if it slows down execution, well, I’m not into squeezing the last drop of speed of everyone. Also, people like that always give you the chance to show how good you are (supposedly): you can support them with potential fixes, you can support the team by saying perhaps that the complaint is not a big deal because data says so, whatever.
It’s like those people who are racist: they always make me feel better with myself because I don’t hold such beliefs. If everyone would be a saint, I would feel a bit down (because I’m not one).
It's fine if you can ignore them and don't have to work with them. If you do it's really draining. Constant negativity is not fun to be around.
I have only worked with one person in my life who was really like this though, so maybe you're just lucky and haven't experienced a truly committed negative Nancy.
[flagged]