Setting review triggers that fire between annual assessments

The annual performance review measures the wrong thing at the wrong time. It scores an employee on what a manager remembers from the last two months, not on what actually happened over the preceding year, and by the time anyone acts on the feedback, the behavior that prompted it is long gone. A shorter cycle wouldn't fix this. What's needed is a set of predefined triggers, tenure milestones, deviation thresholds, structural changes, that force a conversation the moment a specific condition is met, with no calendar involved.

Why the calendar is the wrong clock

Performance systems run annually or semiannually because that's how compensation cycles and budget planning work. It has nothing to do with when feedback actually helps. Kluger and DeNisi ran a meta-analysis of feedback interventions back in 1996 and found that roughly a third of the studies they looked at showed feedback making performance worse, not better. The common thread in those failures was timing: the feedback showed up too far removed from the behavior it was supposed to fix. Delay breaks the link between action and consequence. Tell someone in November that they undersold their work to a client in March, and the correction lands as something else entirely: a character trait, described secondhand, and nobody likes hearing their character summarized once a year by someone reading from notes.

There's a selection problem here too, and it's a quiet one. Whatever happened in the two months before the review gets weighted heavily, because it's freshest in the manager's head, and everything before that gets flattened into a paragraph of vague summary. The review ends up evaluating two months of work with a year's worth of authority attached to it. Triggers fix this by attaching the conversation to the event itself, not to whatever the manager happens to remember when the review template opens up.

What a trigger actually is

A trigger is a condition, agreed on ahead of time, that kicks off a check-in outside the normal review cycle, automatically. Managers saying "let's touch base more" doesn't count; they say that constantly and then never do it, because nothing forces the calendar invite to actually get sent. A real trigger has a threshold, an owner, and an action attached to it before anything happens, not after.

A few that hold up in practice: a project misses its deadline by more than 15%. An engagement survey score drops two points from one quarter to the next. Someone gets a new manager. A client names an individual contributor in a complaint. An employee crosses six months or two years on the team. Each one is observable and timestamped, which means nobody has to make a judgment call about whether enough time has passed to justify bringing it up. The condition either happened or it didn't.

Building the trigger list

Start with what's gone wrong before, not what you'd like to see go right. Pull the postmortems. If three separate incidents show a performance issue was visible for three months before a manager said anything, that three-month gap tells you your threshold, and it should probably be tighter than that, maybe four weeks.

Most useful triggers fall into one of four buckets. Deviation triggers fire on a metric crossing a line: velocity drops below baseline, a support queue backs up past a set number of tickets. Transition triggers fire on structural change, a new manager, a new role, a return from leave. Signal triggers fire on qualitative input, a peer flag, a client complaint, or a piece of unprompted praise that deserves faster recognition than waiting six months for the next cycle. Milestone triggers fire on tenure or project completion, whether or not anything went wrong at all.

That's four, not three. A three-category version tends to flatten into good news, bad news, and everything else, and "everything else" is exactly the bucket that swallows the specific, observable conditions you built this system to catch in the first place.

The mechanics that make it work

None of this works if it depends on a manager remembering to check. Some teams build the tracking into their HRIS, pulling alerts off metrics they're already watching somewhere else, sprint velocity in Jira, CSAT in Zendesk. Others just run a shared spreadsheet that someone on the HR side opens every Monday. The tool doesn't matter much. Whether someone actually looks at it on a fixed schedule does.

A trigger without a defined response is just a notification nobody acts on. A missed deadline should map to something short and specific, ideally within 48 hours, about that one incident, not a referendum on the employee's whole quarter. A six-month tenure trigger probably maps to a career conversation instead, a completely different tone and agenda. Mix these up, treat every alert like it deserves the same weight, and managers start ignoring the system within a few months. That's trigger fatigue, and it kills the whole project faster than having no system at all.

Amazon's six-page narrative memos before major reviews aren't a trigger system, but they run on the same logic: specificity forces honesty. The phrase "there are performance concerns" is vague enough to argue with, and it invites exactly that. "You missed two consecutive sprint commitments" leaves little room for negotiation. The number did what it did.

The tradeoff nobody wants to say out loud

This creates more work, especially in the first few months, and it will surface conversations that a lot of managers aren't currently equipped to run well. That's not an argument against building it. It's an argument for training managers on structured, low-stakes feedback delivery before flipping the system on for the whole org, because a trigger that fires into an unprepared manager just produces a badly handled version of the same problem you started with.

Over-triggering is the other failure mode, where every minor blip fires an alert and the system turns into noise nobody trusts. Calibrate it the way you'd calibrate any alerting system: track how often a trigger fires without producing a useful conversation, and loosen or retire the ones that don't earn their keep.

Annual reviews aren't going anywhere, and they shouldn't. Compensation decisions and long-arc calibration across a team need that structure. But treat the annual review as the only checkpoint that counts, and the moments that actually shape someone's performance, the near-miss in March, the quiet win in July, spend eleven months sitting in silence before anyone thinks to mention them.