Five Tips for Giving Developmental Feedback

Developmental editing is big-picture editing. Dev editors rarely look at grammar, punctuation, or even awkward sentence structure.* Instead, dev editors look at issues like plot structure, character consistency, and whether the climax fulfills all the promises the author made earlier in the story. While test readers report any issues they had with a story, fixing those issues is a dev editor’s job.

I can’t teach you how to dev edit in one post. Instead, we’ll look at tips I wish someone had given me when I first started dev editing* and that I wish someone had given some of the dev editors I’ve worked with as an author.   

1. Ask What the Author Is Trying to Do

You’ve just finished reading a story about two exes working together against a common enemy. It has plenty of romantic tension, but at the end the exes don’t get back together. That’s not fulfilling the story’s implicit promise, so you fire off a note to the author about how the story is great, but the exes should have a scene where they get back together at the end. Everything should be fine, except now your author is freaking out. The exes not getting back together was the whole point! The author was making a statement, just not well. Now they’re convinced you don’t understand their work.

To avoid scenarios like the one above, it’s important to clarify what the author is trying to do before you give any feedback. The ideas in the author’s head may not match what’s written down, but that doesn’t make them any less important. Comb carefully through the story, and note anything that doesn’t make sense to you. You notice that the queen has disappeared after the first couple chapters, so you ask the author what they think happened to her. It turns out the author wanted the queen to die in chapter two, but the description they used was too vague to bring that across.

Since you want as clear an idea of the author’s intent as possible, ask any questions that occur to you. Authors usually enjoy talking about their work, so they won’t mind. Even if no question reveals a misunderstanding between you and the author, the time is a well spent precaution. At worst, the author spends some time thinking about their story and now understands it better.

In the original scenario, you can now provide recommendations on how the author should deliberately subvert audience expectations that the exes will get back together. You suggest a scene where they almost kiss but then point guns at each other instead, to the delight of all. Instead of being upset that you don’t understand their work, the author will love you and probably say nice things about you to all their author friends.

2. Start With Genuine Praise

You’ve read your author’s story with a critical eye, and you see the problems that must be fixed. Major plots go nowhere, characters completely change personalities without a word of explanation, and the ending just fizzles out. Your queries are clear and succinct; you’re ready for the hard work of fixing this baby up. You fire off your feedback to the author and wait. Nothing. Your author never responds, and if you listen carefully, you can hear sobbing through the internet.

Many authors have serious problems with self-esteem when it comes to their stories. They get emotionally invested in their work, which is often the only way to finish a story. Critical feedback, no matter how polite and constructive, hurts. It’s being told the thing they put all of their heart and effort into isn’t good enough. This doesn’t make critical feedback any less necessary, but it does require special consideration if you don’t want to make the author shut down forever.

The most useful thing a dev editor can do to keep an author’s spirits up is start with praise. Find the elements you really liked about the story and talk about them. A few sentences about how the author does a great job describing space battles will do wonders before you dive into why the main character is too flat. Some editors may see this as coddling, but it’s a necessary part of the process. Veteran writers can eventually grow confident enough that they no longer require such validation, but the vast majority will not be there yet.

Remember: It is absolutely vital that the praise be genuine. If you start making up nice things to say, the author will eventually see through it and then feel like they can’t trust you anymore. Even if the story is in really rough shape, search through it until you find at least one thing you like. It can be a small thing, but even the worst stories usually have a bright spot somewhere. Maybe otherwise dull characters have a touching scene together near the end or the author perfectly captures the description of a sunset while everything else is boring and flat. Read until you find something!

3. Don’t Make Jokes

In looking over your author’s story, you notice that the characters keep delivering clunky, exposition-heavy dialogue. By the tenth time you point this out, it’s gotten rather dull, so you add “As you know, Mr. Plot,” to your comment, just to keep things light. Next time you speak with your author, they act all surly and barely respond to anything you say. What happened?

Editors are naturally funny and witty people,* but a dev edit is not the place to exercise that wit. In fact, this is good advice for any stage of editing that involves communication with the author. Remember, authors are not looking at your comments through an objective lens. Even if a joke is hilarious, it’s too easy for the author to interpret it as cutting, and then they shut down.

Alternatively, an author may simply misunderstand a joke. If their story features three anthropomorphic pigs, and you joke that it should also include a big bad wolf, the author might misread that as legitimate feedback and start trying to incorporate a big bad wolf. By the time you straighten out the confusion, a lot of time and effort has been wasted. Editing is all about clarity, and since you don’t know how an author will interpret your jokes, it’s best to leave them out entirely.

The only caveat is for editors and authors who have worked together for a long time—years, at least. By that point, you can develop the rapport needed for the author to know you’re joking, and you’ll in turn know what jokes will make the author smile rather than sending them into a funk.

4. Know If You Should Give Suggestions

Okay, you’ve asked questions and written feedback that starts with praise and doesn’t contain any jokes. In fact, you’ve really done your homework, and your feedback includes detailed suggestions on how the author can solve all the problems you’ve found. Next thing you know, the author is chewing your ear off about how this is their work, not yours: you don’t get to write it!

Alternatively, maybe you only pointed out the the story’s problems and left it completely up to the author to solve those problems. After all, it’s the author’s story, not yours. Now you never hear from the author again as they stare blankly at a list of issues they don’t know how to fix.

Suggesting solutions is a delicate matter for dev editors, and every author requires a different approach. Some authors will see your suggestions as trespassing on their sacred storytelling rights. They only want to know what’s wrong with the story, and then they’ll go out and forge solutions alone. Other authors absolutely need your suggestions. They don’t know a way forward on their own. Still others will be happy to see your suggestions and then go off to make their own changes.

It’s vital to know what kind of author you’re dealing with. The best way is to simply ask them upfront at the same time you’re asking about the story in general. If the author is reasonable, they’ll tell you the style they prefer, and that’ll be the end of the matter.

Of course, it’s not always that simple. Some authors will say they don’t want suggestions, but they will be unable to make changes without them. Others will insist suggestions are welcome and then argue ceaselessly about any you give. In a perfect world, we wouldn’t work with unreasonable authors, but red pens won’t buy themselves. You’ll get a sense for what style suits an author best the more you work with them, but early on it’s best to err on the side of more suggestions. It’s easier for a writer who doesn’t need suggestions to ignore them than it is for an author who does need suggestions to work without them.

Just remember that suggestions are not a replacement for articulating the problem they’re designed to solve. If you don’t believe the protagonist would turn on their best friend like your author has written, don’t just leave a note saying “doesn’t match their character” and then a suggested alternative. Explain why the protagonist’s characterization makes their treachery unbelievable, and then suggest possible fixes.

5. Learn From Reader Feedback

You’ve gotten over the first few hurdles, and it’s time to send the story out to test readers. You’re confident, because both you and your author worked really hard on this piece. One of your big accomplishments was convincing the author to change the ending of their supernatural thriller so that the existence of ghosts was left as an open question. It fit much better with the story’s questioning atmosphere, and who doesn’t love a little mystery at the end?

Then you get feedback from the readers, and they are unified in their dissatisfaction with the ending. They love the spooky story, but they want to know: were the ghosts real or not? None of them are happy with the uncertainty.

So, what happened? An unavoidable part of developmental editing, that’s what. As a dev editor, you must make the best guess possible about what changes will make the story better, but you’re still a human being. Your personal preferences are influenced by millions of factors, and you can’t be aware of them all. Sometimes, that means recommendations you make will not improve a story in the eyes of most readers.

This doesn’t mean that a single response from a test reader invalidates your edits. Neither does it mean you should aim for popularity at all costs. Social justice themes are hugely unpopular with large groups of people, but that doesn’t mean you should get rid of them. But if test readers consistently clash with you on something, it’s time to examine why you wanted it in the first place. If you recommended the author cut down on the number of ship battles in their story because the battles are boring, but the test readers all want more ship battles, you might just have a bias against ship battles.

It’s vital for dev editors to know their own biases, and following the feedback of test readers is a great way to learn. Even if your contract with the writer is at an end, it’s worth your time to follow a story as it flows toward publication. This is also a great way to recoup some value if you’re working on a project for free, so keep it in mind for those occasions when you exchange favors with your writer friends.  

---

Authors and stories can be very fragile, and it’s up to an editor to know how to handle them. Developmental editors in particular have their work cut out for them, because they ask for the most difficult changes. While some writers will fight you over a single comma, it’s far more likely for battles to be had over the fate of an important side-character or how much of a romance scene to cut. As such, dev editors must know how to give their feedback so it will have the greatest impact and avoid any adversarial relationships with their author.