Feedback Frameworks

Feedback Frameworks: COIN + SOLID

Use this skill when the user is preparing or rehearsing feedback for another person. Two complementary models: COIN gives a stepwise structure for what to say; SOLID is a quality checklist that runs over the result.

Default workflow: draft with COIN → check against SOLID → revise.

User profile: If ~/bettersense-work-reflections/profile.md exists, read it before drafting. It carries the user's communication style and directness preference — calibrate the COIN draft accordingly (some users want directness up front; others lead with more relationship work). The profile also surfaces the user's role context, which shapes whether the recipient is a peer, report, or upward stakeholder.

Evidence from reflections: If the feedback recipient is a registered stakeholder (check ~/bettersense-work-reflections/stakeholders.json), read their <category>/<slug>.md before drafting. Past dated entries are exactly what COIN's Observation step needs — specific, dated, firsthand incidents instead of the vague "lately you've been…" the user is drafting from memory. Offer what you find: "Your reflections have two dated examples of this pattern — the standup interruption on June 3 and the design-review comment on June 19. Want to build the Observation on those?" This also strengthens the SOLID pass: entries logged near the event are firsthand and specific by construction, and a pattern claim backed by three dated entries survives a defensive "that was one time" in a way memory doesn't. Never import an entry the user marked as secondhand — SOLID drops it anyway.

Exit signals

If the user says "stop", "exit", "I'm done", "skip this", "pause", or similar — stop immediately. Share whatever has been drafted so far (even a partial COIN) and end cleanly. Don't push through the rest of the framework.

In the opening message, after confirming the situation, add one short sentence: "You can say 'stop' at any time and I'll share whatever we've drafted so far."

When to use this skill

Trigger phrases include:

• "How do I tell my report that…"
• "I need to give feedback on…"
• "Help me draft my 360 review for…"
• "I have a hard 1:1 tomorrow about…"
• "Can you review this feedback I'm about to send?"
• Any draft of feedback shared by the user, even if they didn't explicitly ask for help.

If the user just wants to vent or process emotions, ask before applying the framework — feedback frameworks are for moments of intent, not moments of frustration.

Before drafting: ask three questions

Before structuring the feedback, the user needs to answer (out loud or to themselves):

1. Is this solicited, or am I about to ambush them? If unsolicited, plan how to ask permission first ("Do you have ten minutes for some feedback on yesterday's review?").
2. Did I observe this directly? Hearsay weakens feedback fast. If it's secondhand, name it as such or talk to the firsthand source instead.
3. What outcome do I want? Behavior change, repair, recognition, alignment? The frame determines tone.

If any answer is shaky, surface that to the user before drafting.

Part 1: COIN — the structure

Anna Carroll's model from The Feedback Imperative. Four stages, in order. Some implementations swap "Connection" for "Context"; either is fine, and both can be used together.

C — Connection / Context

Don't open cold. Establish a brief connection (genuine check-in, not performative small talk) and signal the topic so the recipient isn't blindsided.

Examples:

• "Got a few minutes? I wanted to talk a bit about yesterday's stakeholder review."
• "You've been heads-down on the migration for weeks now and I noticed something I want to flag while it's fresh."

Avoid: theatrical preambles, sandwiching praise as a setup ("I love working with you, BUT…"), or burying the topic so deep the recipient is anxious before you've even started.

O — Observation

State what you saw, in neutral, factual language. No labels, no characterizations, no "you always / you never."

• Bad: "You were distracted in the meeting."
• Good: "During the half-hour review, I noticed you were on your phone for several stretches and missed two questions directed at you."

If the user's draft contains adjectives about the person ("you were dismissive", "you came across as defensive"), rewrite to describe the behavior ("you cut in twice before they finished their point", "your reply was 'that won't work' before they'd given the rationale").

I — Impact

Connect the observed behavior to a concrete outcome — on the work, the team, stakeholders, the strategy, or the person's own goals. If there's no current impact but a likely future one, say so explicitly.

• "Because the spec was a day late, the iOS team had to push their sprint planning, and we lost the early QA window we were counting on."
• "Your push for the smaller scope is the reason we hit the date — that's exactly the kind of judgment call I'd love to see more of."
• "There's no impact yet, but if this pattern continues into next quarter's planning, we'll likely miss the architecture review window."

Tie impact to behavior, never to identity. "This decision delayed the release" — not "You're a delay."

N — Next Steps

End with a path forward, co-created with the recipient. Carroll's emphasis: "getting active involvement in this discussion is important because it increases the team-member's commitment to the goal."

This is dialogue, not a directive. Bring a suggestion, but invite alternatives:

• "One thing that might help is X — but I want to hear what you think would work."
• "What support from me would make this easier?"

Land on something specific enough to recognize next time: a concrete behavior, a check-in cadence, or a measurable change.

Part 2: SOLID — the quality check

Voohy's checklist. After drafting with COIN, run the draft through SOLID. The goal isn't to hit every letter perfectly every time — async written feedback often can't be a "dialogue" in the moment — but to consciously notice what's missing and decide whether to address it.

S — Specific, Sincere, Solicited

• Specific: Named incidents, dates, behaviors. No generalities ("you're always late", "you're great at this") without examples.
• Sincere: The recipient should feel that the feedback is given from care, not score-settling. If the user is angry, delay; angry feedback rarely lands.
• Solicited: Did they agree to receive feedback now? In a 360 or formal review, it's implicit. In hallway moments, ask first.

O — Objective, first-hand observation

• Strip subjective interpretation from the observation step.
• Flag any secondhand input as such, or replace it with a direct conversation with the firsthand source.

L — Learning-focused, Logical

• Frame the feedback so the recipient can learn from it. If there's nothing for them to take away — if it's purely venting or signaling — reconsider giving it.
• Make sure the chain of reasoning (observation → impact → request) actually holds together. Emotional logic doesn't survive contact with a thoughtful recipient.

I — Impact discussed

• Did the draft say what changed (or will change) because of the behavior? If not, add it. The impact step is what makes feedback feel consequential rather than nitpicky.

D — Direct, Dialogue-based

• Direct: No burying the lede, no excessive softening. Most recipients prefer directness when sincerity is established. If the user's draft hedges so much the point is buried, surface that.
• Dialogue: Where possible, the conversation should leave room for the recipient to respond, push back, or co-create the next steps. In async written feedback, this can mean an explicit invitation: "Happy to talk through any of this — let me know what lands and what doesn't."

How to help the user

When the user shares a draft or describes a situation:

1. Diagnose the situation first. Ask the three pre-questions above if they aren't already clear.
2. Produce or revise a COIN-structured draft. Show the four parts clearly labeled (or inline with explanation) so the user can see the scaffolding.
3. Run SOLID over the draft. For each letter, note: hit / partial / missing, and why. Suggest concrete edits for anything missing.
4. Offer one revised version. Don't make the user piece together the edits themselves.
5. Flag traps. Common ones: feedback that's actually about the giver's frustration; identity-level statements ("you're disorganized") masquerading as behavioral ones; "feedback" that's really an instruction with no room for dialogue; praise so vague it can't be repeated ("great job!").

A worked example

User says: "My senior engineer keeps shutting down juniors in standup. I want to tell him to stop being so dismissive."

Diagnose: Did the user observe this directly? (Yes.) Solicited? (No — they need to ask for a 1:1.) Outcome wanted? (Behavior change, preserved relationship.)

COIN draft:

• Connection: "Got fifteen minutes this afternoon? I want to talk through something I noticed in standup this week."
• Observation: "In Tuesday's and Thursday's standup, when Priya and Alex shared their approaches, you cut in within a few seconds with 'that won't work' before they finished. Tuesday's was about the cache layer, Thursday's about the migration order."
• Impact: "Two things: the juniors stopped volunteering ideas for the rest of the meeting, and we may have lost a real option — Priya's approach turned out to be what the architect recommended later. The pattern is starting to shape what people bring to the room."
• Next steps: "I'd like us to find a version of this that keeps your judgment in the room without closing the door early. One option is holding the first reaction for thirty seconds. What feels workable to you?"

SOLID check:

• S — specific incidents ✓, sincere ✓, solicited (will be, once the 1:1 is set) ✓
• O — first-hand ✓, observation phrased as behavior not character ✓
• L — clear learning angle (judgment + room for ideas) ✓
• I — impact on team behavior + a concrete missed-option example ✓
• D — direct (names the behavior plainly), dialogue (asks "what feels workable") ✓

Deliver.