Sending difficult feedback on a messy editorial project

At some point (hopefully very rarely), every proofreader and copy-editor will find themselves working on a project where it seems that somebody, somewhere, at some point, dropped the ball in a big way.

As a copy-editor, you might discover that the developmental editor seems to have let through major inconsistencies and that swathes of detail are missing. Or, as a proofreader, you might find that the copy-editor appears to have fed the style guide to a passing llama or didn’t seem to heed that the order of words in a sentence is actually somewhat important.

It can be really difficult to determine the most ethical and professional way to approach a situation of this kind. On the one hand, you might feel that the issues are so bad – so systemic – that they raise serious questions about the quality of the previous editors’ work. On the other hand, it’s unlikely that you have the whole picture: there are all sorts of potential reasons a manuscript could have reached you in a poor state, and you have no way of knowing who is responsible – if, indeed, any single person is.

It’s a dilemma, and deciding how to approach the situation can feel like a big weight of responsibility.

What to do?

So, what do you do? Do you quietly fix the issues and say nothing to your client? Do you send a few pointers of feedback but keep silent about the real scale of the problem? Or do you shout from the rooftops about how dreadful everything is and how unreasonable it is for you to be expected to fix it?

The answer will probably be none of the above (and it’s never the last one).

Instead, in my experience at least, I’ve found it’s best to give full feedback in an honest and objective manner – but, crucially, to leave all questions of who (who is responsible?) and why (why did this happen?) to the person who knows the circumstances best: the client.

Let’s take a deeper look at some of the possible ways to achieve this. Frustration at the issues you’re facing is natural, but it’s vital to be as objective as possible in how you handle the situation.

Reality check

The first thing I do before I start to draft any sort of feedback is to make sure my instincts are on solid ground.

• Self-filter. Are the issues you’ve identified really errors as opposed to preferences or choices? Are they truly as widespread or as devastating as you feel they are? Can you find support for your opinions in appropriate style guides? Can you consult trusted colleagues (being careful to remove all potentially identifying details) to see whether they agree with you?
• Check you have the correct version of the files. Occasionally it happens that the wrong version of a manuscript is used by accident.

Self-filter

Avoid casting aspersions that turn out to be ill-founded. This risks damaging others’ reputation and even your own.

Send feedback: why?

Once I’ve satisfied the above two criteria and any others relevant to the project, I find it helps to remind myself why I’m sending feedback. I almost certainly wouldn’t mention all of these ‘whys’ explicitly in my communications, but I find that keeping them in mind can help me to maintain a constructive mindset.

Firstly, there are two practical reasons to send feedback:

• You need to justify extra costs and time to your client. If the scope of the project has increased, it’s likely you’ll need extra time and/or money in order to do the extra work. You will need to provide a clear explanation of why as a starting point for the negotiation.
• Your client may want input on how the issues are fixed (or even whether they are fixed). As mentioned above, one option is to fix the issues yourself without telling your client. But, if you do that, you only have your perspective to go on. Your client will understand the whole project and its parameters better than you do. And, even if your client replies that they want you to go ahead and fix things for them as you see fit, it’s wise to have their authorisation to do so, to avoid challenges to your work later on.

Secondly, there are at least three (you might think of more) general reasons that might also be relevant to your project:

• Keeping quiet does a disservice to the client. For whatever reason, your client may be completely unaware of the issues you’ve found. This may be a symptom of ongoing quality implications that could impact your client’s brand and reputation.
• Keeping quiet does a disservice to the author. The author may have spent years working on their book and publication may be a huge event for them. And, even if that’s not the case, most authors want their book to be in the best shape possible. By coming forward with your feedback promptly, you give the project the best possible chance of any remedial action being taken (if your client decides it is necessary) within the limits of the schedule and budget.
• Keeping quiet does a disservice to the previous editor (if, that is, your client finds that any specific editor was responsible). It’s possible that this editor will lose out big time in the short term as a result of your feedback. But ask yourself: wouldn’t you want to know – for the sake of the longevity of your business – if there were major issues with your service to your clients? If we don’t know about the gaps in our practice, we can’t fix them.

Be constructive

Why are you sending feedback? If it’s primarily to have a bit of a moan, you might not be in the best mindset to send your feedback in the most productive, professional way.

Send feedback: how?

Once you’re clear in your head about why you’re sending feedback, the next step is to write it. Following are some tips you may find useful.

• Be prompt, not hasty. Avoid firing off a sketchy email before you have a full understanding of the project. Emailing in haste may mean you either fail to give a full picture of the issues or (much worse) inadvertently paint too severe a picture of what you’ve found.
• Remember that you don’t have the full context. There may be circumstances that mean the issues are not as problematic as you think. It may also be that no specific person is (wholly) to blame for the issues you’re seeing. Perhaps a lot of work was done on the manuscript after it left the previous editor’s hands. Perhaps there is a sensitive personnel issue that needs to be taken into account. Only your client knows these details.
• Be precise, not expansive. If there are widespread issues, say so, but where possible give precise, factual examples rather than offering expansive commentaries or interpretation. This means using language such as ‘On pages 4, 17 and 68 I found…’ rather than ‘The copy-editor has not…’ or ‘This is the worst example of xyz I have ever seen.’
• Empower, don’t attack. Empower your client with the information they need, but keep all accusatory and emotive language out of your communications.
• Don’t apologise either. Similarly, it’s not your job to apologise for the issues you’ve found. Avoid peppering your email with phrases such as ‘I can see why, but…’ and ‘I’m not certain, but…’ unless you really can see why or are not certain.
• Offer solutions, not problems. Wherever possible, take a structured approach in presenting your feedback and offer solutions rather than just dumping an unholy mess in your client’s inbox. Try to ensure that your client remembers you as part of the solution rather than a piece of the problem.

Don’t judge

You are the expert witness, not the judge. Focus on the issues, not the person you imagine to be responsible.

---

Sending this kind of difficult feedback to your client when it seems possible that an unknown-to-you previous editor will get the blame can feel really unpleasant. However, it is important to do so, for the sake of the project and to discharge your professional responsibilities to your client.

How you give the feedback makes a big difference ethically and can also be vital to your own reputation. Depending on the details of your project, the three principles explained here – self-filter, be constructive and don’t judge – are likely to be a sound starting point.

---

Note: This post brings together some suggestions from approaches I’ve found useful from my (thankfully rare) experience both writing this kind of email (as a copy-editor or proofreader) and receiving it (as a project manager). However, few topics of business communication are as sensitive as this, so always be governed by the specifics of your project and your relationship with your client.