The performance-conversation block of the training introduced STAR — Situation, Task, Action, Result — as a format for giving feedback that lands cleanly under pressure. It looks like a competitor to SBID, but the two do different jobs. SBID is for in-the-moment feedback; STAR is for the harder, structured conversation: the performance review, the promotion discussion, the difficult one-on-one about whether someone is on track.
I’ve been preparing for performance conversations in something close to this shape since my first review cycle a year ago, partly because the best manager I had as an engineer ran her reviews this way and I’d been copying her structure. The session formalised the format, and the formalisation matters: it makes the shape teachable and it makes my own preparation more honest.
The format
| Field | Question it answers |
|---|---|
| S — Situation | What was the context — the project, the team, the moment? |
| T — Task | What was being asked of the person — the expectation, the role, the deliverable? |
| A — Action | What did they actually do? |
| R — Result | What was the outcome — for the work, the team, the person? |
The four fields look mundane until you try to give performance feedback without filling them in. Then you discover how much of what we normally call “performance feedback” is really a vague mix of impressions and characterisations, given without grounding in any specific moment.
What STAR forces me to do
The most important thing STAR does is force me to separate the expectation from the action. In a lot of bad performance conversations, those two are collapsed: you didn’t lead the project well. That collapse hides whether the problem is that the person didn’t know what was expected, didn’t have the resources to meet it, didn’t try to meet it, or tried but produced the wrong outcome. Each of those calls for a completely different conversation.
When I separate Task (“what was being asked”) from Action (“what they did”), the conversation becomes diagnosable. The person can see exactly where the gap lives. So can I. We can both work on the right thing.
The second important thing STAR does is anchor the conversation in a specific Situation. Last quarter you struggled with stakeholder management is not a STAR conversation; it’s a characterisation. In the migration project in Q1, when the stakeholder asked for the status review on a tight timeline, here’s what I observed and here’s what I’d hoped to see is a STAR conversation. The first invites defensiveness because there’s nothing concrete to engage with. The second invites collaboration because there’s a specific moment to discuss.
The third is that STAR requires me to articulate Result in terms beyond good or bad. The work outcome, the team outcome, the customer outcome, the person’s own learning outcome. When I write Result honestly, the conversation often shifts. Some performance issues I’d been ready to name as Action problems turn out, under STAR analysis, to be Task problems — the person delivered what they understood they were being asked for, and I had failed to set the expectation. That’s a conversation about me, not about them, and STAR is the format that surfaces it.
A worked example
A senior engineer on my team was criticised by another team’s lead a couple of months ago for what they called “slow communication” during a cross-team launch. My instinct, in the moment, was to give him the feedback as I’d received it: the other team felt you were slow to communicate; we need that to be faster. I caught the instinct and slowed down before the conversation, because I knew that version wouldn’t help him improve and might damage trust I’d been building with him.
The STAR version, written out as I gave it:
- S: During the platform launch in March, where you were the engineering lead on our side and the partner team had a separate eng lead on theirs.
- T: The expectation was that you would be the primary point of contact for the other team and would surface integration risks early so they could plan around them.
- A: Two integration risks emerged in the first week. You raised the first one in a Slack message on day eight. The second one came up in the post-mortem.
- R: The other team adjusted late on the first one and missed the second one entirely; their lead felt out of the loop, which is what’s driving the feedback.
The conversation that followed was completely different from the one that would have followed “you were slow to communicate”. He engaged with the specific facts. He brought his side — he thought he was raising risks at the right time, hadn’t realised the partner team’s planning needed earlier visibility, and had inferred from one of their earlier messages that they preferred summarised updates. None of that excused what happened; all of it changed what we did about it. The next launch, the comms cadence was explicit between us before we started.
Where STAR keeps me honest
I want to be specific about the version of myself STAR keeps me from being.
Without STAR, I’m more likely to bring vague, accumulated impressions to a performance conversation. You’ve been struggling with X. The person hears that as a verdict, and we spend the conversation negotiating whether the verdict is fair instead of working on the actual situation.
Without STAR, I’m more likely to confuse Task with Action. The person didn’t do what I wanted, so they failed — without checking whether what I wanted was actually clearly communicated. STAR won’t let me skip the Task field, and the Task field has already caught me twice this year.
Without STAR, I’m more likely to talk about the Result in vibes rather than effects. It didn’t go well. That tells the person nothing actionable. The two engineers who had to scramble at the end lost a week of planned work, and the customer-facing release slipped by ten days is a Result that explains why this matters.
When STAR is the wrong tool
STAR is great for structured, important conversations. It is overkill for the small, in-the-moment feedback that should just happen. For that, SBID is the right format — lighter, faster, more conversational. Using STAR for a five-minute feedback exchange makes the conversation feel like a tribunal.
The line I use: STAR for the conversations that need to stand up to scrutiny later (reviews, written feedback, important calls about someone’s trajectory). SBID for the conversations that are about helping someone adjust this week.
The team effectiveness piece
There are two effectiveness arguments for STAR.
The first is fewer escalations. Performance conversations done in characterisations produce defensiveness, which produces escalations, which produce HR involvement, which produce time and trust losses across the team. STAR conversations don’t escalate at the same rate because there isn’t a characterisation to argue about. The energy goes into the actual issue instead of into the meta-conversation about whether the issue is fairly framed.
The second is better calibration. A team where performance is discussed in STAR terms develops a shared vocabulary of what good and bad work actually looks like, anchored in specific moments. That calibration makes promotions, scope changes, and growth conversations dramatically less arbitrary, which makes the team trust the process more, which makes them invest more in the kind of growth the process rewards.
Both of these compound. Both are invisible until you’ve worked under a manager who runs performance conversations in characterisations — I have, and I remember exactly what it cost.
What I’m taking into the next review cycle
The discipline is the same one I’ve been running, formalised: write the four fields before the conversation for every performance discussion. Use it for written feedback that goes into review packets, so the calibration is consistent across reviewers. Teach the format to the senior engineers on my team who give peer-review feedback into the same packets, so their feedback uses the same shape.
That last one is the multiplier. A review packet where every observation is in STAR form is a packet a person can act on; a packet of characterisations is a packet they argue with.
Closing
STAR isn’t a framework I love. It’s a discipline I rely on, the way I rely on a clean PR description or a structured post-mortem. The conversations I had this year without it as an explicit format were thoughtful but informal; the conversations I’ll have with it next cycle will be sharper, more teachable, and more consistent. That trade-off — the small formality of writing out the four fields in exchange for a conversation that actually lands — is one I take every time.