The Art of Accepting Feedback

As practicing solution and enterprise architects we regularly present our work to our stakeholders for feedback. Those stakeholders range from mentors to peers to project teams to executive sponsors. In any and all of those situations, it is important to be able to accept feedback. In some cases the feedback will have been solicited by us from an internal mentor, client peers, subject matter experts, or other stakeholders. Soliciting feedback is a critical part of our Investigative Architecture process. In other cases the feedback may show up unexpectedly from assorted stakeholders, a manager, or a manager’s manager! Whatever the genesis and source of the feedback, accepting feedback is a critical skill.

Our recommended approach for accepting feedback:

  1. Listen. Be attentive and listen carefully. This communicates that you value the feedback and ensures you understand the feedback being provided.
  2. Capture. Write down the provided feedback and read it back to the person providing it to confirm you understand. This continues to communicate that you value the feedback; it also ensures you remember it when you need to act on it later.
  3. Receive. You asked for it, now take it! It is a natural reaction to push back on negative feedback and start preparing a rebuttal. Don’t. If you are planning a rebuttal, you are not really “being attentive and listening carefully.” Plus, feedback rebuttals are both exhausting and annoying to the person providing the feedback.

    Feedback Assessment

  4. Assess. Either the feedback supports your thesis or it disagrees with your thesis. If it supports, great, you have an additional supporter. If it doesn’t, you either agree with the feedback or you don’t agree with the feedback. If you do, great, you have the information you need to refine your perspective. If you don’t, you can respond… but only after careful consideration of the feedback.
  5. Respond. Share the facts supporting your perspective, engaging in a discussion will help you and the person providing feedback both understand each others’ perspective. Be careful not to overdue it. If you reach a stalemate, communicate that you will do more research for a follow up discussion. Then plan for a fact based analysis.
  6. Express gratitude. Providing feedback takes effort and carries a level of risk. Thank everyone who took the time to provide you with feedback.
  7. Act. If people provide you with feedback and you do nothing with it, they will stop providing you with feedback. Ignoring feedback wastes their time and your time! Take appropriate actions on the feedback – update documents, do additional research, facilitate additional meetings to resolve, etc. – as soon as possible after you receive the feedback and share the results with whoever provided the feedback.

Sometimes, even when you agree with the contrary feedback, you will be inclined to defend your position. It is a natural reaction to explain that you weren’t wrong because you are a moron, but because <insert excuse for your choice here>. Don’t do it! Don’t spend time on this explanation unless the person providing feedback explicit asks why you held a different position initially. Otherwise, this overly-defensive method of feedback acceptance:

  1. Slows down the feedback process.
  2. Sounds defensive and undermines your expertise. It is okay to be wrong. Not knowing everything is not the same as not knowing anything. Accepting your own limitations shows strength, not weakness.
  3. Is annoying and exhausting for the people providing the feedback.

If you find yourself falling into the trap of either defending or explaining every choice, perhaps you are better off not responding to any of the feedback on the spot, but capturing the feedback and handling the assessing and responding when you have had time to step back and regroup.

To learn more about our brand of stakeholder diplomacy, read our Architect or Diplomat? article or check our other articles on diplomacy and facilitation. Please contact us if we can assist you in any way!

The following two tabs change content below.

Dan Hughes

Was a principal consultant at Systems Flow, Inc.

Latest posts by Dan Hughes (see all)



Comments

Comments are closed.