Mark Needham

Thoughts on Software Development

Archive for the ‘Feedback’ tag

Feedback: Reacting immediately

with one comment

I was recently reading an article written by Henry Winter where he mentioned some of the ideas that Sir ALex Ferguson has been covering in some interviews he’s been doing at Harvard and one bit stood out for me:

In a series of interviews in Harvard, Ferguson debated dealing with “fragile” egos in the dressing room, the power of the two simple words “well done” in motivating individuals and the importance of criticising players’ mistakes immediately after the match and then moving on.

I’ve written previously about giving feedback and I think we don’t place enough emphasis on how useful it is to give any feedback close to the time of the event.

My former colleague Ryan Greenhall was particularly good at noticing situations where timely feedback was required and I hadn’t realised how much of an impact doing that had.

As we as the immediate benefit of the event being fresh in people’s minds when they’re talking about it we get an added benefit as well.

The more time that we leave between an event happening and reflecting on it, the more time there is for us to invent a story about what happened that helps to explain it.

In the story we create in our mind we’ll often associate negative traits/motives to the other person and exaggerate the importance of what happened until it doesn’t resemble what actually happened any more.

I tended to veer away from addressing things like this immediately because I thought it seemed like overreacting to believe that it was worth having a conversation but it now seems worthwhile.

In the worst case you just discover there was nothing to reflect on and in the best case you resolve any issues at the source.

Written by Mark Needham

May 23rd, 2013 at 10:43 pm

Posted in Feedback

Tagged with

Feedback: In public

with 2 comments

One of the areas that I covered during a session I ran at XP 2011 on making feedback work in teams was the idea of giving feedback in public.

The general consensus seems to be that giving feedback in public isn’t a good idea and it’d much more effective to give that feedback privately.

I think this is a good rule of thumb and my observations are that feedback given in public tends to not be given in a very constructive manner and therefore leads to a defensive response from the recipient.


On the other hand if it’s done in quite an informal joke-y way then I think it’s less of a problem.

On the last team that I worked on we created some ‘pillars’ for our team which contained some choice phrases that we used to shout across the room at each other whenever someone wasn’t displaying one of them.

I don’t remember anyone reacting in a defensive way to having someone quoting one of the pillars and it actually seemed to act as a nice reminder that they’d lost focus on their work, were taking things too seriously or something else.

The other situation where I don’t know that it needs to be completely private is when there’s a lot of trust between the people in a group and there’s no repercussions from any of the feedback being exchanged.

For example I wrote last year about how Christian, Dermot and I had done a feedback session with all 3 of us in the room, each giving feedback to the other two.

I think the trust thing is important in that situation because if there was someone in management looking on the discussion as part of a performance review then it could quickly become a witch hunt against a person.

Written by Mark Needham

May 11th, 2011 at 12:12 pm

Posted in Feedback

Tagged with

Feedback: Easing in

without comments

One of the most common techniques of feedback which I’ve come across is one that William Noonan describes in ‘Discussing the Undiscussable‘ as easing in.

From the book:

Easing in is a skilful strategy whereby I try to get the other person to come round to my point of view without my stating it directly.

From my experience we’ll try to do this because giving our point of view could lead to an awkward conversation so we’d rather they express our opinion for us instead.

Amusingly I managed to create an example of easing in while showing a colleague (colleague 1) the chapter about easing in!

We’d been involved in a conversation the previous evening with one other colleague (colleague 2) where colleague 1 was asking leading questions to colleague 2 in order to get colleague 2 to confirm an observation that colleague 1 had made.

It didn’t really work because colleague 2 had a different opinion of the situation so the conversation eventually petered out.

The next day I was reading the chapter on ‘easing in’ and showed it to colleague 1 expecting that they would immediately recognise what I was talking about.

Unfortunately that’s not what happened and my colleague just read the part I pointed out and then handed the book back without any comment.

Having realised what I’d done I went and spoke with them about 20 minutes later and described how I thought the chapter had some relevance to the conversation of the previous evening.

We then had the chance to discuss the idea of easing in a bit more and now both of us are more aware of the concept and try to avoid doing so when giving each other feedback.

Written by Mark Needham

April 13th, 2011 at 2:33 am

Posted in Feedback

Tagged with

Feedback: Making the request specific

without comments

My colleagues in Pune have been collecting feedback over the past week as part of the quarterly feedback cycle and it’s got me thinking about the way that people ask for the feedback.

The most popular way is to ask for general feedback which answers questions like this:

  • What are the things that the individual has done well?
  • What are the things that the individual has not done well and/or needs more focus/improvement?
  • Suggestions for future directions.

The problem I have with this is that it’s extremely generic and it’s much easier to drift towards giving evaluative feedback where you judge the person against some perception of what they ‘should’ be doing.

On the other hand I find it’s much easier to give people feedback if I know them a bit more and have some rough idea of what exactly they want to achieve or which things they are particularly passionate about.

Knowing this information helps to put us in a more supportive mindset and I feel the feedback you come up with in this mindset is more likely to be helpful to the person and will help them get better.

As I mentioned earlier a lot of the time the request for feedback will be general so we’ll need to ask questions to try and elicit the goal the person is currently trying to achieve:

Some examples of goals that I’ve heard about could be:

  • Learning how to drive pieces of functionality to completion
  • Learning a language/framework
  • Learning how to effectively lead a team
  • Learning how to take more responsibility for the success of a team

Some of these are still a bit general so we can then ask further questions to understand what the person has tried already around this and then if possible give some suggestions on approaches that might work better.

That’s what works for me anyway. YMMV.

Written by Mark Needham

February 6th, 2011 at 3:47 pm

Posted in Feedback

Tagged with

Listening to feedback mechanisms

without comments

In Growing Object Oriented Software the authors talk about the value of listening to our tests to understand potential problems with our code and I’ve started to notice recently that there are implicit feedback mechanisms dotted around at a higher level which we can also listen to.

A couple of examples come to mind:

Nothing to show in the showcase

I’ve worked on a couple of projects where we’ve got to the end of the iteration and realised that we don’t actually have anything tangible to show the product owner.

This tends to be because we’ve spent the majority of our time working on ‘technical stories’ which typically have no visible output.

This may be as a result of horizontal slicing of work rather than vertical slicing but what it essentially means is that the work you’ve done has no immediate value to anyone.

Sometimes there are technical aspects to a solution which have a lot of unknowns and combining those with a vertically sliced story would mean that the story becomes too big to fit in an iteration.

From my experience a way around this which has worked well before is to run a spike/experiment card where we work out all the technical details/gotchas and setup any necessary ‘framework’ and then have the other vertically sliced chunks of work plug into this.

Having said that I’m no expert in breaking down work into manageable chunks so if anyone has any other ideas I’d be interested in hearing about those.

Boring meetings

The typical response if someone complains of being bored in a meeting or walks out of a meeting is that they should deal with it but that response doesn’t help us that much.

I think if people are bored then it’s an indication that the meeting isn’t particularly interactive/inclusive or that the person shouldn’t be in the meeting.

We can try to resolve that first point by having meetings which are designed more as a discussion/learning forum rather than a brain dump session by one person to the group.

This encourages more of a pull approach over a push one and seems to be more effective at keeping people’s attention as long as the topic of the discussion is actually relevant to them.

Frequently it seems that a more effective approach would be to have fewer people involved in a meeting and have one of the participants quickly summarise what happened for the rest of the team.

Written by Mark Needham

January 21st, 2011 at 3:46 am

Posted in Feedback

Tagged with

Feedback loops: Overcompensating

without comments

One of the things that I’ve noticed while working with various colleagues over the last few years is that the more experienced ones are much more skilled at making slight adjustments to their approach based on feedback that they receive from the environment.

I’ve been reading a couple of books on systems thinking over the last few months and one of the takeaways for me has been that we need to be careful when reacting to feedback we get from a system to ensure that we don’t over compensate and end up creating a new problem for ourselves instead.

The idea of over compensating is also know as ‘chasing the gauges‘ in the airline business where it describes the following situation:

When you roll on aircraft left or right. pitch it up or down, change the throttle or the brakes,t tokes time for the plane to “settle out.

Good pilots fly by making a change, then waiting a couple of seconds to see the results. If you don’t you’ll just “chase gauges” that are themselves still changing.

In terms of software development a mistake that I’ve made before is to see something go ‘wrong’ in a situation and then come up with a ‘solution’ to that which effectively means doing something completely different to what we’re doing now.

We had example of this on a project I worked on where we ended up doing a lot of re-work in one iteration because several people were working in a similar part of the code base and ended up trampling all over each other.

In the next iteration we had some stories which would touch a similar part of the code base and I thought it would make sense to split the work by front and back end rather than having each pair work on one story.

While this removed the re-work problem the unfortunate side effect was that it meant we had no visibility about either of the stories until one day before the end of the iteration.

A colleague pointed out that it might have been more effective to wait for a pattern to emerge before trying to make a correction.

In this case the solution probably didn’t need to be as dramatic as ensuring that people didn’t touch the same areas of the code base.

A more effective approach might have been to just have the pairs sitting next to each other and ensure that they communicated which bits of the code they were changing.

Tying that in with frequent commits would probably have removed the problem of re-work and still allowed us to keep the visibility of individual stories.

It takes a bit more discipline to not overcompensate and I think in a way it goes against the human instinct to try and fix a problem as soon as we see it.

I’m trying to move more towards the following approach:

  • Wait and watch situations for longer before taking action
  • Ensure any action isn’t too dramatic i.e. small steps
  • Watch to see how the system responds to the change
  • Try something else if necessary

It is difficult though and I certainly make a lot of mistakes.

Written by Mark Needham

October 24th, 2010 at 8:39 am

Posted in Systems Thinking

Tagged with

Feedback, the environment and other people

without comments

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.

Written by Mark Needham

July 20th, 2010 at 5:30 pm

Posted in Feedback

Tagged with

Group feedback

with 3 comments

On an internal mailing list my colleague David Pattinson recently described a feedback approach he’d used on a project where everyone on the team went into a room and they took turns giving direct feedback to each person.


Since we were finishing the project that we’ve been working on for the past few months, Christian, Dermot and I decided to give it a try last week.

One thing to note is that this feedback wasn’t linked to any performance review, it was just between the 3 of us to allow us to find ways that we can be more effective on projects that we work on in the future.

Much like David I found this approach to feedback to be the most useful that I’ve seen in nearly 4 years working at ThoughtWorks.

We took it in turns to receive feedback from the other two guys and each person first explained what they wanted the feedback to focus on.

I’ve participated in face to face feedback before but what I liked better about this approach was that someone could make an observation about something that you’d done and then that became a discussion point between the three of us.

In general it seems to promote a more conversational style of feedback than often seems to happen when it’s just one on one.

I think it was really good being able to get two opinions on each behaviour as people often have different takes on the same situation. Taking both viewpoints together along with your own seemed to make it easier to narrow in on the behaviour and see how it could be improved.

When giving feedback it was useful to have someone else doing so at the same time as it helped remind me about things that I’d forgotten about.

I still need to improve the way I give and receive feedback – Pat Kua details a series of tips for extracting behaviours from the actual feedback that people give and has several other posts on the topic. This is the best resource that I’ve come across but I’d be interested in knowing of any others.

The key thing that I’ve noticed when giving feedback is to only point out your observation and the impact it had on you rather than making assumptions about why the person might have done that – you’re nearly always wrong!

Overall though I found the group feedback approach to be useful and it’s something I’ll look to encourage on projects I work on in the future although I’m unsure how well it would scale in a larger team.

Photo taken from AmyZZZ1’s Flickr stream under the Creative Commons licence.

Written by Mark Needham

July 7th, 2010 at 12:17 am

Posted in Feedback

Tagged with

Feedback: Positive Reinforcement/Change yourself first

without comments

One of the more interesting concepts used on the NLP course that I did last year was the idea of only giving positive feedback to people.

The thinking behind the theory (which I think comes from Robert Dilts, one of the early thinkers behind NLP) is that people know what they are doing wrong and already beat themselves up about it; therefore there is no point you mentioning it as well.

I was initially sceptical about this approach as it seemed a bit too idealistic for my cynical mind. I found it extremely difficult to start with and didn’t give any feedback to anyone for quite a few sessions. Eventually though something clicked for me and by the end of the 18 day course I feel I did gain a greater respect for and recognition of the talents that other people on the course had. The need to focus only on the positive actually seems to drive the mind to see more in this area than it otherwise would.

Although noone likes it when they are criticised, I think there are some occasions when someone criticising you can prove to be extremely motivational. This basically involves them completely writing you off and you then being determined to prove them wrong. For example at school I was told that I would definitely fail the Pure Maths modules of my A Level Maths course. Completely unimpressed with this verdict I persevered with it for months eventually scoring 85%. Job done.

I think sometimes when giving critical feedback it can say more about you than it does about the person you are giving it to, and this is where it’s vital to step back and think why you are giving the feedback.

I find at least for myself the tendency is to want to point out things people do that annoy me, which in effect is me trying to make the person more like myself. Steve Pavlina suggests that the things we hate the most in other people are the things we actually hate in ourselves. Therefore his suggestion was if you find something someone else does annoying, first look at yourself and try and improve yourself in this area.

I’m not sure if I totally subscribe to why this approach would work but I definitely agree that it is way easier to change yourself than it is to change someone else.

Similar articles:

Written by Mark

February 12th, 2008 at 12:01 am

Posted in Feedback

Tagged with , , ,

Giving effective feedback

with 2 comments

One of the most interesting things I have discovered since starting at ThoughtWorks earlier this month is the emphasis that is placed on giving feedback.

The first lesson we were taught about giving feedback was that it could be one of two types. Either it should Strengthen Confidence or Increase Effectiveness.

In Layman’s term that means that if you want to make a positive comment about somebody’s contribution then you should make reference to something specific that you believe they have done well so that they can continue doing it. Equally if you believe there is an area that they could improve it, a specific example of this behaviour/fault should be noted along with a suggestion for how they can improve.

As a member of Toastmasters since January I was already used to this concept of feedback and there are certainly parallels in the feedback system encouraged at Toastmasters and that used at ThoughtWorks.

Although Toastmasters do not define types of feedback, there is an expectation that evaluators will apply themselves in a certain manner when carrying out their job.

One of the things which is frowned upon is known as ‘whitewashing’. This is where an evaluator would say that a speaker was ‘brilliant’ or give a summary just using complementary adjectives. Although the speaker may well be flattered, it does not really tell them anything or leave room for improvement. The use of the word ‘brilliant’ or ‘superb’ is only the perception of the person using it, and the failure to make use of the word with regards to a specific behaviour or action means that it is rendered meaningless.

Equally when the evaluator believes there is an area that the speaker can improve in they should make a reference to the specific negative behaviour or action so that the speaker can recall their mistake and go about making the improvement. When giving feedback it is very poor practice to attribute your own feelings to the speaker – you are giving them control over something which they do not have control over! For example, if an evaluator were to say: ‘I felt bored listening to your speech, you should make the next speech more interesting’. In this case the evaluator is giving the speaker the power to make them feel bored. It is ridiculous to let someone have that amount of control over you and if we consider that another person listening to the same speech may have felt really engaged, a property of the speech cannot be that it was ‘boring’.

This is very similar to the way that ThoughtWorkers are expected to give feedback, although it is also emphasised that when giving feedback one should speak only for themselves, and not try and speak for a group of people. Doing this would assume that mind reading is possible and as far as I’m aware this feat has yet to be achieved. An example of committing this mistake would be to say something along the lines of: ‘It would be better for us if you could do x’. In this case ‘us’ is not defined and it is unlikely that one person can speak precisely of the feelings of other people.

This concept is very similar to that of Generalisation in the NLP Meta Model, which states the following:

“Generalization is the process by which elements or pieces of a person’s model become detached from their original experience and come to represent the entire category of which the experience is an example.”

This is an area that I am actually working on myself, and I am finding it very difficult to speak only for myself because I’m so used to generalising! Of course there are still times when generalisation is vital, and we would find it very difficult to live our daily lives without generalising on some things. Giving feedback, however, is one area where this ‘technique’ is counter productive.

Written by Mark

September 2nd, 2006 at 3:07 am