Why Feedback Order Matters: A System for Document Review

Bad document feedback was the bane of my existence at the State Department. (We always talked about "happy to glad" changes). You've probably seen this happen. Someone sends a draft for review. The first reviewer opens it, spots a comma splice on page one, fixes it, notices an awkward phrase on page two, rewrites it, flags a structural problem on page three, catches another typo, and drops a comment at the bottom of the document that says that the paper missed the original intent and probably needs to be rewritten. Meanwhile, several other colleagues are in, rewriting prose.

This is predictable and preventable. Without guidance or training, people tend to give feedback in the order they notice it, which is the order they read — left to right, top to bottom. That means structural problems get flagged alongside spelling errors, and the author has no way to tell which ones matter more.

This has costs. First, it wastes time polishing text that later gets rewritten or deleted. Second, it distracts everyone. When everything looks equally broken, easy local fixes get done while hard structural questions get deferred.

The fix is separating feedback by scope of impact and working from largest to smallest.

Three Tiers of Concern

Higher order concerns determine whether the document works at all. Is the central argument clear? Does the structure make sense? Does it actually answer the question being asked? If a proposal doesn't respond to the RFP requirements, no amount of elegant prose saves it. These are the make-or-break issues.

Middle order concerns affect how sections work together. Transitions between ideas, how evidence is introduced and explained, whether the tone stays consistent, whether the background section is three times longer than the recommendations. The document might have the right argument and structure, but individual sections don't quite connect.

Lower order concerns are what most people think of as "editing." Grammar, spelling, word choice, formatting. These matter for professionalism and clarity — but only in text that's going to survive.

The principle: always work top-down. Higher order first, middle order second, lower order last.

Why Order Matters

Changes at higher levels cascade down. If you restructure the argument, sections move or get cut. If sections move, transitions need rewriting. If transitions change, paragraph structure shifts. If paragraphs get rewritten, every comma splice you fixed in the original version is gone.

Working bottom-up means constant rework. Working top-down means each level of polish lands on stable text. This sounds obvious when stated plainly. But watch what happens in practice. A reviewer sees a typo and thinks "that takes two seconds to fix." True — but flagging it pulls the author's attention toward local cleanup and away from the structural question three pages later that actually determines whether the document succeeds.

💡 This works for AI output too. The same mistake shows up when reviewing AI-generated content — people edit sentences ("make this more concise") while the argument is wrong or the structure doesn't serve the audience. Check higher order concerns first: Did it understand the purpose? Is the structure right? Only then refine at the sentence level. Scope of impact determines sequence, whether you're reviewing a colleague's draft or an AI's output.

Making It Practical

If you're giving feedback, label the level. A simple tag — [HOC], [MOC], [LOC] — tells the author where to focus first. "The structure assumes the reader already knows our methodology" hits differently when it's clearly flagged as a higher order concern rather than buried between two typo fixes.

If you're requesting feedback, specify what you need. Early drafts: "Focus on higher order concerns only — is the argument right?" Middle drafts: "Structure is locked, focus on section flow and transitions." Final drafts: "Just need a proofread before submission." This prevents reviewers from spending time on issues you'll address anyway.

If you're running a team review, consider separate passes. Structural review first — does this answer the question? Content review second — do sections connect? Polish last — grammar, formatting, cleanup. Different reviewers might handle different passes. Subject matter experts for structure; strong writers for polish.

The Objection You're Already Thinking

"But the typo is right there. It takes two seconds."

Fair. If you must note it, put it in a clearly separated section at the end of your feedback. Don't let easy fixes crowd out hard ones. The goal isn't to ignore lower order issues — it's to ensure they don't consume attention that should go to structural questions first.

And if the prose is genuinely so rough that you can't evaluate the argument? That's itself a higher order concern: "This draft isn't ready for structural review." Say that directly. But be honest about whether the writing is truly unreadable or just unpolished. Those are different problems.

The Shift

When teams internalize the hierarchy — higher order, then middle, then lower — communications and workflow patterns change. Authors write with structure in mind from the start. Reviewers give feedback that helps rather than overwhelms. And everyone stops wasting time polishing text that's about to be rewritten.

For a quick-reference version of the feedback tiers, labeling format, and decision guide, see the Document Feedback Reference Sheet