The other day I was speaking to a friend about having conversations with colleauges when you’re unhappy with something they’ve done. It’s important to be clear, and it’s important be objective. I said that after recapping the scene, one of things I sometimes do is to explain what they did and explain how it differed from what I would have expected.
As I said this, I realised this was very much how one writes a good bug report. The standard format of this is: here’s my setup and what I was doing; this what I did; this what I expected to happen.
Perhaps this isn’t too surprising. We should most certainly not treat people like machines, but when someone does something which is problematic we are sort-of filing a bug report for a human: “You did this, which is a problem. Could you not do that in future, please?”
A more common (and humane) format for feedback conversations is situation-behaviour-impact: recap the situation; explain what happened; then explain what effect this had. The “actual vs expected” comparison is one way of doing the “explain what happened” part. But when speaking to people, the impact part is really important. It makes explicit why the behviour wasn’t good. Explaining the impact also forces us to be clear to ourselves why we’re disappointed (and sometimes we have to confront our biases when doing this; when reflecting, we may find that the actual problem is not as great as we first felt).
That said, explaining the impact of a bug is also helpful, because it helps the developers prioritise it appropriately… just as we hope our colleague will prioritise correcting their behaviour.
Human beings are most definitely not machines. But when trying to get the best out of both it’s important that we structure our communication effectively.
niksilver.com 