Depends on the organization's culture - depends on the individual - depends on the topic.
Some cultures encourage honesty more than others. They invite positive, criticism to promote learning and growth.
Individuals differ in degrees of confidence and competence. Those secure in their knowledge and ability to argue their points share more openly than others. Of course, there are some who are mistaken in their self-perceptions and mistake mere verbosity for honest sharing.
At both cultural and individual levels, there may be some topics that are deemed to demand honesty and other for which honesty is relatively unknown if not downright taboo.
As an example, at the first code review meeting I attended at a new shop, I provided insight that a section of one of the other developer's code was dead - a conditional block that would never be active, due to an error in coding. In particular, it was one of my favorite nemeses, "var = literal" instead of "literal == var" - easy catch for me, because I ALWAYS look for it. It would have rejected by the interpreter, if the comparison order had been reversed. So, I commented on the specific error AND had a teaching moment to promote one of my pet practices. Everyone in the room, except the guy who was my team leader and had arranged my hire, was at least mildly astounded (my team leader just smiled - he knew what to expect based on our having worked together for a few years at another shop); the other devs in the meeting were inexperienced with REAL code reviews. Most of that staff was accustomed to discussing coding style, alternative naming conventions, competing flow options, e.g., {while} vs. {until} vs. {if}. Code reviews were almost a rubber-stamp exercise. These guys were not stupid - they were young and inexperienced, untrained in one the primary goals of code reviews...finding and killing bugs BEFORE they are promoted into a dev or test environment. Honesty required - and it demands that reviewers be kind and reviewees be trusting. The guy whose code I reviewed button-holed me after the meeting and thanked me both for the specific bug catch, the general rule about logical comparisons, and the eye-opening nature of REALLY having code reviewed.
In summary, honesty CAN be effective and desirable, but only if the culture supports it for the given topics, and the individuals involved are kind and trusting. Oh, and you have to express yourself intelligibly by other people's standards, but you already learned THAT one.
Man, that hit me like a truck. I've since changed my approach, and man... It's been night and day improvement.
So what was the change you give feedback that caused this improvement?
Dunja Radulov
Marketing and growth consultant. Previously Growth Manager at Hashnode
A formula that works pretty well for me is:
What do you think?
That keeps the feedback brief and you're open to hearing the other person out.
What is your new approach?