Giving Feedback That Names the Work

A draft can contain a real problem without proving a story about the person who made it. “This status is unclear” and “you are careless” do different things. The first can point to work that can be examined. The second may turn a particular observation into a verdict the evidence cannot support.

This short educational handbook follows an invented workplace review from preparation to a checked revision and follow-up. It concerns ordinary feedback within an agreed role. It is not a formal appraisal procedure, employment advice or a technique guaranteed to make somebody grateful for criticism.

Mara and Dev are fictional colleagues. Mara has been asked to review Dev's one-page project report before a Wednesday ten o'clock internal briefing. She is not his manager. Eli, their manager, owns decisions about the reporting process. Mara's role is to review this draft and discuss any concerns with Dev, not assign him a performance rating.

The report contains three fictional projects. Cedar has customer acceptance recorded. Rowan is prepared for review but has not been accepted. Willow is still an internal draft. The word ready appears beside Rowan. Mara worries that somebody reading the report will think the project has already been accepted.

Her first private thought is that Dev has been careless again. Before repeating that sentence, she asks what she can actually point to. She has one draft, a status label and the relevant project records. She has not established an enduring trait or checked what Dev meant by the label.

Start your own review with a similarly clear boundary. What work are you asked and authorised to review? Which expectation is relevant? What specific item concerns you? A review of one document does not automatically become permission to investigate a colleague's private life, comment on every aspect of their work or conduct an informal disciplinary hearing.

Mara opens the report and the corresponding records. Cedar's row includes a reference to its acceptance record. Rowan's record shows that the prepared work still awaits review. Willow is described as an internal draft. Mara can now describe the particular discrepancy without calling all three rows wrong.

She drafts a sentence: in Rowan's row, ready does not tell me whether preparation or customer acceptance is complete. She adds what she needs to establish: how Dev intended the term and what the briefing audience is meant to infer. This is a question about an ambiguous label, not a finding that he deliberately misrepresented progress.

She does not add “you always do this.” Even if a pattern later needs attention, it requires its own evidence and appropriate process. A large accusation is not made accurate by attaching it to one small example. Nor does a genuine concern require an invented history to become worth discussing.

Mara also notices something worth keeping. Cedar's acceptance reference lets a reader check the claim. She can name that useful detail accurately. She does not need to invent praise as wrapping for the correction, or say that the whole report is excellent when she has a specific unresolved concern.

Before the conversation, she checks the review arrangement. Dev has agreed to discuss the draft privately at two on Tuesday. There is time to revise before Wednesday's briefing. The fifteen minutes they set aside are a practical choice in this example, not a universal feedback duration or a reason to hurry through an important unresolved issue.

For your own observation, separate what you saw, what you inferred and what you still need to ask. Keep private material out of the discussion unless genuinely needed and appropriately handled. Being specific does not mean collecting every possible detail about another person.

At two, Mara points to Rowan's row and asks what ready means there. Dev says he means ready for internal review, not accepted by the customer. He shows her the template the team has been using. Mara recognises it: she supplied that earlier template, and its ready label never defined which stage was complete.

That information changes the account. There is still an ambiguity to fix, but Mara cannot fairly describe it only as Dev ignoring a clear rule. She says that the template she provided left the term unclear. Owning her part is not an instruction to Dev to abandon responsibility for checking the report. It makes their description of the problem more accurate.

Dev says he would rather discuss such a concern privately than hear a guessed explanation in the group briefing. Mara agrees to keep this review within its proper setting. She does not promise that no work issue will ever need wider discussion. She can respect the particular conversation without inventing a universal secrecy rule.

She explains her concern: the current wording could be read as customer acceptance, whereas the record supports readiness for review. She has not observed an actual reader make that mistake, so she calls it a possible interpretation rather than a measured effect. Dev agrees the distinction should be clearer.

A real conversation may not end in agreement. The other person may identify a factual error in your review, disagree about the relevant standard or need time to respond. Listen and check what can be checked. Do not claim that neutral words guarantee a calm reaction, or treat immediate agreement as proof that you have been fair.

Some concerns involve safety, discrimination, harassment or formal performance matters. They may require the organisation's proper process and qualified support. This modest peer review must not replace those routes or turn serious concerns into a private wording exercise.

Mara and Dev draft more precise status descriptions: Prepared; Sent for review; Accepted. They discuss what each should mean in this team's report. Accepted will refer to recorded customer sign-off, not simply a file somebody feels happy with. The labels are a proposal until Eli approves the reporting change.

Dev will revise the three rows and the explanatory note. Cedar remains accepted, with its reference. Rowan is prepared for review and is not yet sent for that review in this example. Willow remains an internal draft. A clearer vocabulary must not move a project further along than the records allow.

Mara will review the revised report at four on Tuesday. Dev will ask Eli to approve the proposed labels and their definitions. They do not assume that Mara's seniority as a colleague gives her authority over the reporting process. The needed decision has a named owner outside this review conversation.

The revision concerns this report and its ambiguous terms. It is not a demand that Dev rebuild the team's whole system that afternoon or provide a defence of every previous report. If a wider problem needs action, identify it separately with the appropriate people and time rather than quietly adding it to a small correction.

Mara writes a brief account of what they agreed and lets Dev check it. It includes her responsibility for clarifying the old template. It does not describe him as resistant, careless or grateful. Those labels are unnecessary to explain the revision they will make.

For your feedback, make the next step concrete enough to revisit: what will change, who will do it, who must decide and what check follows? Respect limits of authority and capacity. A suggested change is not an approved change merely because it was expressed politely.

You can prepare a short note using five questions: Which work? What can I point to? What do I need to ask? What revision and decision are agreed? What did the follow-up show? This original aid is not a validated assessment scale, a branded feedback method or a replacement for an organisation's review procedure.

Mara's first answer names the one-page report for Wednesday's internal briefing. Her second points to Rowan's ready label and the record showing preparation without acceptance. It also preserves Cedar's useful acceptance reference. It does not call the entire report wrong or rate Dev's character.

The third asks what ready means and whether the existing template defined it. After the conversation she adds Dev's explanation and her own contribution to the ambiguity. The note must be able to change when new information arrives. Preparing it is not a way to lock your first interpretation in place.

The fourth records the proposed stage labels, Dev's revised rows and note, Mara's four o'clock check and Eli's approval role. It keeps a proposed process change distinct from one already accepted by the manager. It also keeps Willow's internal draft distinct from work actually prepared or sent for review.

The fifth stays open until the follow-up happens. Mara cannot fill it with “Dev understood and improved” simply because the conversation felt friendly. She needs to inspect the revised work and record the appropriate decision. A pleasant meeting is not the same as a completed correction.

Use only the parts that help you. Do not turn a small working note into an unofficial personnel dossier or keep private judgments that have no legitimate purpose. Apply the real information-handling and record rules relevant to your role. This handbook does not invent a retention period, legal entitlement or right to collect colleagues' information.

At four on Tuesday, Mara reads Dev's revision. Cedar is accepted with its supporting reference. Rowan is clearly prepared for review, not accepted or already sent. Willow remains an internal draft. The note explains the proposed stage meanings. Mara checks the wording against the project records rather than treating different labels alone as proof of accuracy.

At four-thirty, Eli approves the labels and definitions for the report. Dev updates the note to show that approval. The revised report is ready for Wednesday's briefing in the ordinary sense of being prepared for its intended use; that does not make Rowan an accepted customer project. The different uses of ready are no longer being left to guesswork in its status row.

Mara tells Dev exactly what she found useful: the revised Rowan description matches the record, and Cedar's acceptance reference remains easy to check. She does not say that he has become a completely different worker or that all future reports will be correct. Specific positive feedback can stay as bounded as a correction.

The following Tuesday they look at the next report. The stage descriptions are used with their supporting records. Mara records that observed follow-up without turning one later report into a verdict on Dev's entire performance. He can still have opinions about how the earlier conversation went; completion does not require him to praise her feedback.

For your own review, finish with the change you can actually see, the decision that was actually made and any issue still open. If your original observation was mistaken, correct it. If the revision is incomplete, describe the remaining work without inventing a motive. If a formal matter needs another process, say so and use it appropriately.

Feedback that names the work leaves room for evidence, another person's account and a checkable next step. In this example the report became clearer, the shared template problem was acknowledged and the actual manager approved the change. That is a complete, modest result. It needs neither a character label nor a promise that every difficult conversation will end the same way.

Primary OPM pages checked on 6 November 2026 provide bounded background. Intern-supervisor guidance discusses specific, factual feedback, listening and follow-up: https://www.opm.gov/intern/intern-supervisors

OPM's performance-management cycle describes ongoing feedback separately from formal rating: https://www.opm.gov/policy-data-oversight/performance-management/performance-management-cycle

These are US federal-workplace resources, not universal employment rules or evidence that this handbook's original five-question note has been validated. No current federal appraisal requirement, disciplinary rule, branded model, complete institutional checklist or guaranteed improvement claim is reproduced. The invented peer-review example does not grant managerial authority or substitute for applicable organisational processes.

Mara, Dev, Eli, the report, projects, records, dialogue, times and results are fictional. No real employee assessment, customer record or private workplace information is published. This is not legal, clinical or professional HR advice. Appropriate policies, duties and qualified support take priority where needed. No promotion, earnings, satisfaction, cooperation, calm reaction or future accuracy is guaranteed.

The complete short digital handbook and full Bengali, Hindi, Spanish, French and Arabic editions are AI-assisted original writing and translations with editorial review. The English front and back covers are original conceptual art. No independent human authorship, native-human certification, assigned ISBN or print proof is claimed.