2 min lesson
Build each story this way
Rebuild the sequence in "Build each story this way" from memory, ending with the check that proves the outcome.
Step 1 of 2
Build each story this way
- 1Situation + Task, in two sentences. Just enough stakes to make it matter. Skip the org chart.
- 2Action, in the first person. What you did, the call you made, the tradeoff you chose. This is most of the airtime - say "I," not "we."
- 3Result, with a number. Resolution time dropped, ticket volume fell, the macro deflected N requests a week, an enterprise renewal was saved.
- 4The honest coda. One sentence on what you'd do differently. This is the part that makes everything before it believable.
"Our queue kept filling with the same crash reports and I was hand-parsing stack traces before standup to spot the pattern. So I wrote a script that grouped incoming logs by signature and posted a daily digest to our triage channel - I shipped a rough version Friday, then tightened it the next week once I saw which signatures actually mattered. First response on those crashes went from about six hours to forty minutes. If I did it again I'd add an alert for a brand-new signature sooner; the first cut only caught patterns I'd already seen."
Quantify wherever you honestly can: time saved, tickets deflected, users affected, revenue at risk on a blocked enterprise account. "The customer was happy" is the answer this culture screens out. If your best result is a feeling, rebuild the story around something you measured.
Learn more
Advanced table
Tag every story so you can deploy on demand
Tag every story so you can deploy on demand
- Story
- Root-caused the cross-OS indexing hang
- Primary theme
- Debugging craft
- Result you'll cite
- Closed a class of tickets, not one
- Story
- Calmed the enterprise lead who threatened to churn
- Primary theme
- Empathy under pressure
- Result you'll cite
- Saved the account, fixed the real bug
- Story
- Built the log-parser triage script
- Primary theme
- Bias to action
- Result you'll cite
- Cut first-response time from 6h to 40m
- Story
- Escalated the auth regression cleanly
- Primary theme
- Support-Eng loop
- Result you'll cite
- Hotfix shipped in a day, not a week
- Story
- Admitted a wrong diagnosis publicly
- Primary theme
- Truth-seeking
- Result you'll cite
- Reopened, re-fixed and wrote the postmortem
| Story | Primary theme | Result you'll cite |
|---|---|---|
| Root-caused the cross-OS indexing hang | Debugging craft | Closed a class of tickets, not one |
| Calmed the enterprise lead who threatened to churn | Empathy under pressure | Saved the account, fixed the real bug |
| Built the log-parser triage script | Bias to action | Cut first-response time from 6h to 40m |
| Escalated the auth regression cleanly | Support-Eng loop | Hotfix shipped in a day, not a week |
| Admitted a wrong diagnosis publicly | Truth-seeking | Reopened, re-fixed and wrote the postmortem |
Have one story explicitly about working at high pace: a launch week, a Slack channel on fire, a model swap that broke behavior overnight. Don't just say you handled it - say how you triaged, what you let slip on purpose and how you still kept the highest-severity user unblocked.
A "disagreed with a decision" story is high value because it tests truth-seeking, but it fails if you're abrasive or if you caved instantly. Show that you named your case with evidence, stayed collegial and either changed the outcome or committed cleanly once the call was made.
QWhy does Cursor want a metric in the Result of your support STAR stories and why insist on the first person?