Most objectives fail before anyone starts work on them. They fail because they describe activity instead of a result, because there are too many of them, or because nobody looks at them again until the review.
This guide is about the thinking. It applies wherever you write objectives, not only in useful.
What an objective is for
An objective answers one question: what will be different in six months because this person was here?
That question has a useful property. It cannot be answered by a list of tasks. “Run the onboarding project” is a task. “New starters reach full productivity in four weeks instead of nine” is a difference. The first tells you what somebody was busy with. The second tells you whether it mattered.
Two things follow from this.
An objective is not a job description. The job description covers the work that always happens. The objective covers the work that changes something. If an objective describes the whole job, it is not an objective.
An objective is not a promise. Some objectives are not achieved. That is information, not failure. An organisation where every objective is achieved is one where the objectives were too easy to be worth setting.
How many
Three to five per person per cycle. Fewer than three usually means the objectives are too broad to act on. More than five means none of them is a priority.
The count matters more than people expect. A person with twelve objectives has no objectives — they have a task list with ceremony attached. When they have to choose what to drop in a busy week, twelve objectives give them no help. Four do.
If you cannot get below five, the objectives are probably written at the wrong level. Look for two that are the same thing described twice.
Outcome, not activity
This is the single most common failure, so it is worth being precise about it.
An activity is something you do. An outcome is something that is true afterwards. Compare:
| Activity | Outcome |
|---|---|
| Deliver sales training to the team | Every rep passes the product test at first attempt |
| Improve the release process | Releases go out weekly, with no rollback |
| Hire two engineers | The platform team is fully staffed by the end of Q3 |
The activity versions all share a problem: you can complete them and change nothing. You can deliver the training to a team that learns nothing. The outcome version fails honestly if the outcome does not happen.
There is one legitimate exception. Sometimes the activity genuinely is the point — a compliance deadline, a migration that has to happen by a date. Write those as objectives too. Just be honest that the value is in the completion, and do not dress a task up in outcome language to make it look better.
Set them where the work is
An objective set by a manager, for a person, without that person in the room, is a target. It might still be a good target. But it belongs to the manager, and it behaves that way — the employee delivers against it rather than owning it.
The best objectives come out of a conversation where the employee has more context than the manager about how, and the manager has more context than the employee about why. Give each of them the part they are better at. The manager brings the direction. The employee brings the shape.
This matters more than the wording of any individual objective.
Look at them more than twice
The most reliable predictor of whether an objective is achieved is how often anyone looked at it.
An objective set in January and next opened in December was not an objective. It was a note. Nothing about it influenced a decision in between, which is the only way an objective can do any work at all.
Check in monthly, or at minimum quarterly. The check-in does not have to be long. It has to answer one question: is this still likely, and if not, what changed?
That question is why useful asks for a confidence level at each check-in rather than a percentage complete. Percentage complete rewards activity. It goes up whether or not the objective is going to happen. Confidence goes down when something goes wrong, which is exactly when you want to know.
The four failure modes
Objectives usually fail in one of four ways. All four are visible before the end of the cycle, if anyone is looking.
Nobody wrote down what success means. The objective says “improve customer satisfaction”. Nobody agreed what a good result would be. At the review, everyone argues about the score rather than the work. The fix is measures — see Writing an objective people can act on.
Too many objectives, so none of them is real. Covered above. The symptom is that the person cannot recite them without looking.
The blocker was known for months and never said out loud. Someone knew in March that the budget was not coming. They said so in December. Ask for blockers at every check-in, and treat naming one as a good thing rather than an excuse.
The objective stopped mattering and nobody cancelled it. Priorities change. An objective that no longer matters should be closed as no longer applicable, not carried to the end and marked failed. Carrying dead objectives teaches people that objectives are theatre.
What to do with a failed objective
Mark it honestly, and separate two questions.
Was the objective achieved? That is a fact about the work.
Should the person have achieved it? That is a judgement about circumstances, support, and whether the objective was reasonable when it was set.
Organisations get into trouble when they collapse these into one. If an unachieved objective always reflects badly on the person, everybody sets easy objectives, and the whole exercise stops telling you anything. Record the result accurately. Have the conversation about why separately.