performance-feedback-author
Build-an-X workflow that drafts evidence-based performance feedback and review input for testers using the Center for Creative Leadership's SBI model (Situation - Behavior - Impact, extended to SBII with Intent) - pulling every Behavior statement from verifiable work artifacts (bug reports authored, test cases and automation merged, review comments, charter session logs) rather than impressions or adjectives. Distinct from `tester-one-on-one-planner` (sibling skill that plans the recurring conversation where this feedback is delivered), from `skill-matrix-author` (team capability map kept deliberately separate from performance data), and from `hiring-rubric-author` in qa-hiring (scores external candidates, not current team members). Use when a QA manager owes someone specific feedback this week, or when writing review input or a promotion case for review season.
performance-feedback-author
Overview
Most performance feedback fails on the same axis: it describes the manager's impression ("not detail-oriented enough", "great team player") instead of the person's behavior, so the recipient can neither verify it nor act on it. The Center for Creative Leadership's SBI model fixes the shape: clarify the Situation with a precise time and place rather than a vague window ("this morning at the 11 am team meeting", not "last week"); describe the specific observable Behaviors without judgment (someone "interrupted me while I was telling the team about the monthly budget", not someone "was rude"); explain the Impact the behavior had, including the genuine effect on you ("impressed", "frustrated", "troubled"). CCL extends it to SBII by adding an Intent inquiry - asking "What were you hoping to accomplish with that?" - which turns delivery into a two-way conversation and replaces negative assumptions about motive. CCL's claim for the format is practical: it "reduces anxiety around giving feedback" and decreases defensiveness in recipients. (All of the above: CCL, "Closing the Gap Between Intent vs. Impact: SBII", fetched 2026-06-10.)
This skill adds the QA-specific half: in a testing team, the Behavior component should come from work artifacts, which are abundant and citable - bug reports, test cases, automation PRs, review comments, charter logs, CI history. Feedback built on artifacts survives challenge; feedback built on recollection does not.
When to use
Do not use this skill to:
Step 1 - Capture the inputs
| Input | Notes |
|---|---|
| Subject + window | Tester, and the period the feedback covers (a single event, a sprint, a review half-year) |
| Artifact access | Bug tracker (reports authored, triage quality), test management tool or repo (test cases, charters), code review system (comments given and received), CI history |
| Purpose | One of: immediate feedback / review input / promotion case - the same evidence, three different output shapes (Step 4) |
| Ladder criteria | For review input and promotion cases: the level's evidence list from career-ladder-author |
Step 2 - Mine the artifacts for Behavior candidates
For each feedback theme, locate the artifact before writing a word. QA work leaves a wide evidence trail:
| Artifact class | What it evidences | Where |
|---|---|---|
| Bug reports authored | Investigation depth, reproduction quality, severity judgment | Tracker query: reporter = subject, window |
| Test cases / charters | Coverage thinking, technique application, edge-case instinct | Test management tool, charter log |
| Automation PRs | Code quality, flake-rate of authored tests, harness contributions | Repo history, CI pass-rate per test author |
| Review comments given | Teaching behavior, rigor, tone | Review system: comments by subject |
| Escapes in owned area | Outcome trend (use with care: escapes have many causes) | Defect tracker, found-in = production |
| Triage and incident threads | Communication under pressure, hand-off quality | Tracker and incident tool history |
Rule: no Behavior statement without a linkable artifact or a first-person observation with date and place. Secondhand reports ("people say...") are not Behavior; either observe directly, collect the reporter's own SBI, or drop the theme.
Step 3 - Draft each item as SBI(I)
Worked example, corrective, artifact-backed:
**Situation:** In Tuesday's triage meeting (2026-06-02), reviewing bug #4821,
the payment-retry failure you filed on Friday.
**Behavior:** The report had a one-line description, no reproduction steps, and
no environment block. Dev returned it as cannot-reproduce, and you re-filed it
with full steps on Monday (#4838) - those steps reproduced first try.
**Impact:** We lost two working days on a P2 in the payment path, and the
developer's first hour went into guessing context your Monday version supplied
in full. When your reports carry reproduction steps, like #4838 or #4640 from
May, they typically clear triage in one pass. I want that to be the default.
**Intent (ask, then listen):** What was happening on Friday when you filed the
first version - what were you trying to get done?Worked example, positive, same discipline:
**Situation:** During the 2026-Q1 charter sessions on checkout (your session
log, weeks 3 - 14).
**Behavior:** You logged 31 charter-based sessions and your session notes
flagged the cart-merge timing issue that became P1 #4512 before it shipped,
including a recorded repro.
**Impact:** Two of the quarter's three would-be P1 escapes were caught in your
sessions; the cart-merge catch alone avoided a production incident in the
revenue path. I used your session notes as the example in the team's charter
workshop - I was genuinely impressed by the audit trail.The positive example follows the identical Situation/Behavior/Impact discipline (CCL); vague praise ("great quarter!") wastes signal exactly the way vague criticism does. The Intent step is most valuable on corrective items: per CCL it surfaces the gap between what the person intended and the impact that landed, instead of assuming motive.
Step 4 - Assemble into the purpose-shaped output
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Adjective feedback ("be more proactive") | Unverifiable and unactionable; recipient cannot replay what to change | Every item passes the Step 2 artifact rule |
| Personality framing ("you are careless") | Attacks identity, spikes defensiveness; CCL's model exists to avoid exactly this | Behavior describes actions ("the report lacked repro steps"), never traits |
| Vague situations ("recently", "sometimes") | Recipient cannot place the event; the conversation degrades into whether it happened | CCL: name the time and place precisely |
| Assumed motives ("you clearly did not care") | Usually wrong, always inflammatory | SBII Intent question: ask what they were trying to accomplish (CCL) |
| Feedback sandwich | Buries the signal; recipients learn to discard the praise as packaging | One item, one message; positive items stand alone on their own days |
| Stockpiling for review season | Months-old events are unfixable; the review becomes an ambush | Step 4 immediate path; reviews summarize known conversations (ISBN 978-1491973899) |
| Metric-only judgment (bug counts as performance) | Raw counts reward volume over value and are gameable | Counts may locate themes; the feedback itself cites specific artifacts and their impact |