Writing, feedback, and editing

In this part, I will have to repeat some things from Part I, but I think they are worth repeating. It is now my strong belief that it’s very difficult – not impossible, but difficult and risky – to write a successful proposal all on your own. As I mentioned earlier, generous colleagues who share their proposals can help you get started and inspired. Not everyone will do this, and that’s perfectly fine. I’m also not ready to share mine widely yet – my project hasn’t even started, and the proposal contains some sensitive information. Maybe ask me again in a couple of years!

But it is even more important to share your proposal – or some parts of it – with people for feedback.

I shared my first version with five people, some of whom were experts in the immediate field I was working in, while others were social scientists relatively remote from it. Additionally, our research support office organized a mock panel, where several people from different social sciences and humanities departments at my university listened to my presentation, and two read the draft proposal, giving feedback and asking questions.

Now I realize that it was the best combination: ERC panel members who will be reading the proposal may or may not be familiar with your field, so it is important to make sure that your writing is clear and convincing to people with different degrees of pre-existing interest in and awareness of your topic. If your institution doesn't organize things like these, you can assemble a mock panel yourself. I think a good idea is to replicate the disciplinary composition of the panel you're going for as much as possible, but it seems to me now that the panel members closest to your topic will be your main readers.

I collated all the feedback I got and tried to see patterns – where was I the least clear? Which aspects of the proposal did people comment on most? Here it is important to not just blindly incorporate all of this feedback, but to see why people commented the way they did and identify gaps in your writing and reasoning. People too close to your topic may take some things for granted and suggest you elaborate on something super specific, which may or may not be relevant or helpful for the general understanding of the project by someone who is less connected to the field. A fine balance, and decisions to be made – but whatever feedback you received, you can use it to improve your proposal.

I also received some very good feedback on the structure and organization of the project from my assigned research support officer and the editor they hired to read the B1: there were some very basic things I missed just because I was no longer able to see the proposal clearly, having re-read it so many times myself. So these extra pairs of fresh eyes were very important at the last stage.

Obviously, not everyone will be able or want to read your whole application package; and that’s ok, too. But I found that sharing bits and pieces for micro-feedback is also a good strategy: I did harass my friends with my diagrams and tables, which I just sent them without any context – to see if these visuals looked good and worked on their own. But I don’t think at the end of the process I had any friends left who were not already force-fed with my project and could count as fresh.

At the interview stage, I used a similar approach to prepare my presentation slides – I also shared bits with my friends to see if the colors I chose made their eyes bleed or imprinted the gist of my research in their retinas forever. But more on the interview stage in the next posts.