By, Shanthi Balasubramanian

A three-part series on constructive feedback.

PART – 2

A quick refresh on Part 1 of the series:

• Feedback is important 
• Gather feedback early on, quickly, and as much as you can
• Constructive or effective feedback is combined with specific comments and is supported by evidence

In Part 2 of the series, we shall try and understand how to GIVE effective feedback.

If we have the responsibility of giving feedback, the challenge lies in the fact that the recipient who asks for feedback may not be ready to receive it. It is possible that they may be offended, insulted, or hurt when you give feedback. But the fault is not entirely theirs. We are, perhaps, not trained to deliver feedback in the right way!

The process of giving feedback is delicate, and can either cause anxiety/fear or encourage the receiver to see the brighter side of things.

The possible reactions to feedback could be:

The first set of reactions to feedback is not the desired outcome. To garner the second set of reactions, we must deliver feedback effectively. There may be several factors that constitute constructive feedback. However, I would like to narrow down on the following four key factors when GIVING feedback:

• Give it while it matters: If you really want your feedback to be worth your while, give it on time. For example, giving feedback on a new format of HELP design suggestion on the day of the release is practically of no use to anyone. You might as well not give it! However, timely feedback may help in implementing the plan.

• Issues vs Recipient (be aware of “unconscious bias”): It is important to address the issue at hand rather than focus on the individual (the recipient of feedback). It is also important to remain unbiased. For example, the review comment “Bummed that there is not a search. ☹  Does the tool support one?” actually encourages a discussion between the giver of the feedback and its recipient. It does NOT suggest in any way that the person responsible for design may have forgotten to add the search feature. Allowing pre-conceived notions to form the basis of feedback may result in a negative head start. Also, suggesting a solution to a problem may be an effective key rather than reiterating the problem itself.

• Look for positives too! Avoid sarcasm: From personal experience, whenever I have approached QA for a review, I end up getting feedback, such as “There is a spelling mistake”; “The alignment is poor”; “The footer is missing”, and so on. Which may be true! But, I am also eager to know about the good things. It cannot always be a case of “half glass empty”.
  I think, when we don the shoes of the GIVER, we tend to tell ourselves “Look for what is bad with this”. Instead it would be better to tell ourselves, “Look and see how this can be better”. It is thus important to maintain a balance of positives and negatives to ensure constructive feedback.
  It would be wise to avoid being sarcastic. For example, “I see that the hyperlink to “Documentation Feedback” is returning a 404 error. Do you really want feedback or not?”

• Information Overload – suggesting the “doable”: Working on a project from scratch is always easier than to go back and edit the legacy drafts. Providing feedback on 2 or 3 key areas and enhancing the result is better than overloading the recipient with information that may either seem like nitpicking or cause confusion. For example, “Page 3 has spelling errors; page 4 is not formatted properly, double spacing instead of single; page 6 does not read well as all of the SME’s comments have not been addressed;  has been spelt incorrectly; “hologram” is spelt incorrectly on page 22” can be replaced with a table of errors thereby classifying each of the errors (as shown in the table below) to help the recipient understand it and resolve it easily.

Nature of Error	Description	Page Number/Section	Action by recipient
Spelling	Hologram spelt incorrectly	43 / 1.1.3
Formatting	Headers and Footers do not align with template	59 / 3.2.9
Content	Check with SME	98 / 6.3.4 – A

Or, for that matter formatting errors, where one or more Headers and Footers are not as per the prescribed template. It would be easy to put a note asking for thorough review of all the headers/footers.

To summarize, when giving feedback:

• Ensure on-time feedback

• Be firm, not mean

• Consider the value of the feedback for the receiver before suggesting it

• Be positive and sincere; it is not about winning or losing

• Identify 2-3 key areas of improvement, don’t produce a list

In the concluding article, Part 3 of the series, we shall evaluate how to RECEIVE Constructive Feedback.

About the Author

Shanthi is engaged with Kripya Engineering as Consultant – Documentation and handles several documentation assignments. She has 20+ years of experience in documentation varying from the Corporate to the IT sector. She loves to write, believes in continuous learning and remains fascinated by all that happens in the world of Tech writers.