The intersection of technology and leadership
Conflict is a natural part of your every day life, whether it is at work or home. A certain amount of conflict is healthy as long as you work out how to resolve it.
Liv Wild and I will look at a number of conversation models we’ve found healthy teams use, in agreeing to agree. We’re holding it at the Thoughtworks UK office from 7pm this Tuesday (9 Feb). More details can be found here.
Last year, I ran a workshop at XP2009 and Agile 2009, helping people map behaviours to the different levels in the Dreyfus Model. Being a workshop for only 90 minutes, we only had time to introduce the model, generate a set of behaviours mapping them to each level in the model and only a small fraction of time thinking about where this might be useful in a coach’s toolbox.
I tend to use it as a way of encouraging people to self-assess their own behaviours, and as a way of seeing concrete, specific sets of behaviours that people in more advanced stages might find themselves.
We didn’t really get an opportunity to discuss the limitations of using the model in this way (remembering that all models are inherently limited in some manner).
Most useful for Novices
Ironically enough, this set of behaviours mapped in this way is only most useful to those who still remain Novices and less so, the Advanced Beginner. Novices need concrete rules, and directions. Advanced Beginners start to see context, yet it’s often helpful being specific about what sets of behaviours you might see at different stages.
Ironically, as you progress, using the Dreyfus Model in this way becomes less useful as you progress. I like to introduce this set of behaviours after people have had some experience with a certain practice. It helps people answer the question, “What does good look like?”
It’s not an exhaustive list
When I’ve run these workshops with other coaches, I find it interesting to see how they notice different sets of behaviours from what I would observe. Even when looking at a single practice, you have a multitude of behaviours at lots of different levels. It’s preciseness at describing specific sets of behaviour also has the risk of people only focusing on the prescribed behaviours instead of thinking about the sorts of behaviour that sits at this level.
I can’t imagine trying to list every single set of behaviour. As interesting as that might be, I think it would be impossible to capture, and difficult to communicate succinctly.
Best for personal development, not as performance evaluation criteria
It’s easy for managers to see a list of different levels, and then attempt of fit people into a box for performance evaluation. As much as their intention might be good good (professional growth) I think it’s easy to game.
I like to emphasise that this model is best used as a way for coach’s to help people self-assess, and for people to set their own goals about where they want to be.
Not the only tool to use
I like using this tool as a transitional tool, helping people jump the gap from Novice to Advanced Beginner and from Advanced Beginner to Competent. Beyond that, I would use less of this tool and look at other tools that help people self discover their information.
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.
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.
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.”
Agile methods have a gap on how to do deal with requirements that often leaves business analysts confused about what to do. From an analyst’s point of view, user stories seem to be the only technique agile methods prescribe. When people are new to agile, they take this as agile’s “only” way of modelling requirements. What isn’t made explicit often gets forgotten, so I want to make this clear: Agile methods don’t discourage thorough analysis or modelling. They don’t discourage the use of diagrams and other visualisations that help people better understand and refine their domain representation. They want everyone to focus on value and communication by using the rights tools for the job.
When coaching analysts, I often find myself telling them, all the tools they draw upon to question, to challenge, to refine and capture their understanding is important. Agile methods focus on better understanding of value, not better note taking. Writing things down does not automatically translate into understanding between two people. Cockburn’s already demonstrated a model that talks about the richness of communication methods, with written documentation being one of the worst.
The best business analysts I’ve worked with have little need to write things down, having absorbed what needs to be done, understood the real requirements, and constantly available ready to help clarify them. Conversely, the worst business analysts see their job only as writing “requests” and “demands” down, doing little to question and challenge what is really needed versus what is merely articulated. These I call overpaid scribes.
Question what value your tools are using and if they help you either better understand or better communicate with other people. If you find modelling in UML helps you better see relationships, do so but avoid spending all your time polishing the model and getting the syntax correct. Be wary of investing yourself too much in one particular model or document that makes you potentially more resistant to changing it. Neal Ford describes this as Irrational Artefact Attachment. If you find yourself writing something down to remind yourself of what is important to get across, do so but don’t use it as a way to avoid helping others understand it.
Agile methods appear nebulous to many people because “user stories” simply appear. It’s not prescriptive about how you get there because there are simply too many different ways to get there. Whilst being prescriptive will help some projects, it would no doubt hurt many others.
Image of Shh! taken from Anthony Gattine’s flickr stream under the Creative Commons Licence
As 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
When 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
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.
As 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
The 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:
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
Let’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
I’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
© 2024 patkua@work
Theme by Anders Noren — Up ↑
Recent Comments