The goals that work best are specific, fair, and easy to measure
- Use SMART as a base, but let the shape of the role decide whether the goal should focus on results, behaviours, or learning.
- Keep performance goals separate from development goals so the review covers both delivery and growth.
- Set a starting point, a deadline, and a realistic measure so both sides can see progress.
- For collaborative work, measure handoffs, communication, and team contribution, not only output.
- Review progress through the year, because annual-only goal setting ages badly.
How I separate performance, development, and behaviour goals
I like to start with the work itself, not with a template. A review goal should answer one of three questions: what results must this person deliver, what skill should they build, or how should they work with others while doing it?
| Goal type | Best use | Example | Watch-out |
|---|---|---|---|
| Performance goal | Core output in the current role | Reduce average customer email response time from 48 hours to 24 hours by the end of Q3. | Avoid goals the employee cannot influence directly. |
| Development goal | Building capability for the current or future role | Complete one advanced Excel course and automate one monthly report by September. | Do not make the course the whole goal, apply the skill. |
| Behaviour goal | Teamwork, service, and leadership habits | Lead a weekly handover update and reduce missed dependencies to zero for 12 weeks. | Keep it observable, not vague. |
For UK teams, I keep one rule from Acas in mind: objectives should reflect the employee’s usual workload and still be stretching enough to matter. If the job is complex, I am happier with a strong learning outcome or behavioural standard than with fake precision. That is usually the difference between a goal that motivates and a goal that only looks neat on paper. With that in place, the examples below become much easier to use.
Examples of goals that actually work in a review
When I write goals for review season, I want them to survive real work, not just sound impressive in a meeting. The best examples are clear enough that an employee can act on them immediately and a manager can check them without guessing.
| Goal area | Example goal | Why it works |
|---|---|---|
| Customer service | Reduce average first response time from 48 hours to 24 hours and keep customer satisfaction at 90% or above through the next two quarters. | Names the metric, target, and timeframe. |
| Project delivery | Deliver 95% of assigned tasks by the agreed deadline and flag blockers within one working day. | Measures both output and communication. |
| Quality | Cut report rework to one revision round or fewer on monthly reports for the next three months. | Focuses on quality, not just speed. |
| Collaboration | Send a Friday status update for active projects every week and close open dependencies within 48 hours. | Makes teamwork visible and trackable. |
| Leadership | Hold one 1:1 with each direct report every two weeks and document one action point from each meeting. | Protects the coaching habit, not just the calendar slot. |
| Development | Complete one role-relevant learning goal each quarter and apply it in at least one live task. | Ties learning to practice, which is where the value appears. |
The pattern is simple: a good goal names the behaviour or outcome, gives a number or standard, and puts a deadline on it. If I cannot tell who owns the outcome or what evidence will exist at the end, I rewrite it. That is how I write employee goals for performance review when I want them to survive the whole cycle.
How to adapt goals when the role is collaborative or hard to measure
Not every job lends itself to neat output numbers, and pretending otherwise creates bad reviews. For knowledge work, teamwork, and management roles, I usually focus on quality, reliability, decision-making, or learning outcomes instead of volume alone.
| Role situation | Better goal style | Example |
|---|---|---|
| Knowledge-heavy role | Learning outcome plus quality standard | Improve first-draft accuracy on client briefs so manager edits fall by 50% over the next quarter. |
| Team-based role | Shared outcome plus behaviour | Close 90% of sprint handoffs on time and raise blockers within 24 hours. |
| New starter | Ramp-up goal | Independently handle the standard workflow by week 10 with no more than two escalations per week by then. |
| Manager | People goal | Complete monthly check-ins with every direct report and document development actions within 24 hours of each meeting. |
| Underperformance case | Improvement goal with support | Meet the agreed checklist for two consecutive months with weekly support meetings. |
CIPD’s current guidance is useful here: where work is complex, open-ended objectives or learning outcomes can work better than rigid targets. I agree with that view. The tighter the dependency chain, the more I care about behaviour and coordination, because results are often shared. That also explains why team goals sometimes make more sense than purely individual ones. The next step is to avoid the mistakes that make otherwise good goals feel unfair or vague.
Common mistakes that make review goals useless
I have seen well-run reviews fall apart because the goal design was sloppy, not because the employee lacked effort. These are the errors I look for first:
- Too many goals - Four to six is usually enough; beyond that, attention gets diluted.
- No baseline - If you do not know the starting point, the final discussion becomes fuzzy.
- Goals outside the employee’s control - Avoid outcomes that depend mostly on another team, budget approval, or hiring decisions.
- Vague language - Words like improve, support, and communicate mean little without a standard or deadline.
- Hidden priorities - If a goal really matters, make it visible instead of burying it in a note.
- No checkpoints - Quarterly or monthly check-ins stop small issues from becoming surprises.
- Stretch without support - A hard goal is acceptable only if the employee has the tools, time, and authority to attempt it.
My practical test is simple: if I read the goal out loud and still need three follow-up questions, it is not ready. A review goal should be hard enough to matter, but not so blurry that both sides can reinterpret it later. Once those problems are removed, the writing process becomes much easier.
A simple way I write the goals during the conversation
I use a short sequence when I am in the room with a manager and employee:
- Start with the team’s priorities for the next 3 to 12 months.
- Pick 2 to 4 performance goals and 1 development goal.
- Write the metric, the baseline, and the deadline in one sentence.
- Agree the support, authority, or tools needed to make the goal realistic.
- Test the wording against SMART and workload fairness.
- Schedule the first check-in before ending the review.
That sequence keeps the conversation grounded in real work instead of abstract ambition. It also aligns with the shift many organisations are making in 2026 toward regular performance conversations rather than the once-a-year appraisal model. If the wording takes too much explaining, I simplify it until the action is obvious. A strong goal should be readable by someone outside the conversation six months later and still make sense.
The notes that make next year’s review much easier
The most useful habit is boring: keep the original goal, the current status, the evidence, and the support given in one place. That record turns the next review into a factual conversation instead of a memory contest.
I also update goals when priorities move. In 2026, that is not a weakness; it is good management. A goal that made sense in April can be obsolete by October after a product shift, restructuring, or client change.
The best review cycle is the one where the employee knows what success looks like, the manager can point to proof, and both sides have already discussed progress before the formal meeting arrives.
