In some companies I’ve worked for, we’ve found ways of running meetings that encouraged contributing information that is considered an attack in many other companies. The particular context was code reviews, but we did them often enough that the same attitude could be seen in other design discussions. The attitude we taught the code’s presenter to have was appreciation for the comments, suggestions, and actual bugs found. The catechism we used to close code reviews was that someone would ask the presenter whether the meeting had been valuable, and the appropriate response was always “yes”. The presenter could find different things to say about the value contributed by the attendees, but that catechism reinforces the point of view that improving the code is worth the time spent by the reviewers. As people get better at reviewing and being reviewed in the proper spirit, everyone who worked with us seemed to learn that finding fault with the code and explaining the problem clearly helped the company produce better products.
Once the engineers had learned how to provide constructive criticism, and others in the company learned to understand the spirit in which it was intended, it was easier to present disagreement on other subjects without needing to disagree at the end.
In some companies I’ve worked for, we’ve found ways of running meetings that encouraged contributing information that is considered an attack in many other companies. The particular context was code reviews, but we did them often enough that the same attitude could be seen in other design discussions. The attitude we taught the code’s presenter to have was appreciation for the comments, suggestions, and actual bugs found. The catechism we used to close code reviews was that someone would ask the presenter whether the meeting had been valuable, and the appropriate response was always “yes”. The presenter could find different things to say about the value contributed by the attendees, but that catechism reinforces the point of view that improving the code is worth the time spent by the reviewers. As people get better at reviewing and being reviewed in the proper spirit, everyone who worked with us seemed to learn that finding fault with the code and explaining the problem clearly helped the company produce better products.
Once the engineers had learned how to provide constructive criticism, and others in the company learned to understand the spirit in which it was intended, it was easier to present disagreement on other subjects without needing to disagree at the end.