Non-Judgmental Communication
A while ago I published an article about non-violent communication. The concept has been introduced and championed by Marshall Rosenberg in his seminal book. As I received feedback from readers, some of the reactions could be summarized as follows: “What are you talking about? Which violence? Do you think we behave outright violently when we communicate at work?” I pondered that and came up with a bit reframed concept. While Marshall Rosenberg — who passed in 2015 at the age of 80 — was addressing the outright aggressive behavior — as in household abuse, gang violence, jail violence, etc. — we find ourselves in quite a different situation as software development professionals. We can not be violent per se; this is office, work, and yelling at someone, or using physical force — which would be perceived as the ultimate violence — is out of question, of course.
So, I’d like to provide a bit different highlight to the subject of non-violent communication in teams, replacing “non-violent” with non-judgmental. If we think about it, in the verbal form, what would the utter form of violence be, in a well-behaved social context? To me, this is accusation. For example, when a person in a team publicly blames another person for a failed release, saying: “It’s all your fault. You missed this thing in the code. You overlooked this bug. You’re the one to blame for this late release”. This is an utterly simplistic example, of course, just for the sake of example. From what I see, the culture in most software development teams does not allow people to be that bluntly accusing. We are all human, and we know that people must have their reasons for the delays, or problems with code, etc.
The next gradation of violence in teams would be judgement. Someone might ask, why on Earth can judgement be a form of violence? Let’s look deeper into that. The most common example is labelling a thing someone else has done as “good” or “bad”. Especially when this judgement comes from someone in a position of a formal or an informal authority. Like, your code is “good”, or your design is “bad”. Think about it: which value the “good-bad” modifying descriptors would bring to what the team is trying to do? The descriptors represent a subjective judgement and give no suggestion of a way out. Doomed. However, what we are looking for when we work together as a team? We look for the ways to improve. To keep our colleagues encouraged to perform at their top ability. To me, the “good-bad” judgement ultimately kills the spirit of friendly feedback and improvement. Okay, you say this design is bad. But have you noticed that this person is truly searching for a sweet spot? That this person genuinely cares? That he or she wants to come up with a workable solution?
Now — someone might ask — why would it sound so upsetting to the others when someone else gets the “this-one-is-the-best” score? First of all, everyone invests their best effort into what they do. The judgement given to only one out of many might sound especially painful to those others, as they would feel underappreciated for their input. They would then project their feeling of being underappreciated to this “good” praise that goes to another bird in the flock. Someone might call this nonsense, but it’s as serious as it can get, for the team culture.
The subject of judgments can be looked at from a yet another perspective: the Dunning-Krueger effect. The incompetent rate themselves highly just because they’re unable to recognize their faults, whereas the competent are too harsh on themselves. In the context of teamwork, the competent professionals who suffer from this bias might get completely unenthusiastic about their abilities, which in the end would mean losing out for the whole team, as they wouldn’t be able to capitalize on the skills of the competent ones. On the other hand, we tend to be very condescending to those “incompetent”. If someone does a foolish thing, and then goes on how great he/she is, we’d somehow rather laugh it all off, whereas a harsh judgement could be a proper response in this particular case. It’s a very fine line, and certain psychological skills are required to keep it. Remember the Emperor’s New Clothes tale, the one I keep referring to in my articles? No one dared say that the emperor just had no clothes on, until a little boy voiced the truth. Actually, there’s another human reason for this loose attitude. Subconsciously, we might feel that we are superior to the incompetent ones, that’s why we “let them live”, just to make fun out of them, keeping their heightened false beliefs of their abilities. Here, not a laugh but a shock treatment would be of more help. Like: “Dude, can’t you see that what you say is absolutely clueless?” This does sound like a harsh judgement, but it will work like a sobering shower for this incompetent person, eventually helping them form a realistic understanding of their abilities and improve.
“The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts.” — Bertrand Russell
The benefits of non-judgmental communication are enormous, and team culture does not emerge overnight. It builds up with time. If you’re looking to foster the non-judgmental culture, watch out for judgement when giving feedback about someone’s performance. Note if you’re inclined to using “good” or “bad”, and consciously replace these with “interesting”, or “smart thinking behind this code”, or “I can see you’ve put much effort in this design”. If you need this person to improve their work — to make the code or design more compliant with some objectives, etc. —offer them advice, not judgement. Creative people are usually very sensitive. They need to be treated with kid gloves. To get the best of their abilities, acknowledge their input.
These are all very subtle things. But devil is in the details, and software development is more about people than anything else. I hope that my articles contribute to this awareness.
This story was updated and re-written from one of my earlier articles.
