How to receive feedback: from a difficult comment to a specific change

“You need to communicate your findings better.” That is what you hear after presenting a report you spent several days preparing. Your reply is already forming: there were charts, an explanation and a file with the calculations. You can defend your entire professional record, or find out what specifically the reader was missing. I would choose the second conversation, although the first can be tempting.

Receiving feedback involves several separate tasks. You need to hear the comment, understand its meaning, evaluate the evidence and choose an action. Emotions can make this harder, but difficulty alone does not establish whether the comment is correct. You can feel angry about an accurate observation and comfortable with a completely inaccurate assessment.

In my earlier Polish article, I arranged the process into six steps called 6P. In English, I describe them as paraphrase, process, position, probe, proceed and perspective. I retain the mnemonic as a practical aid for a conversation. I do not present it as a scientifically validated method or a recipe that repairs every workplace relationship.

All the dialogue and situations below are fictional educational examples. They are not quotations from clients or descriptions of a particular team. The main scenario concerns a sales-report review, but the same questions can help after a presentation, an assignment or a discussion about working together.

Identify what kind of comment you received

Feedback might concern an error, a preference, an expectation or the effect of your behaviour on others. “The table total does not match the data” can be checked through calculation. “I prefer bars to lines” requires a discussion about the chart’s purpose. “I need to hear about a blocker a day earlier” describes an expectation about collaboration. These statements do not call for identical responses.

I first establish the subject of the conversation. If the comment concerns accuracy, I check the result. If it concerns clarity, I ask the reader to show where they became confused. I do not turn every difference in preference into a technical mistake. Equally, I do not explain an incorrect calculation by saying that everyone has their own working style.

Sometimes a sentence contains several layers. “You keep doing reports your own way and nobody can use them” includes a judgement, a claim of repetition and a problem with usability. You can ask to separate those elements. That gives the conversation a chance to address a specific piece of work instead of becoming a broad case against your personality.

Paraphrase without inventing an accusation

Paraphrasing checks understanding. After “you need to communicate findings better”, I would avoid replying, “so you think I should not be an analyst?” That introduces a new claim. I would try: “I want to understand what was missing. Do you mean how I presented the main finding, or when you received the report?”

A useful paraphrase is shorter than a defence. It lets the other person correct a misunderstanding before you discuss solutions. If the answer is that the report arrived too late, continuing to explain the chart colours will not help much. The calculations may be sound while the timing of the communication creates the problem.

I also avoid politely agreeing with everything. Saying “I understand that this was your experience” does not mean confirming every factual detail. You can acknowledge the reader’s experience while wanting to verify the sequence of events. State that distinction explicitly so neither person has to guess which points were actually accepted.

Process your reaction and choose the moment

Not every answer needs to be immediate. If you are about to list everyone else’s mistakes since your first day, a short pause may be sensible. I would say: “I want to check this properly. I will come back to it today after reviewing the report version we are discussing.” The important part is returning to the conversation as agreed.

I separate my initial reaction from the decision. I can notice that a comment surprised me without concluding that it was unfair. I can also acknowledge a mistake without promising that everything will be perfect from now on. A meaningful correction requires understanding what happened and what allowed the problem to occur.

A pause should not become a way to defer the conversation indefinitely. If you ask for time, specify when you will return and what you will examine. A small error may require only a few minutes. Conflicting expectations may need a separate discussion. Choose the format according to the problem rather than an obligation to appear completely calm at every moment.

Consider position and access to information

The person giving feedback sees a particular part of your work. A manager may know what the reader expects but not the details of a data problem. A colleague may understand the code but not the decision deadline. A client sees the finished report without seeing internal agreements. I ask which observation supports the comment and what context might be missing.

I avoid trying to read the other person’s intentions. Instead of “they want to undermine me”, I check whether they can identify an example, whether they have the current version and whether the expected standard was agreed earlier. Those questions can be answered. Assigning motives without evidence often extends the argument without making the work clearer.

Hierarchy matters for decisions, but it does not replace evidence. A manager can specify a reporting format; that does not make an incorrect total correct. A less experienced colleague can identify an unclear definition. I neither dismiss nor automatically accept a comment solely because of the speaker’s job title. Their observation still needs to be understood on its own terms.

Probe for a specific example

With a general comment, I ask about the situation, behaviour and effect. That resembles the Situation-Behavior-Impact model described by the Center for Creative Leadership. A useful part of that model is its focus on observable behaviour without assigning intentions to the other person.

In our example, I ask which meeting lacked information, what I showed or omitted and what became harder as a result. The answer might be: “At Wednesday’s review, you showed a percentage change without the number of orders. We could not tell whether it represented a large group.” We now have a specific issue to evaluate and a concrete piece of work to inspect.

An important correction: I do not reject feedback merely because it conflicts with my self-image. That disagreement can itself deserve investigation. I look for evidence, additional context and alternative explanations. If a comment is inaccurate, I should be able to explain why. The thought “I do not work like that” does not settle what happened in a particular case.

A conversation after a report review

Imagine this exchange. The reader says, “Your reports are hard to understand.” The analyst replies, “Could you show me the part of the latest version where it was unclear what to do next?” The reader points to a chart of sales changes. It does not explain whether the comparison covers complete months or includes returns. Those are two checkable issues.

The analyst might say: “The definition including returns is on the second tab, but it is not visible beside this chart. The comparison uses complete months. I will put that information next to the result and show you a draft before the next meeting.” This acknowledges an accessibility problem without claiming that the entire calculation was incorrect.

Then the analyst asks about the expected result: “Do you also need the order count and a short explanation of the change on the first view?” If so, they agree on that revision. If the reader additionally requests a six-month forecast, a new assignment has appeared. Receiving feedback does not automatically mean accepting an unlimited expansion of the project.

Proceed with one observable change

A general resolution to “communicate better” is difficult to evaluate. I would translate it into a behaviour: in the next two reports, I place the definition, period and group size beside the main result. Before sending each report, I ask one person to explain how they understand it. This is a bounded trial that can be completed and discussed.

I do not change everything at once. If the feedback also concerns presentation speed, slide order and delivery timing, I agree on the most important element with the reader. Otherwise, two weeks later it becomes difficult to tell what helped and what merely added obligations. A small scope makes a specific difference and its cost easier to observe.

I record what I need from others too. Delivering a result earlier might require earlier data closure or an earlier decision about the definition. I do not promise a deadline the existing process cannot support. I propose a change with its dependencies, so the discussion concerns cooperation rather than placing every part of the responsibility on one individual.

Gain perspective after making the change

At the agreed time, I return with a specific question: “In the last two reports, I added the period, definition and group size next to the chart. Was it easier to evaluate the result? Where was context still missing?” This is more likely to produce useful information than asking whether I am now a better employee.

I also inspect the material itself. Was the information present in both versions? Could it be read on the meeting-room screen? Did the new description introduce another ambiguity? A good intention does not guarantee that the change reached the reader. It helps to examine the result in the conditions in which the other person uses it.

If the revision helped, I incorporate it into normal practice, perhaps through a report checklist. If it did not, I revisit the diagnosis. Perhaps the issue was the moment of delivery rather than missing context. An unsuccessful trial is information about the proposed solution. It indicates that I should adjust the approach or describe the underlying need more accurately.

Disagree using evidence

Suppose you hear, “You did not warn me about the delay.” You check the task history and find a message sent two days earlier. You can answer: “I added the information to the task on Tuesday; here is the link. I can see it did not reach you before the meeting. Let’s agree where I should flag that risk next time.”

This corrects the fact while recognising a communication problem. You do not need to accept a false chronology to have a constructive conversation. You also do not need to stop at a triumphant “I already told you.” If the objective was for a particular person to receive information, it is worth agreeing on an effective channel rather than merely proving your activity.

When expectations conflict, I ask for a decision. One person wants a short report; another wants a full explanation of exceptions. I can propose a main view with an appendix, but we still need to agree who accepts the work and against which standard. Trying to satisfy everyone without priorities can produce an endless sequence of contradictory revisions.

Separate the content from the delivery

Accurate information can be delivered unpleasantly. Inaccurate information can sound very polite. I try to assess these separately. I can investigate the reported mistake while asking to discuss a specific behaviour without personal labels. Accepting a correction does not require accepting every possible way of speaking to someone.

An example response is: “I will check the difference in the numbers. I also want us to refer to this table without calling me an irresponsible person.” If the discussion cannot reach the facts, I suggest another time or involving the person responsible for team cooperation. I do not promise that one well-phrased reply will change somebody else’s behaviour.

In a recurring conflict, I record specific events and agreements rather than a list of suspected intentions. That gives us something checkable to revisit. This article concerns everyday discussions about work. It does not require you to remain in every conversation at any cost or to repair the entire team’s working environment by yourself.

Written feedback needs context

A short task comment can be interpreted more broadly than intended. “Fix this” could refer to a label, the whole chart or an incorrect definition. Before rebuilding the report, I ask about the scope. For a complex disagreement, I suggest a short conversation and then record the agreed outcome in the same place as the work.

My note contains the problem, agreed change, deadline and way to check it. For example: “Add the period and definition of sales after returns beside the main chart; draft by Wednesday; review checks readability and consistency with the calculation.” This reduces the chance that, a week later, each person remembers a different version of the agreement.

I do not forward private conversations to an ever-growing audience simply to win an argument. I choose the working space and participants needed to resolve the assignment. When several people comment, I distinguish a recurring issue from several comments about one event. Three messages about the same chart are not three independent pieces of evidence about my general performance.

Ask for feedback that can help

Instead of sending the entire report with “what do you think?”, I identify a section and purpose. “Please check whether the first page makes the metric’s coverage and limitations understandable.” This helps the person choose where to focus. It also gives me information connected to a defined need rather than a collection of unrelated suggestions.

Ask someone who actually uses that kind of result. A SQL colleague can review the query. A business reader can assess whether the answer supports their next step. These perspectives complement each other. I do not expect one person to verify the code, validate the business definition and judge the usefulness of the whole analysis at the same time.

If you are building a portfolio, ask someone to reproduce one calculation and restate the conclusion in their own words. Notice where extra explanation was necessary. That gives you concrete material for improving the presentation. Establishing the project scope first will help; I explain that in the guide to planning a data analysis project.

An exercise for your next conversation

Take one recent comment and record its meaning without adding a judgement about your entire personality. Identify the situation, observed behaviour and effect, where known. Turn the gaps into questions for the speaker. Then choose one change you can actually make and agree when to return to the subject. Keep the exercise small enough to complete.

If you disagree, write down the evidence and an alternative explanation. If the problem is conflicting requirements, prepare a proposed priority. If information is missing, do not pretend to have a complete improvement plan. A useful answer can begin with an honest request for an example. That gives the conversation more substance than automatic apology or automatic defence.

You do not need to recite six steps during the next discussion. It is enough if they help move the conversation from an unclear assessment to an agreement you can verify. That is what I want from feedback: information I can act on, followed by a way to check whether the chosen change helped the work.