Give and receive feedback

Supports: Developer, weeks 4 to 6 (when you ask others to review your work), and the Master Developer review. Time: about two and a half hours. Rung on the agent ladder: use and delegate. Feedback to people stays with you.

1. Why this matters

People do better work when they know how they are doing. They stop doing good things when nobody notices, and they repeat mistakes when nobody says. Many managers still wait too long, because feedback feels uncomfortable for both people.

Waiting makes it worse. A small problem told today is a short, easy talk. The same problem told at the end of the quarter is a surprise, and a surprise feels like an attack. The Dojo rule from the stakeholder track applies to people too: no surprises.

Feedback also has a new reader. You now give feedback to agents all day, as review comments and changes to the brief. It works only when it is specific. A person also has feelings and a life outside work, so a person’s feedback needs care and an agent’s needs precision.

A Product Development Manager (PDM) gives feedback because nobody else holds the whole picture of the goal. An agent can help you prepare, by checking your wording or playing a role. It cannot know the person, the history or what a remark will mean to them. The conversation is yours.

What the PDM decides here

You decide	You may delegate to an agent	You verify	Other disciplines involved
What to say, to whom, when and where; whether the matter is praise, a small correction or a serious issue; what you will do next	Rehearsing a hard conversation with you; checking your draft for absolutes and blame; turning your review notes into clear comments for an agent	The feedback names a real situation and behaviour you saw; it has a next step; the person understood it; you did not share personal details with a tool that should not have them	People and legal advisers where work rules apply (serious problems need a proper process), privacy (no personal data in public tools), design and engineering (who judges the craft), operations (workload)

2. Key ideas, explained

Feedback describes; it does not judge

Compare two sentences.

• “You are careless with deadlines.”
• “On Tuesday the mockups were due at noon. They arrived on Thursday, and the café owner had already asked twice.”

The first is a judgement about the person. It is hard to hear and hard to act on. The second describes what happened. The person can agree, correct a fact or explain, and each is a useful start.

Situation, behaviour, effect

A simple form helps. GitLab’s public guide to feedback calls it Situation, Behaviour, Impact. We use three short parts:

1. Situation. When and where. “In Tuesday’s review.”
2. Behaviour. What you saw or heard, without guessing why. “You presented the new sign and did not mention the two risks you had told me about.”
3. Effect. What it caused, for the work, for you or for others. “The sponsor said afterwards that she felt the plan was safer than it is.”

Then add a fourth part, which is not in the name: a question or a next step. “What happened there?” or “Next time, can we list the risks on the first slide?”

Avoid the words “always” and “never”. They turn a single event into a trait, and the person will argue about the word and forget the event.

Praise is feedback too

Praise that says “good job” teaches nothing. Praise that names the situation, the behaviour and the effect tells the person what to do again. People repeat what they know was seen.

Prepare for a hard conversation

When the matter is hard, take ten minutes before you speak. The GitLab guide quotes four questions that come from the book Crucial Conversations, and they are useful: What do I want for myself? What do I want for the other person? What do I want for the relationship? How would I act if I wanted all three? If the honest answer to the first is “to win”, stop and think again.

Then:

• Pick a private place and time, not the end of a long day.
• Start with the situation, in one sentence. Do not start with praise as a trick to soften what follows. People notice.
• Say the behaviour and the effect. Stop. Listen.
• Ask questions. “How did it look from your side?” The GROW model from Google’s re:Work (Goal, Reality, Options, Will) is a useful frame: what do you want, what is happening, what could you do and what will you do.
• End with a next step that the other person chooses and says aloud, and a date to look again.
• Write two lines afterwards: what was said, what was agreed.

Differences in how people hear feedback

In some cultures, direct words show respect. In others, they feel rude. Some people want feedback in writing, others want to talk. The GitLab guide suggests getting to know the person before you push for directness. Ask: “How do you like to get feedback?” Then do that, and still say the true thing.

Trust comes first, and feedback builds it

Feedback is easier to hear where there is trust. GitLab’s page on building trust names three ingredients: empathy, respect and selflessness. Build trust with small acts, like doing what you said you would do, and start with small, task-based feedback before a harder one.

Google’s re:Work article “Following the data” lists coaching and clear communication among the behaviours of strong managers. It is Google’s own data about its own people, so use it as a prompt for reflection, not as proof about your team.

The one-to-one

A one-to-one is a regular private talk between you and one person on your team. It is the best place for feedback because there is already a time and a habit. A few ideas from GitLab’s public page on one-to-ones:

• Keep a shared written agenda, and let the other person put most items on it. If you fill more than half of it, something is wrong.
• Keep a steady rhythm, such as weekly, and do not cancel unless you must.
• Do not save feedback for the meeting. Give it close to the event, and use the meeting to go deeper.
• Keep the document private to the two of you.

Receiving feedback

You will receive feedback too, from a team member, a sponsor, a café owner or a user. It is hard to hear because the mind treats it as a threat. A few habits help.

• Listen to the end. Do not explain yet.
• Ask for an example. “Can you tell me when you saw this?”
• Say thank you and mean it. It is not agreement. It is thanks for the effort of saying it.
• Take time. “I want to think about it. Can we talk again on Friday?”
• Decide. Choose one or two things to change. Say which, and tell the giver. Doing nothing is also a decision, but say that too, and say why.

Looking back as a team

A team also needs a regular look back. Atlassian’s page on retrospectives describes a simple routine: what went well, what did not, what we will change. Keep it short and blame-free, and pick one change to try.

Feedback to agents

An agent does not need kindness. It needs a comment that changes the next result. A good comment:

• points to the exact place (“line 40 of the sign copy”);
• says what is wrong and why (“the sentence promises a refund; we never promised that”);
• says what you want instead (“remove the sentence”);
• and, when the same mistake will come again, goes into the brief or the project rules, so the agent does not need to be told twice.

Treat repeated mistakes as a sign that the brief or the rules have a gap. Fix the page, not only the output.

3. Step by step: your feedback routine

Step 1: Pick one person and one moment

Choose something you saw this week, good or not good. Write the situation in one sentence.

Step 2: Write the behaviour and the effect

Cut every word that judges the person (“lazy”, “careless”) or guesses a reason (“you obviously didn’t care”).

Step 3: Add a question or a next step

Step 4: Choose the time, the place and the form

A private talk, the one-to-one or a note? Serious problems, and anything about someone’s job, need a proper process and trained people in a real organisation. Do not improvise those.

Step 5: Say it, then stop

Say the first three parts in under a minute. Then listen before you reply.

Step 6: Agree one next step, in the other person’s words

Write it down, with a date, and keep two factual lines in your private notes.

Step 7: Give feedback to an agent the same day

After each agent task, write one comment that would change the next result. If you write the same comment twice, move it to the brief.

Step 8: Ask for feedback yourself

Once a month, ask each person: “What is one thing I could do differently to help you do better work?” Thank them. Act on one thing.

4. Worked example: TrailMug

TrailMug is fictional. The people are invented.

Feedback to a person. Ana, the part-time designer, delivered the café sign two days late, and the founder did not know until the café owner asked.

Situation: On Tuesday the café sign was due at noon. I heard on Thursday morning, from the café owner, that it was not ready. Behaviour: You did not tell me on Tuesday that it would be late. Effect: I was surprised in front of a café owner, and I could not give a new date. Question: What got in the way of telling me on Tuesday? And what could we change so that I hear on the day?

Ana said that she was waiting to finish a version she liked before writing, and that she had not wanted to send a message with bad news and no plan. The founder said she would rather have the bad news early, even without a plan. They agreed on one rule for the working agreements: “If you will miss a date, tell me the same day, even with no new date.” Ana wrote the rule herself.

Praise. The founder wrote: “On Friday you asked the café owner to show you a return instead of describing it. We learned that the lid is hard to open with one hand. That saved us from printing 200 signs with the wrong picture.” The number is an example, not real. Ana said she had not known that this had mattered.

Receiving feedback. The café owner, Leo, said: “Your emails feel like a form.” The founder did not defend herself. She asked for an example. Leo pointed to a message that began with three lines about TrailMug before the answer to his question. She thanked him, changed the template to put the answer first, and told him.

Feedback to an agent. The agent’s draft of the sign said: “Return your cup for a full refund.” TrailMug has no refund. The founder’s review comment:

Line 2 promises a refund. TrailMug has no refund. Replace it with: “Return your cup to any TrailMug café.” Check every other line for any promise of money or prizes and list them without changing them.

The same mistake came back the next day, from a different agent session. The founder added a line to the brief: “Never mention money, refunds, discounts or prizes. If a draft needs one, stop and ask.”

One-to-one agenda (excerpt).

Ana adds: sign print options. Founder adds: the date rule; one thing Ana would like me to do differently. Last time’s next step: the lid test with Sam. Done / not done.

5. Working with AI agents on this

Delegate:

• Rehearsal. “Play Ana, who has missed a deadline and is worried. I will say the first three parts of my feedback. Reply in two or three sentences. After each turn, tell me whether I judged her or described what happened.” Use made-up names, and do not paste private details about a real person into a tool your organisation has not approved for that.
• Checking wording. “Underline every absolute word (‘always’, ‘never’), every guess about why and every judgement of the person in this draft.”
• Turning notes into agent comments. “From these review notes, write one comment per issue, each with the place, the problem and what I want instead.”

Do yourself:

• Decide whether to give feedback, and what it is.
• Hold the conversation. Never send feedback about a person through an agent.
• Choose the next step with the person.
• Decide what you change after you receive feedback.
• Keep personal details out of tools that should not have them.

A brief you can adapt (for agent feedback):

Here are my notes from reviewing the agent's work on the café sign
(notes.md) and the project rules (rules.md). For each problem in the
notes, write one review comment with: where it is, what is wrong, why
it matters, and what I want instead. Then check rules.md: for each
problem, say whether a rule should already have prevented it, and if
not, draft one new rule of one sentence. Do not edit any file.

How to check the output. Read each comment as the receiving agent. Could it act without a question? Does each new rule match a real problem that you saw? Reject any rule that is not tied to something that happened.

Where this sits on the ladder. Rehearsal and wording checks are use. Turning your review notes into comments and rule drafts is delegate: you hand over a task and read the result. Moving repeated comments into written rules is a first step towards govern: the rule now applies to every session, and it keeps working when you are not watching. Feedback to a person is not a rung. It stays with you.

Disclose. If an agent helped you prepare, you do not need to tell the person in the room. If you used an agent to write any written feedback, you should say so, and a person reads it before it goes.

6. Common mistakes

• Judging the person. “You are unreliable” is hard to hear. “The report was due Monday and came Wednesday” is not.
• Guessing why. You do not know the reason. Ask.
• The compliment sandwich. Praise used as a wrapper is easy to see and makes later praise worthless. Say the praise when it is true, and say the correction when it is needed.
• Defending yourself when you receive feedback. Ask for an example and say thank you.
• Vague comments to agents. “Make it better” produces a different guess. Fix the brief too, or the mistake returns.
• Sharing personal details about a real person with a tool that should not have them.

7. Practice: three pieces of feedback and a one-to-one

Deliverable: in your git repository, in a folder team/feedback/:

1. praise.md: one piece of praise in the situation, behaviour and effect form, about a real or realistic event.
2. correction.md: one piece of correction in the form with a question or next step. Use a realistic event and invented names if you work alone.
3. agent-comments.md: three review comments for an agent about a real piece of its work, each with the place, the problem, why and what you want. Add one rule you moved into the project rules, and the mistake that caused it.
4. one-to-one-agenda.md: a shared agenda with room for both people’s items and for last time’s next steps.
5. received.md: one piece of feedback you received, what you did in the moment, what you decided and what you told the giver.
6. Your AI-use line.

Commit with a message such as Add feedback examples and one-to-one agenda.

Check: give correction.md to a colleague and ask: “What happened, what effect did it have and what is the next step?” If they cannot say all three, rewrite it.

8. Checklist

• My feedback names a situation and a behaviour I saw, not a judgement.
• It says the effect and ends with a question or a next step.
• I avoided “always” and “never”.
• I gave praise in the same form.
• I prepared before a hard conversation and chose a good time and place.
• The one-to-one has a shared agenda and a steady rhythm.
• I listened to feedback to the end and said thank you.
• My comments to agents name the place, the problem and what I want.
• Repeated comments became rules.
• No personal details about a real person went to a tool that should not have them.
• I recorded my AI use.

9. Further learning

GitLab’s public guide on feedback is the main source for the situation, behaviour and effect form, and its pages on one-to-ones and building trust show how one company runs these habits openly. Google’s re:Work guide on coaching with the GROW model gives a four-step shape for conversations, and its article on the research behind great managers shows what one company measured. Atlassian’s retrospective guide helps you run a regular look back. MIT’s open course on management communication lets you practise writing and speaking to a specific reader. Next, run a team of people and agents, where direction, expectations and feedback meet the work agents do.