Feedback

Feedback

Before Starting

Check for EM context first:

1. Read .agents/em-context.md if it exists
2. If a person is mentioned, look for .agents/reports/[name].md — it may contain their feedback preferences, prior feedback history, and working style
3. Use that context — only ask for information not already covered

If .agents/em-context.md does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.

If a specific person is central to the conversation and .agents/reports/[name].md does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update .agents/em-context.md or .agents/reports/[name].md automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

Response Style

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.

Default to:

• State the likely diagnosis or recommendation first
• Ask at most 2-3 targeted questions only if the missing context changes the advice
• Give the next concrete action and, when useful, exact wording the manager can use
• Mention the relevant framework briefly, but do not explain every part of it
• Offer a deeper version only after the direct answer

---

How to Use This Skill

Identify what the user needs before diving into frameworks:

• Giving positive feedback → Go to Precision: No Weasel Words — it applies equally to praise
• Constructive feedback — know the issue but not how to open → Opening a Critical Feedback Conversation, then Instead of the Compliment Sandwich
• Expecting resistance or pushback → Behavior Change Stages first
• Something happened recently and the user wants to address it now → In-the-Moment Feedback (don't save it for the 1:1)
• Building feedback culture across the whole team → Speed Feedback
• Writing feedback for a review or document → Precision section first; then ask for the specific events to document
• Building a lightweight weekly accountability loop with reports → read references/extended.md — Weekly Called Shots
• Getting honest feedback from your own team → Getting Feedback from Your Team

If the user hasn't given you a specific event yet, ask for it. Vague feedback inputs always produce vague feedback outputs.

---

Default Response Shape

When helping with feedback, produce wording the manager can actually say:

1. Intent: what outcome the feedback should create.
2. SBI draft: situation, behavior, impact, in concrete language.
3. Opening line: a direct but humane start to the conversation.
4. Follow-up question: invite their perspective without softening the message.
5. Next step: request, agreement, or observation period.

For praise, keep it specific. For corrective feedback, do not hide the message inside a compliment sandwich.

---

Precision: No Weasel Words

The most common feedback mistake is vagueness. "You're too blunt in meetings" or "your communication needs improvement" — these feel like feedback but give the person nothing to act on. They're also easy to dismiss: "I don't think I'm blunt."

Specific feedback is factual and indisputable.

Weak: "You're too blunt in meetings." Specific: "In the meeting with Christopher, you cut him off when he started suggesting the React-based solution. We missed an opportunity to check more approaches. I also noticed that Christopher stopped contributing to other meetings after that."

The specific version names the event, the person affected, and the downstream consequence. The other person can't dispute the facts — they can only engage with what happened.

Apply this same standard to positive feedback. "You did a great job" is forgettable. "The way you handled the incident on Thursday — staying calm, communicating clearly to stakeholders while the team debugged — that's exactly what we need in situations like that" is memorable and repeatable.

Before giving feedback, do the homework. Identify the specific event, the specific behavior, and the specific impact. Vague feedback isn't kind — it's just unprepared.

---

Public Praise Isn't Universal

"Praise in public, criticize in private" is standard management advice. The first half isn't always true.

Some engineers genuinely don't want to be called out in front of the team. They prefer private acknowledgment. Surprising them with public praise — a Slack shoutout, a nomination for a recognition program — can create awkwardness instead of motivation.

Ask before you assume. A simple "How do you prefer to be recognized when you do great work?" in a 1:1 is enough.

---

Translating Social Cues

Not everyone can read a room. If you're good at this, part of your job is translating for those who aren't.

When a team member says something that lands badly and doesn't notice — upset someone, came across as dismissive, answered too abruptly in a meeting — tell them privately. Not as criticism, but as information: "I think that landed differently than you intended. Here's what I noticed." They often don't know. Telling them is the most useful thing you can do.

---

Behavior Change Stages

When addressing a performance or behavior problem, people typically move through three stages before accepting feedback:

1. Ignore — they don't acknowledge the problem exists
2. Deny — they actively push back ("That's not true" / "You're wrong")
3. Blame others — they redirect responsibility elsewhere

In a single 1:1, you can often move someone through all three stages. The right response at each stage is different:

• At Ignore/Deny: bring specific facts. Don't argue — present evidence calmly.
• At Blame: don't let them escape into it. Acknowledge partial truths, then redirect back to what they can control.

The goal isn't to win the argument — it's to get to a point where the person can own the problem.

---

Instead of the Compliment Sandwich

Starting with a compliment and ending with one — sandwiching criticism in between — backfires in two ways: the opening compliment feels insincere (they're braced for the hit), and the closing compliment can bury the critique due to recency effects.

Four steps that work better (from Adam Grant, based on research):

1. Explain why you're giving the feedback. Signal that you're on their side: "I'm giving you this because I have high expectations and I know you can reach them." It's harder to reject a hard truth from someone who believes in you.
2. Take yourself off a pedestal. Reduce the power asymmetry: "I've benefited from people giving me tough feedback — I'm trying to pay that forward." It makes the feedback less threatening.
3. Give the criticism directly. No burying. Say the specific thing, the specific event, the specific impact.
4. Invite them to respond. Ask what they think. Let them engage, not just receive.

---