A hefty chunk of this job involves receiving - and responding to - feedback, aka criticism, aka an assault on your very soul. Even after all these years, it’s very hard not to take critical comments on your work as a personal attack. I think this is even more true of grant applications than of manuscripts - a manuscript is something you’ve done, finished, and you can be confident that it will find a home somewhere. In funding applications you are laying yourself bare: this is my next big idea, my vision, my future; if you don’t like it I may never get to do it.

Given this huge personal investment, the temptation is to hit back hard at any and all criticism. I don’t necessarily think this is a bad idea - it can be cathartic to write the response you want to write. But probably best to then delete it and make a start on the response you ought to write.

I have just spent two days in grant panel deliberations, a typically brutal process where the pot of money available is dwarfed by the pile of excellent proposals in front of us. In this context, not only the content of the rebuttal, but also its tone, can tip the balance between ‘it’s good, but…’ and ‘fund this!’. As a rule of thumb, if you respond to your reviewers as if they simply needed to read your proposal properly, your chances of progressing from the first to the second reaction decrease.

The art of the rebuttal includes at its heart an assumption of good faith. Your reviewers may well have misunderstood parts of your proposal, but they will have read it carefully and will have tried their hardest to make sense of it. If they have not quite grasped a particular concept or detail, the onus is on you to explain it better. Simply pointing them back to the original proposal is not usually the best strategy. (Caveat: sometimes it really is, but there are ways of doing this that steer clear of defensiveness and condescension.)

A little empathy in considering the constraints under which the review has been produced is also useful. Often reviews of grant proposals are required to be highly structured, and also to fit within a strict character limit. In some schemes the review itself is already a consensus, with text pieced together from several independent reviews. Space for nuance is limited, so a review might state something like “links between work package 1 and work package 2 outputs are not sufficiently clear” rather than “although a diagram of linkages between work packages is provided, the specific ways in which the outputs from WP1 will feed into WP2, including alignment of timings in the deliverables, is unclear.” Obviously the second statement would be more useful but you should assume that the reviewers considered what you originally presented and go beyond a cursory “We refer to our original figure which fully explains this” in your response.

And of course you’re allowed to disagree. I prefer the term ‘response’ to ‘rebuttal’ as it is less antagonistic, but sometimes you really do need to rebut. The key here is to evidence your counterclaims. And tone is always important. Your reviewers may be mistaken, but they have not willfully misunderstood you. Here is your chance to provide some additional context and explanation to make your point more clearly and forcefully. We are willing - indeed, often actively hoping! - to be convinced. Successfully pushing an application you really like to the top of the pile brings its own glow of satisfaction.

This, ultimately, is the art of the rebuttal. It is to turn enthusiasm for your idea into excitement; to turn a general feeling that you know what you’re doing into a conviction that you are the best team in the world to deliver your vision; to turn a broadly sympathetic ally into a champion for your cause. Don’t forget that all reviewers today will have been reviewees themselves, and will share in some of the pleasure of success.