The intersection of technology and leadership

Category: Feedback (Page 3 of 4)

A Guide to Receiving Feedback Part IV: Apply It Immediately

A key principle to keep in mind when giving effective feedback is to do so in a timely manner. Feedback only helps the recipient if they have an opportunity to do something about it. It’s difficult to change a specific behaviour if a project’s finished or the feedback comes a year later.

If someone gives you the gift of feedback and you agree upon actions, seek the nearest opportunity to apply it. Applying the actions immediately reinforces the value of feedback. When the feedback donor sees a change in behaviour, they see that it helped the recipient become more effective. Applying it sooner than later creates opportunities for the donor to give new feedback, focused on strengthening confidence and encouraging more of the desired behaviours. More than helping the donor realise the value in their feedback, the agreed upon actions should help improve or continue the recipients’ effectiveness in what context they are working in.

Skiier Fallen OverAs an example, when you’re out skiing, applying actions from feedback will improve your effectiveness the most by applying it immediately. It may take some time to master it, to change conscious behaviour but it’s only useful if you do it while you’re on the slopes, not when you’re back from your skiing holiday.

Remember that not executing on actions immediately has other negative effects. Not doing anything about agreed upon actions sends a message that you don’t value the feedback, decreasing the likelihood the donor will give any feedback in the future (whether or not its focused on Strengthening Confidence or Improving Effectiveness). Not applying the actions immediately also makes it easier to forget what behaviour needs to change and it will be harder to get affirmation about if your effectiveness has improved.

Photo taken from Sunflower Dave’s Flickr stream under the Creative Commons licence

A Guide to Receiving Feedback Part III: Agree on Action

HandshakeThe biggest mistake when giving feedback is telling someone what to do (or what not to do). Ever been on the receiving end of feedback like that? Do you immediately recoil and feel yourself saying no? It’s natural because you don’t know how following their recommendation makes you more effective. When someone recommends a specific action, unwind the (ineffective) feedback to see how they ended at their recommendation. Find out what key behaviour triggered they observed and what impact it had. Here’s how you might do it:

Follow these steps:

  1. Acknowledge
  2. Establish what you’re about to do
  3. Ask for specific behaviour
  4. Ask for observed impact
  5. Generate alternative actions
  6. Agree on an action

Only after you both share the same context and background do you then want to move onto Agreeing on the Action. Asking someone to change their behaviour assumes it will fix the problem. Many times people suggest one thing not having the full context and actually, a better solution is something completely different.

Ensure that you both agree on the action because it will make the person receiving the feedback more effective, not because someone told them to.

Picture of handshake comes from Oooh.oooh’s flickr stream under the Creative Commons licence

A Guide to Receiving Feedback Part II: Observe First, Judge Later

SilentLet’s be honest. People aren’t used to hearing feedback, let alone listening out for characteristics of effective feedback. It’s easy to jump to feeling defensive and trying to justify everything and look for reasons why you behaved as you did. People with backgrounds in programming are also often quick to apply the labels: “Good” and “Bad”.

When receiving feedback, consciously slow down your reactions. Focus on understanding the situation, the facts. Then assess the impact. Avoid the temptation label the feedback as positive or negative, good or bad. Placing a value judgement immediately leads you to agreeing or disagreeing with it. Really listen to the feedback and confirm what you heard, first asking for the specific behaviour, followed by understanding how they perceive the impact.

Here’s an example:

Donor: “Last week I noticed you turning up for stand up three of out five days. I’m concerned because I think it indicates to other team members that their time is not valuable to them.”
Recipient: “You’re saying that I turned up late three out of five days?”
Donor: “Yes”
Recipient: “I only thought I was late for just one day. You’re also saying that my team mates are being affected by this? How are they expressing that their time is not valuable?”
Donor: “I’ve heard a few of them talk about if you’re not turning up on time, why should they?”
Recipient: “I had no idea about this”

The person giving the feedback will often give feedback that is ineffective, therefore as the recipient you may need to ask them questions to get back to the original observations. Focus on facts. Then focus on interpretative. Leave the action until last.

Donor: “You need to turn up on time for stand ups.”
Recipient: “It’s helpful for me to understand some specific examples. Have I not been turning up for stand ups on time?”
Donor: “No. You arrived late last week.”
Recipient: “I only thought I was late for just one day. Was I late more than that last week?”
Donor: “Yes. I thought you arrived late during stand up at least three times last week. It’s so annoying.”
Recipient: “I’m sorry to hear that you see it as annoying. It’d be helpful for me to understand why you see that as annoying.”
Donor: “It’s annoying because other team members have been complaining about if you’re not turning up, why should they.”
Recipient: “Ahh. So you’re saying that because I’m turned up late three times last week, then everyone else feels like they shouldn’t have to either.”
Donor: “Exactly.”

Whether or not a donor is giving you effective or ineffective feedback, they are trying to tell you something. Use the opportunity to listen to what they are trying to tell you, even if it is masked by emotion and suggested actions. Use the opportunity to uncover the elements of effective feedback. Avoid agreeing or disagreeing with a person immediately. Confirm what you are hearing. Uncover the facts and understand how they perceive the impact and both of you will understand what actions need to be taken and more importantly why.

Photo above taken from Borghetti’s flickr stream under the Creative Commons licence

A Guide to Receiving Feedback Part I: Ask for It

Asking For FeedbackI’m writing this guide to answer a question a trusted colleague asked me the other day. I think there are plenty of resources for how to give effective feedback (I’ve written a few myself) yet I can’t find as many about the other end, or how to go about receiving feedback. I’m planning on writing a series of these posts, so my first tip in this series is: Ask For Feedback.

I’m amazed at how many people go through life without asking for feedback. There are plenty of reasons why people don’t do so. Perhaps it’s because people are ineffective at giving feedback, perhaps people are fearful of the consequences it may have on their status, on their career, or their current position. Many organisations, teams and processes don’t really create a safe environment for people to receive effective feedback, only serving to fuel the cycle of not wanting to provide effective feedback. Poor HR processes tie performance evaluations to annual reviews that only occur once a year, adding to the vicious cycle of providing poor quality feedback.

Remember that effective feedback should be about Strengthening Confidence and Improving Effectiveness for the person receiving it. Anything else is ineffective.

The first step that you, as the person benefiting from the feedback, should do to break the cycle is simple; ask for it. Asking for feedback (particularly detached from performance evaluation cycles) starts to create a safe environment for the person giving feedback. It gives the donor permission to help you understand what things to continue doing (or do more of) and places where you might improve. You could start the conversation off like this:

“I value your opinions and I’d be interested in getting your feedback about how you think things are going. It would be helpful for me to understand specific examples focusing on behaviour where you can help me strengthen my confidence and improve my effectiveness.”

Make sure you give the person the opportunity to think about it:

“I’d like to get that feedback soon and would like to give you some time to think about it. Can we organise a time later in the week to cover this?”

Establish a time that works for the both of you – enough to let the donor collect their thoughts balanced against enough time for it to be relevant for the recipient. More importantly, ask for feedback frequently. Don’t wait until the end of a team, the end of a project or a whole year. You want feedback to be relevant and specific because relating feedback to recent events gives you the opportunity to apply it.

Photo above taken from GreyBlueSkies flickr stream under the Creative Commons licence

Reminder of a rule for Giving Feedback

A trusted colleague recently asked me for some feedback on their work. I gave them some honest feedback, including a strong suggestion they make some changes since there was a strong potential for offence. Surprisingly, they chose not to take my recommendation and never explained why they disregarded it or helped me to better understand the underlying context.

Although I’m not offended, I’d be lying if I said that I wasn’t a little bit upset. Reflecting on this situation, I reminded myself about one golden rule about giving feedbackyou need to be prepared for your feedback not to be accepted.

It’s the reverse of the what I find myself saying when giving advice on receiving feedbackit is okay to disagree with feedback someone gives you.

Run automated tests as often as possible

I’ve been working with a large scale legacy system (in the Michael Feathers’ sense). Strangely enough there are a small handful of tests, unfortunately most of them falling by the way side having not been added into an Continuous Integration process. Many of them no longer look relevant, others, unable to run without a specific person’s machine (due to configuration files or special databases). Others look like a mechanism for people to simply diagnose issues with plenty of tracing statements. All of this was an inevitable system without someone running all the tests all the time.

Any serious team serious about continuous integration will think hard about their development testing strategy, considering approaches that allow you to run tests all the time. The strategy needs to consider a good way of preventing side effects from other tests (global state, global configuration, or left over state in external resources) balancing out speed with good quality feedback. Staggering build processes into smaller chunks, such as using build pipelines are a great way of achieving this.

Please don’t let leave your tests to die a sad and lonely death. It will take discipline and effort to keep them running yet the results will often pay back for themselves very quickly on any system with a reasonable lifespan.

Facilitation Tool – ORID

Last year, Esther Derby and Jean Tabaka shared a model at the 2008 Retrospective Facilitator’s Gathering that I now think about all the time. Esther Derby and Diana Larsen used it as the base model to describe how to run retrospectives. It also got me thinking how it mirrored different models described by other facilitation approaches, negotiations strategies and advice on how to give effective feedback. Apparently this originated in the book, The Art of Focused Conversation.

The base model starts with the acronym ORID that means:

  • Objective – Focus on the facts, hard evidence data
  • Reflective – Focus on how that made people feel or other associations
  • Interpretive – Focus on the impact and significance
  • Decisive – Focus on next steps.

I thought it’d be useful to share this model with a wider audience, and I keep forgetting what the “I” specifically stood for, so I’m putting here so I can find it later.

More on how to apply this later.

Active Passive Load Balancer Configuration for HAProxy

It took me a while to understand the help for the configuration file for HAProxy, another software load balancer that runs on a number of *nix-based systems. Here’s the resulting file that we used to successfully test an active-passive machine configuration that someone will hopefully find useful one day.

global
    log     127.0.0.1 alert 
    log     127.0.0.1 alert debug
    maxconn 4096

defaults
    log        global
    mode       http
    option     httplog
    option     dontlognull
    option     redispatch
    retries    3
    maxconn    2000
    contimeout 5000
    clitimeout 50000
    srvtimeout 50000

####################################
#
#           loadbalancer
#         10.0.16.222:8555
#           /          \
#   webServerA         webServerB
# 10.0.5.91:8181     10.0.5.92:8181
#    (active)           (passive)
#
####################################

listen webfarm 10.0.16.222:8555
    mode    http
    stats   enable
    balance roundrobin
    option  httpclose
    option  forwardfor
    option  httplog
    option  httpchk    GET /someService/isAlive             
    server  webServerA 10.0.5.91:8181 check inter 5000 downinter 500    # active node
    server  webServerB 10.0.5.92:8181 check inter 5000 backup           # passive node

A guide for receiving feedback

I recently gave some advice on how to give feedback effectively and was asked to give some advice about receiving feedback. My guidelines for receiving feedback are pretty much based on understanding how to give effective feedback. Ola recently also shared his experiences with this.

Before I understanding how to receive feedback, it’s useful to recap some guidelines on how to give feedback:

  • Feedback should be specific. Talk about specific observations and impact of the behaviours exhibited during those observations.
  • Believe that someone was doing what they thought was correct at the time. (Akin to the Retrospective Prime Directive)
  • Feedback should be timely. Give it early and often as you see fit.
  • Feedback should be about both strengthening confidence and improving effectiveness. It shouldn’t be about making someone feel bad about themselves.
  • The focus of feedback should be about behaviours, not perceived values or attitudes.

When you receive feedback, be prepared not to receive feedback in an ideal manner. For many different reasons, most people find it difficult to give effective feedback, often requiring plenty of practice to get almost incrementally better at it.

Gift

Photo taken the Powerhouse Museum’s Flickr Stream under the Creative Commons licence

Listen candidly
When I receive feedback, I try to listen without reacting immediately to the feedback. Some common (ineffective) feedback people give is something like, “Your code is awful”. When put that way, who isn’t going to get defensive? Even something like “You’re really great” makes it hard to understand what behaviours you should continue repeating, and what behaviours you might consider changing. It’s particularly challenging listening to other feedback if you’ve already been put on the defensive, therefore…

Clarify detail and ask for specifics
When you feel offended or shocked with the feedback, ask for what observations people made to reach that conclusion. I like to ask for what observations they made and what impact it had, as well as how they felt about it. For some people, it’s useful to help them understand that you currently feel defensive. I might say something like, “I feel like I’ve just been judged and feeling defensive. I’d like to understand what behaviours you saw had a negative impact so that I can better understand your perspective.”

Share your context with them
People often jump to the wrong conclusion because they may not have the complete picture. It’s often useful to share other motivating forces about the same observed behaviours. For example, “I joined the conversation uninvited because I feared you would never ask me for my input and I felt I had important things to contribute.”

Acknowledge and thank them for their feedback
When people give feedback, they are giving up some of their time. Some people may have overcome certain fears about giving feedback. So when you’re receiving them, ensure that you acknowledge what they are saying and thank them for their feedback. Even if you disagree with their conclusion acknowledge their contribution if you also observed the same behaviour.

Ask for feedback early and often
Giving effective feedback takes time and isn’t often at the front of people’s minds. We know that it’s easier to respond to feedback early when you have an opportunity to change something. As the person receiving feedback, it often helps to invite people to give you feedback as this alleviates the fear most people have when giving feedback, “How are you going to react?” Giving people some notice about collecting feedback also helps.

Move people away from judgements to positive action items
For some people, it will be difficult to move them away from their “evaluation” and brining them back to observed behaviours. Also, some people don’t take remember specific behaviours or impact and like to talk about their “gut feeling”. While this isn’t particularly effective, as a person receiving feedback you can still benefit by asking them, “What should I do differently?” or “What could I do to make more of the situation, or make the situation better?”

What helps you?
I’m sure there are plenty of other tips on how to receive feedback. What do you tend to focus on when receiving feedback?

Retrospectives: Making Issues More Visible

Magnifying GlassI remember reading about the Cause, Made Visible and Not Related story on Esther Derby’s blog a while back. My biggest takeaway was that retrospectives aren’t normally the Cause of issues, instead creating Visibility into the issues already present. People constantly surprise me when they say that don’t like retrospectives because it doesn’t fix their issues. Guess what? Simply holding a retrospective won’t magically fix all your issues because it isn’t the Cause of them. Yet how do you go about fixing your issues if you don’t take the time to identify what issues you have, what impact they’re having and how you’re going to fix the true Cause?

Image taken from Dr Pat’s Flickr photostream under the Creative Commons licence.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑