It’s been a long time since I’ve written about what you could call the “Rogues Gallery” of Software Development Teams.
We have the Nitpicker, the Backbencher and the Doomsayer but today we are introducing the legend themselves – the Whiner.
It’s super easy to know who Whiner is…
- Whine about the requirements
- Whine about the codereview
- Whine about the unit tests
- Whine about the QA Plan
- Whine about the deployment taking too long
- Whine about the servers being too slow
We all whine about this, that or the other thing from time to time. Some days you have absolutely had enough and simply need to vent it out – i.e., beer o’clock. But what really turns someone into the Whiner of the team isn’t that they have these issues, isn’t that they have concerns over these issues, isn’t that they think there is a better way to do them. It’s that they never try to make it better, never try to fix it and most importantly feel the need to let it out based on the most important people in the room and/or the size of audience in the room.
That’s right – the whiner waits (in the grass?), for the moment when those of perceived power are present to really air their issues, instead of trying to discuss them with their Team Lead hoping “action will be taken” and/or they wait (again in the grass?) for a large meeting to happen and then they air the laundry right in front of everyone hoping to court public opinion.
The best way to help a Whiner? Get them involved, make them part of the solution, solicit their opinion and yes give them those meetings where the perceived power are present but also ensure that those that are directly affected (i.e., a Team Lead) are present. It’s not about top-down or bottom-up, it’s about all around.
