Over the years (31 years in another month), I have had the privilege of working with a lot of colleagues and being on the receiving end of a lot of job applications. That has given me an insight into how editors view aspects of their job and how they go about applying for work.
In a previous essay, Business of Editing: Losing the Chance, in “Error 6” I discussed the copyediting test and how it is possible to tell whether an applicant passed or failed the test within one minute. One way to tell is to look at any queries. (Of course, the lack of any queries can also be very revealing.)
Most editors do not understand the variety of roles that queries fulfill. If you want to kill future prospects, a quick way to do so is with poor, no, or little (when more than a little is expected) querying. Queries should be viewed as playing these roles, at minimum:
- to ask the author a question
- to demonstrate to the author and to the client (assuming your client is not the author) that you are knowledgeable
- to explain
- to market your skills
- to make the author and client comfortable with you
- to demonstrate why you are the editor that the author and client should always seek out
Each of these roles is linked to your success as a professional editor.
To Ask a Question
Editors get tired of writing the same query repeatedly, chapter after chapter, even project after project. Repetition is deadly but let’s face it, many of the queries we need to ask remain the same author to author, client to client, and project to project. After a while, there is a tendency to scale back on the query because it is tedious to retype. This is where a tool like EditTool’s Insert Query macro is a solution to a problem.
What I have seen is repeat queries being truncated. The first time, maybe the second time, the editor will write:
AQ: There is no section by this title in this chapter. Is this the correct section title? Please either provide the correct section title or modify the incorrect section title.
But it isn’t long before that query becomes “AQ: Please provide the correct section title,” which shortly thereafter becomes “AQ: Need correct section title,” which soon becomes “AQ: Section title?” — or, which also often happens, the query starts and finishes as “AQ: Section title?”
The first query identifies the problem, asks the question, and offers alternative solutions — it shows that you are a professional editor. But the pared down versions show laziness and a lack of understanding of how to communicate with an author. More importantly, the message you are sending your client — whether the client is the author or the publisher — is that you are not a professional.
The pared down versions also suffer from being incomplete. How do you expect the author to understand what the problem is and the solutions are from a cryptic message? (The worst queries I have ever seen were “AQ: ?” How can one form a response? My initial reaction was to reply “ED: !!!”)
To Demonstrate Knowledge and Explain
We all have lots of competition. One way we convince clients to hire us again or to recommend us to colleagues is by demonstrating our knowledge, whether it be of the subject matter or of something else appropriate.
For example, it is common in books that I edit for authors to confuse “recur” and “reoccur.” Consequently, where I think they may have confused the terms, I ask:
AQ: Recur/recurrence mean to happen again repeatedly; reoccur/reoccurrence mean to happen again but only once. Which do you mean here?
This query demonstrates my knowledge of language and raises an important point, because it does matter greatly whether something happens repeatedly or just once again. (And I make my life easy by having this as a standard query in my EditTools Insert Query dataset so I only need to select it and insert it, not type each time I want to use it.)
Two additional examples of queries that I routinely use in my editing work are:
AQ: Should “/day” be changed to “/dose” or should “divided” be added before “bid”? As written it appears that the daily dose is to be given multiple times a day. Please make clear the frequency.
and
AQ: Do you mean “e.g.” rather than “i.e.”? When the items are only examples and the list is not all inclusive, “e.g.” is used. If the listed items are all the possibilities, then “i.e.” is used. If “i.e.” is correct, consider moving the material from the parens and making it a proper part of the sentence.
Notice the messages I am communicating. First, I identify the problem; the author does not have to guess. Second, I explain why it is a problem. Third, I provide solutions. Both the author and the client can see that I am carefully reading the manuscript, I am thinking about the manuscript (i.e., I am focused), I care about the manuscript and the author, and, above all, that I am knowledgeable about editing — that is, that the editor’s primary role is to help the author communicate clearly and that one tool in the editor’s toolbox for doing that is for the editor to communicate clearly with the author.
The point is that queries can serve multiple purposes and I want all of those purposes to reflect positively on me.
To Market and to Comfort
Every author is anxious about the editor. After all, the author has invested time and effort into the manuscript and wants it treated with respect. For those of us who work indirectly with authors, the author’s anxiety about us is even greater. And because we work for publishers or packagers, the publishers and packagers also experience anxiety albeit at a much lesser level than authors. Their concern often revolves around how the author will perceive and receive the editor.
You put everyone at ease when you demonstrate your skills and communicate effectively. Perhaps more importantly, if you view queries as your opportunity to establish your credentials with the author and client, you will be more cautious in how you write them, which means that you are less likely to antagonize either the client or the author.
I recall a book I was asked to review after it had been edited because the author was angry over the editing and had spent a considerable amount of time both berating the inhouse production staff for having hired the editor and in correcting what the author perceived as editor errors.
As I went through the editing it became pretty clear that the editing was well done; the problem was the queries. They were written in such a manner as to convey the editor’s contempt for the author. I admit the author was somewhat lazy and that had I been the editor, I, too, would have been cursing the author — but the difference is that I would not have let those feelings permeate the queries: neither the author nor the client should ever think that I have anything but admiration for the author’s work.
The editor hadn’t comforted the author or the client nor had the editor marketed herself well. The author’s anger might be ratcheted down a bit, but both the author and the client will hesitate to use the editor again, and the author will let fellow authors know as well.
To Demonstrate Why I am The Editor
Presumably we are all well-skilled, well-qualified professional editors. Put us in a bag, shake us up, and pull one of us out at random and you should get a good quality editing job. But that doesn’t bring me any business, and bringing in business is the name of the game. (If you haven’t read it, let me recommend my book, The Business of Editing. It is not enough to have editing skills, you must always be thinking and acting like a business.)
I always have the need to bring in future business in mind, so when I edit I look at the editing as a way to impress my client, and I look at queries as the way to both impress and communicate what makes me The Editor — the editor to hire for future projects and the editor to recommend to colleagues. Well-crafted, informative queries (just like emails and online posts) are like a billboard advertising my skills. Cryptic, curt queries undermine the image of professionalism that I want to project.
This does not mean that every query needs to be five sentences long or a dissertation on grammar. It does mean that every query must satisfy these criteria:
- be on point, not meandering
- identifies the problem and offers an appropriate solution
- reinforces my skills and expertise as an editor
- reinforces the correctness of the decision to hire me
- declares clearly my status as a professional editor
Every query that I write that fulfills those criteria sets me apart from my competition and says I am The Editor.
EditTools’ Insert Query Macro
Because writing queries can be time-consuming, it is a good idea to build query templates that require minor modification based on the circumstance and project. That is the premise behind EditTools’ Insert Query macro. I have numerous “standard” queries that are saved to a dataset and that I can call up and modify for a particular project. In addition, each project has its own custom queries. By using the Insert Query macro, I can minimize the time I need to spend inputting a query and the opportunity for inputting error. It also means that I can use more detailed queries because I do not have to retype the same query innumerable times.
Consider this query:
AQ: Using this type of time reference allows the time to shift. The shift occurs because the reference was made when you were writing the text but doesn’t allow for either editing and production time until publication or for the book’s expected several-year shelf-life or for the passage of time between the writing of the text and when it is read by a reader. It would be better to write, for example, “since 2000” (substitute the appropriate year), so that the time reference always remains static.
How long would it take you to type this query? How many times would you care to do so? With EditTools’ Insert Query macro, I typed it once into the dataset and now can either use it as is or modify it as needed, taking seconds rather than minutes and avoiding typing errors.
To get the most out of queries, think of queries as marketing tools.
Richard Adin, An American Editor
An American Editor 