patkua@work

The intersection of technology and leadership

Search results: "feedback" (page 1 of 12)

The Gift of Feedback (in a Booklet)

Receiving timely relevant feedback is an important element of how people grow. Sports coaches do not wait until the new year starts to start giving feedback to sportspeople, so why should people working in organisations wait until their annual review to receive feedback? Leaders are responsible for creating the right atmosphere for feedback, and to ensure that individuals receive useful feedback that helps them amplify their effectiveness.

I have given many talks on the topic and written a number of articles on this topic to help you.

However today, I want to share some brilliant work from some colleagues of mine, Karen Willis and Sara Michelazzo (@saramichelazzo) who have put together a printable guide to help people collect feedback and to help structure witting effective feedback for others.

Feedback Booklet

The booklet is intended to be printed in an A4 format, and I personally love the hand-drawn style. You can download the current version of the booklet here. Use this booklet to collect effective feedback more often, and share this booklet to help others benefit too.

Feedback for Conference Presenters

After presenting at the recent Quarterly Technology Briefing in London, Manchester and Hamburg I had a very good question from one of my colleagues about what feedback I found most valuable.

Our feedback forms were quite short with two quantitative questions (out of a 1-5 scale), and three or four free text questions. Although the quantitative questions gave me a good indication of general feedback from the audience, it is not specific enough for me to really understand what things to do more of, or things to do less of. It reminds me of a traffic light system some conferences used (red, yellow, green) for evaluating conference presenters. Fun, quick, but entirely useless to know why people put numbers down.

Although the free text answers to feedback forms take more time to read, the feedback is much more helpful, particularly around getting an understanding of where expectations for a session matched or didn’t match, and useful suggestions or ideas to focus more on. I can take this feedback and actually do something about it for a different presentation.

For conference organisers, or if you’re putting feedback forms together for your own workshop, please don’t leave feedback as a binary, or based solely on numbers. Although there are advantages to getting quicker to an evaluation, you don’t really know why people rated something well or not well. Ask open ended questions and provide these to speakers unedited and raw.

I think if conferences really wanted speakers to get better as well, I think having some peer presenters sit in a session and provide targeted feedback would be even better. I could imagine something like this could focus solely on the mechanics and/or execution of the presentation and give timely, helpful feedback to improve the session and the presenter.

Tightening the Feedback Loop featured on Slideshare Homepage

I uploaded my slides for “Tightening the Feedback Loop” for the Agile 2011 conference and it got selected for the homepage on Slideshare. Keeping this one for posterity:

Writing feedback as a conversation with the recipient

We had a couple of people roll off our project recently. Even though we had been doing regularly feedback as a group, each person still wanted some written feedback to take with them to their next project. In writing down the feedback (and trying to collate all my thoughts from previous sessions) I found it was immensely useful to write the feedback as if I was talking to the person.

In past occasions, for some reason, I wrote a lot of feedback as if someone else was going to read it. For example, “I worked with <Joe> and noticed… It had this impact…”

Rather than as if I was writing feedback for someone else, I tried to write the feedback as if I was talking to the person. Framed in the context of the person who will benefit from receiving the feedback, I think it really changed the way that it made me think about it. It really focused my attention on feedback that would really help the person grow – reinforcing those behaviours that they should continue doing, and bringing to attention those behaviours that continued to puzzle me, or bringing to attention those behaviours that might take much more time than a single project to develop.

I found that writing feedback as if I was talking to the person also helped me humanise and personalise a lot more of the feedback I wrote down. Why don’t you give it a go next time?

Long Feedback Loops

Almost five and a half years ago, one my first project in the UK, I built a constrained email tempting engine to be used by marketing folk with a small team of three other developers. I think we worked for about six to eight weeks to develop the entire application, including retrofitting its integrate its output with another system.

A year or two ago, we had some consultants return to the client who talked to one of the original developers who still worked for the same client. They spoke fondly of the good times he had on our team, and spoke proudly about the application we wrote. In the four years or so of constant use (they would revisit their emails at least once a month), the users apparently only ever reported one bug. He mentioned that bug (a special character in the email subject line) was also deprioritised from the original work we did. It was an enough fix and with test around it, was not a problem updating the system.

I certainly appreciated the feedback, particularly since you don’t always get to return to see the long term results of the work you do as a consultant, or even just as a developer.

Some of the great things I learned from that project.

Acceptance Test Driven Development is entirely possible
We worked hard to test drive this Swing based application from the start. It really changed the way that we designed the application and all of us learned a whole heap about understanding testable presentation patterns. It formed the basis of several talks and the knowledge, particularly the separation of concerns is entirely applicable to all sorts of other tools and interfaces such as javascript, or command line interfaces.

On a different note, coverage combining end to end acceptance test and unit tests meant we had 100% code coverage. It was never the goal, but interesting to see on this application it was entirely possible.

Never discourage people from trying new things
The organisation was rife with contractors. Not all of them entirely passionate. I love building great teams and the fact that everyone was learning, and saw things being delivered reignited people’s passions to do various things. I distinctly remember two events made possible by encouraging people to explore their passions and strengths.

One of the developers, interested in the User Experience side asked if he could do some user testing with the application. I can’t remember exactly what I said, but certainly encouraged him to do that. He did, what some people call Guerilla Usability Testing – grabbing someone who didn’t know anything about our application, and giving them a task list to complete as he watched them over the shoulder. Based on this study, we found out, to no surprise, the way we laid out the application didn’t make some of the tasks as easy as they could have been. We channeled this feedback into our interface and helped make life easier for its users.

The other event, a contractor, seemed to find his passion for developing usable software reignited. Everyone will know that swing applications aren’t the nicest things to look at. I remember coming in one morning to find that whole interface reskinned and redeveloped. It looked a whole load better than what you’d get with swing out of the box.

I found out much later that he had, by his own volition, worked a couple of extra hours one night because he wanted to add that extra polish and make the interface attractive to users. Awesome stuff that would never have happened without encouragement to do “the right thing”.

Involving real users
As a systems thinker, I know that the purpose of the project should have been an intermediate step. The real problem the organisation was a missing feedback loop from IT back into marketing. I knew that then, and I know that know, however being pragmatic and realistic, you can only do good things within your own sphere of influence. Trying to change how the entire marketing and IT department silos worked (or failed to work together) would take much more than the two or three months I was going to be there.

Fortunately, we had one person on our project who had worked for their company for a while and had a couple of good contacts in marketing. Whilst we couldn’t change the way projects spun up, we managed to get someone who was going to use our software down, early, and show them what we were building for them. More than that, they asked for somethings (that we could almost immediately turn around for them) and they were blown away that their feedback actually mattered and made a difference.

Conclusion
I appreciate good projects, and where possible, create those environments for others to thrive in. There are many good things to carry forward in these things and can only hope others benefit from it as well.

Long Feedback Cycle on a 4 Year Old Project

Almost five and a half years ago, one my first project in the UK, I built a constrained email tempting engine to be used by marketing folk with a small team of three other developers. I think we worked for about six to eight weeks to develop the entire application, including retrofitting its integrate its output with another system.

A year or two ago, we had some consultants return to the client who talked to one of the original developers who still worked for the same client. They spoke fondly of the good times he had on our team, and spoke proudly about the application we wrote. In the four years or so of constant use (they would revisit their emails at least once a month), the users apparently only ever reported one bug. He mentioned that bug (a special character in the email subject line) was also deprioritised from the original work we did. It was an enough fix and with test around it, was not a problem updating the system.

I certainly appreciated the feedback, particularly since you don’t always get to return to see the long term results of the work you do as a consultant, or even just as a developer.

Some of the great things I learned from that project.

Acceptance Test Driven Development is entirely possible
We worked hard to test drive this Swing based application from the start. It really changed the way that we designed the application and all of us learned a whole heap about understanding testable presentation patterns. It formed the basis of several talks and the knowledge, particularly the separation of concerns is entirely applicable to all sorts of other tools and interfaces such as javascript, or command line interfaces.

On a different note, coverage combining end to end acceptance test and unit tests meant we had 100% code coverage. It was never the goal, but interesting to see on this application it was entirely possible.

Never discourage people from trying new things
The organisation was rife with contractors. Not all of them entirely passionate. I love building great teams and the fact that everyone was learning, and saw things being delivered reignited people’s passions to do various things. I distinctly remember two events made possible by encouraging people to explore their passions and strengths.

One of the developers, interested in the User Experience side asked if he could do some user testing with the application. I can’t remember exactly what I said, but certainly encouraged him to do that. He did, what some people call Guerilla Usability Testing – grabbing someone who didn’t know anything about our application, and giving them a task list to complete as he watched them over the shoulder. Based on this study, we found out, to no surprise, the way we laid out the application didn’t make some of the tasks as easy as they could have been. We channeled this feedback into our interface and helped make life easier for its users.

The other event, a contractor, seemed to find his passion for developing usable software reignited. Everyone will know that swing applications aren’t the nicest things to look at. I remember coming in one morning to find that whole interface reskinned and redeveloped. It looked a whole load better than what you’d get with swing out of the box.

I found out much later that he had, by his own volition, worked a couple of extra hours one night to reskin our interface using JGoodies because he wanted make the interface attractive to users. Awesome stuff that would never have happened without encouragement to do “the right thing”.

Involving real users
As a systems thinker, I know that the purpose of the project should have been an intermediate step towards a bigger change. The real problem was that the organisation was a missing feedback loop from IT back into marketing. I knew that then, and I know that know, however being pragmatic and realistic, you can only do good things within your own sphere of influence. Trying to change how the entire marketing and IT department silos worked (or failed to work together) would take much more than the two or three months I was going to be there.

Fortunately, we had one person on our project who had worked for their company for a while and had a couple of good contacts in marketing. Whilst we couldn’t change the way projects spun up, we managed to get someone who was going to use our software down, early, and show them what we were building for them. More than that, they asked for somethings (that we could almost immediately turn around for them) and they were blown away that their feedback actually mattered and made a difference.

Conclusion
I appreciate good projects, and where possible, create those environments for others to thrive in. There are many good things to carry forward in these things and can only hope others benefit from it as well.

Tightening the Feedback Loop on Slideshare

I presented this session on the Collaboration track at Oredev yesterday. I uploaded the slides and they’ve now been showcased on Slideshare’s home page and their Business & Management home page.

Check it out and feedback always appreciated.

http://www.slideshare.net/mobile/thekua/tightening-the-feedback-loop

Giving feedback to defensive people

A few people have arrived at this blog looking for the terms, “Giving feedback to defensive people.” Before focusing on the fact that the recipient may be “defensive”, I’ll refer to you to several different posts outlining some principles of giving effective feedback. Read them before continuing on.

Firstly, if you’re giving feedback to a person, ensure that you follow the principles of effective feedback.

  1. You intend on strengthening their confidence; or
  2. You’d like to help them improve their effectiveness

Many times I’ve heard several people give feedback and it is not in the spirit of either of these. Often, they give feedback with the intent of improving their own effectiveness, not necessarily the recipient. For a variety of different reasons, it’s easy for me to improve my own effectiveness by asking people what to do – something that is selfishly easy. It takes more courage and effort, putting yourself in the recipient’s shoes to help them out.

CrossedArms
Photo taken from Noii’s Flickr stream under the Creative Commons licence

If someone comes across as “defensive”, I’d ask yourself what circumstances they could possibly be under that make them so. Perhaps they have other things on their mind, and are preoccupied in a manner that makes it difficult to listen to feedback. The solution? Ask them if now is a good time to give them feedback.

Maybe the recipient associates “feedback” with “criticism” due to others “giving them feedback” ineffectively, fuelling a cycle of defensiveness. The solution? I find it easy to spend a quick minute or two describing the basic principles of feedback, and help them understand you are here with the true intent of either strengthening their confidence or improving their effectiveness. I like to emphasis it should be a conversation and that I will try to be a specific as possible, but encourage questioning if the recipient needs clarity.

Another reason the recipient may be defensive is for fear of being judged as a person. The solution? Focus on behaviours and impact, rather than attempting to describe what you think their motives are. This doesn’t mean you cannot have an opinion, however it should be clearly stated about how you interpret the impact, not on how you interpret them as a person.

They may truly believe that whatever situation you describe, they disagree with. The solution? Start with the model I describe here, seeking agreement for observations, then impact, before thinking about recommendations. Any disagreement on the early stages will inevitably lead to disagreements on future stages.

Finally, as a person giving feedback, you need to accept the recipient may choose to acknowledge, disagree with or do nothing with the feedback you gift to them. I remember one incident, quite recently, where a colleague gave me feedback with recommendations. We talked about it, both understanding the variety of forces unbeknownst to each other. At the end of the conversation, I concluded I would have repeated the same behaviour in the same circumstances, however that’s when the feedback donor got frustrated.

My lesson: if you’re giving feedback to someone, be prepared to say, “I respect that we disagree on something, and thank you for being prepared to listen.”

A Guide to Receiving Feedback Part VI: It’s Okay To Disagree

DisagreeingAs a person receiving feedback, you may find you can’t understand what the other person is trying to tell you. You’ve already put significant effort shaping effective feedback out of whatever it is the donor gives you. First you focused on fact finding, uncovering your specific behaviours. You then asked some questions identifying how the donor interpreted the impact.

Remembering that effective feedback is aimed at helping you, the recipient, Strengthen Confidence or Improve Effectiveness, you may find, at some point, the donor’s feedback isn’t doing either. Perhaps you don’t remember your own behaviours, or you see the impact being different. It’s your responsiblitiy as a recipient to seek actions that help you Strengthen Confidence or Improve Effectiveness and if you cannot find out how changing your behaviour will help you do either, then it’s okay to disagree.

Make sure you thank the donor for their feedback, helping them understand how and why you the feedback doesn’t Strengthen Your Confidence or Improve Your Effectiveness. Only when you’ve done everything you possibly could to uncover effective feedback, then is it okay to disagree with the feedback.

Don’t feel like you have to respond and agree with every part of feedback. At some point, interpretation of impact requires a matter of perception, and people often remember facts quite differently from what actually happenned.

The image above is taken from Twilsoncom’s flickr stream under the creative commons licence

A Guide to Receiving Feedback Part V: Thank Them For Their Feedback

Give ThanksWhen someone gives you feedback (even if it’s not wrapped completely effectively), it’s important to thank them for taking the time to do so. As long as you uncover the important elements of effective feedback together, and agree on actions helping you Strengthen Confidence and Improve Effectiveness, then you personally benefited from the situation.

Avoid the need to justify every single part of the feedback and start with a “Thanks!” Acknowledging the person trying to help you goes a long way. Affirming the value of each piece of feedback helps the donor feel at ease. It assures them you are listening and aren’t reacting badly to their feedback. Creating this safe environment for the donor lets them focus on giving effective feedback, boosting their confidence as they continue with the rest of the feedback.

There’s no need to go all gushy and shower them with gratitudes. Start simple, using short positive affirmations, indicating to the donor you are listening to their feedback focusing on what it is they are trying to tell you.

Effective feedback takes time to give, and as a recipient you should thank the donor for taking their time to help you strengthen your confidence or improve your effectiveness.

Picture above comes from Fave’s Flickr stream under the Creative Commons licence

« Older posts

© 2019 patkua@work

Theme by Anders NorenUp ↑