Something that I’ve noticed over the last few years is that when people give feedback to each other there is often an over emphasis on the individual and less attention paid to the environment in which they were working.
I covered this a bit in a blog post I wrote about a year ago titled ‘Challenging projects and the Kubler Ross Grief Cycle‘ which I converted into a presentation that I gave at XP2010 in June. In the presentation I spoke more about the way the environment can impact the way we behave.
One of the points I made was that the environment has a very big impact on the way that people act.
After one particular project that I worked on Lindy, who was running our performance review process, pointed out that everyone who had worked on that project had the exact same feedback and that it said way more about the environment that project was operating in than it did about the individuals.
I’m not quite sure where we draw the line between what an individual can reasonably be said to have control over and what is difficult for them to influence because of the environment. Perhaps there doesn’t need to be a line.
In Crucial Confrontations the authors talk about there being three sources of influence – self, others and things – or personal, social and structural as on the diagram on the right!
As I understand it the authors suggest that we start looking at the individual in terms of their own motivation and ability first and then work our way down through the others.
Although this model is intended for conversations where one person is confronting the other for not behaving how they expected in some way, it seems like a reasonable model to follow for general feedback as well.
As assumptions seem to drift into our perceptions of what other people are doing often in an unfavourable way the point of following the model is that it will help draw out these assumptions and help us to see exactly why someone acted the way they did.
A fairly common example is where a tech lead just give instructions to their team to do something without explaining why they want them to do that.
They assume that the team already know why – assuming that the team has the information, context and experience of making this type of decision that they do. The team assumes that the tech lead isn’t telling them because he/she just wants them to follow orders.
Neither of these assumptions are particularly useful and it seems much more effective to talk through something with the other person based only on what we’ve observed so that we can see whether there is something for them to improve or if we need to try and improve the environment in some way.
Easier said than done.