Giving effective feedback is a skill that, like any other, needs to be honed. I wouldn’t claim to be an expert but there are methods in how to give feedback that means that your guidance is more likely to help the person improve.
Giving feedback to colleagues on grant applications is particularly tricky. It’s partly the high stakes involved: people’s livelihoods can be at stake and applicants’ best ideas are laid bare, so care is needed. It’s very different to critiquing a manuscript or commenting on a thesis. In those cases, what’s right and wrong is clear. With grant applications, it’s uncertain “what works” and any criticism is often subjective.
Writing feedback to unfunded applicants from a real grant panel is easier. OK, most of the time you just want to write “There was nothing wrong with your proposal. It’s just a really competitive round and your application did not make the cut, I’m sorry”. Instead panel members are tasked with finding the slight negatives picked up during review and stating them in order to justify the decision not to fund the application. The applicant has no idea how heavily these negatives weighed in the funding decision and so the feedback is very rarely useful. There’s a strong argument for not giving feedback to all applicants and instead only do so, in detail, for new investigators. Regardless, feedback from a panel is anonymous and distant, therefore easier.
The situation is more complicated when doing “internal peer review”. At my institution, we have a committee that coordinates peer review of colleagues’ grant applications. The committee looks at each proposal and gives guidance on how to improve the application.
How feedback is received by the applicant is highly variable. Obviously, feedback that says “all is good, go ahead” is warmly received. However, any hint of negative feedback can elicit a wide range of responses. Angry emails, hasty decisions and backtracking, denouncement of the expertise of the committee, despondency…
This always reminds me of Edgar Frog’s (played by Corey Feldman) advice to Sam Emerson (played by Corey Haim) in “The Lost Boys”, on the topic of delivering the fatal blow to a vampire.
“No two bloodsuckers go out the same way. Some yell and scream, some go quietly. Some explode, some implode. But all will try and take you with them.”
Edgar Frog, “The Lost Boys” (1987)
Obviously, because the applicant is a colleague, the feedback process can be rather fraught. Nobody wants to cause upset but it’s important that we can give applicants robust, honest feedback. Hey, it’s better that it happens internally – and can be fixed – rather than happening at the grant panel which can mean the application will not be funded.
So, a few tips that go some way to reducing the friction:
Structure
Write the feedback with an executive summary, followed by major points, then minor ones and finally reiterate the next steps.
For example, the executive summary might say that the committee thought the proposal was strong but needs the following points to be addressed before it should be submitted. It could say that major issues have been identified and that we advise holding off submission until a future call. Either way, make it clear for the applicant.
Major points can be bulleted and should be issues that are severe enough to require some concentrated work to fix. Minor points are typos or small changes. Major points are the ones that would make the difference between getting the grant and not, whereas minor points are concerned with presentation and clarity.
Conclude with whether the committee would like to see a revised version or if the person is free to revise and submit when ready (or whatever the outcome is).
Depersonalise the feedback
Make it clear that any decisions or feedback are the consensus view of the committee. They are not associated with any one person on the committee. Emails can be sent from a neutral address and signed by the committee. This is helpful because it is easy for the applicant to dismiss one person’s view, or to believe that any negativity is due perceived differences between colleagues.
When writing feedback, criticise the application and not the applicant. Instead of “you tend to write long sentences which are irritating to read”, go with “several sentences in the proposal were very long, which make it difficult for the reader to understand”.
If a grant application has a section on track record, depersonalising is harder. Rather than “your lack of experience in x stands out”, perhaps “the proposal requires x expertise, this is missing from the track record section”.
Be specific
Areas where a proposal has violated the funder’s guidelines are firm ground and straightforward to point out; anything else is likely to be subjective.
If there were points that were hard to read, say what they are and give line or paragraph numbers for examples. It can be frustrating to get airy feedback about a proposal being “too detailed” or “proposing too much work”. State places where there is too much detail, or give suggestions as to how to reduce the workplan, e.g. “consider cutting back on work package 2”, “could the number of validations in aim 3 be reduced”? The answer might be no, but at least the applicant can think about how to tackle the comment.
Cooling off
Use a standard text in the feedback email footer to ask the applicant to wait 24 hours before replying to any feedback. Back to the Frog brothers. No-one likes receiving negative feedback and I’ll save the blushes of my colleagues by not revealing who may have yelled/screamed/exploded/imploded. Often bad reactions come in the heat of the moment of receiving negative feedback. The footer text reminds the applicant that we want them to get funded!
—
The post title comes from “Feedback Deficiency” by Melt-Banana from their “Melt-Banana Lite Live: ver.0.0” LP.
