▲ | giantg2 3 days ago | |||||||
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. | ||||||||
▲ | CharlieDigital 3 days ago | parent | next [-] | |||||||
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. | ||||||||
▲ | brunoarueira 3 days ago | parent | prev | next [-] | |||||||
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! | ||||||||
▲ | mnhnthrow34 3 days ago | parent | prev | next [-] | |||||||
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. | ||||||||
| ||||||||
▲ | mcny 3 days ago | parent | prev [-] | |||||||
For most practical problems, the answer is usually, "well, it depends. There are no clear solutions, only tradeoffs" |