"Manage customer accounts" is a responsibility. It is also what most job descriptions would say.
"Reduce unresolved customer issues and improve renewal visibility across the portfolio" is an outcome. The two could describe the same job, but they lead to very different searches.
The first tells a recruiter to look for someone who has managed accounts, which is a long list of people. The second tells the team what the person is there to fix. That gives everyone something more useful to source, assess and discuss.
In a recent article we argued that the first question in any search should be what needs to be different because this person was hired. This article is about how to answer that question well.
Activities are not results
Most job descriptions list activities because activities are easy to write. They can be copied from the last version of the role, and nobody will object to them.
The same habit shows up inside large organisations. The US Office of Personnel Management notes in its guide to performance plans that plans built from position descriptions generally describe activities, not accomplishments. It recommends focusing on the accomplishments instead. That guidance is written for managing staff already in post, but the logic applies just as well before you hire.
Public health evaluators draw a similar line. The US Centers for Disease Control and Prevention's program evaluation framework separates outputs, the products of a program's activities, from outcomes, the effects or changes it expects. Vaccinations given are an output. Higher immunisation rates are an outcome. It also admits that outcomes can be harder to measure, which is exactly why people default to counting activity.
Hiring has the same temptation. "Runs weekly reports" is easy to write. "Leaders can make decisions without chasing numbers" takes more thought, and it is far more useful.
Three questions for an outcome statement
An outcome statement does not need to be long. It needs to answer three questions.
What must be different after six or twelve months? Describe the situation you want, not the work that gets you there. If nothing would be visibly different, ask whether the role is really needed in this form.
Who will notice the difference? Name the people. Customers, the finance team, the owner, the night shift. If nobody would notice, the outcome is probably too abstract. Naming them also tells you who should be consulted before the role is advertised.
What evidence would show that progress was made? Decide what you would look at in a year's time to know the hire worked. This is the question most teams skip, and it is the one that makes the other two honest.
Not every result is a number
A common objection is that much good work cannot be reduced to a single figure. That is true, and it is not a reason to skip this step.
Some outcomes concern quality, reliability, decision speed, risk or the confidence of the people relying on the work. They still need to be observable.
OPM's guidance on developing performance standards offers a helpful starting list: quality, quantity, timeliness and cost effectiveness. Quality covers accuracy, usefulness or effectiveness, so it does not have to be a count. Its eight step guide adds a practical rule. If you can measure an accomplishment with numbers, record how. If you can only describe it, be clear about who will judge it and what they will look at.
That rule translates well to a role outcome. "Board papers are trusted" is vague. "The finance director no longer rewrites board papers before they go out" is something a real person can observe, even with no number attached.
Be careful with numbers as well. A single target can push people towards the figure rather than the goal. Cutting open customer issues is easy if you close them without solving them. Pairing the number with who notices the difference helps guard against that.
Work backwards to the capabilities
Once the outcome is clear, the requirements get easier to write, because you can ask what it would take to deliver it.
Take the customer account example. To reduce unresolved issues and improve renewal visibility, this person probably needs to:
- find the root causes of repeat complaints, not only respond to each one
- keep a simple forecast that others can rely on
- raise bad news early with people more senior than them
Those are capabilities you can test in an interview. Ask about a time they found the cause of a recurring problem, or told a senior person something unwelcome. Each one links straight back to the reason for the hire.
Requirements that do not link back are worth questioning. If the old description asks for a particular qualification or number of years, and you cannot connect it to an outcome, it may be there out of habit.
A quick before and after
Here is one small team's role, written two ways.
Before: "Office administrator. Answer phones, manage diary, process invoices, order supplies, support the team."
After: "Within six months, supplier invoices are paid on time without the owner checking each one, and the owner gets back a day a week. The owner and our suppliers will both notice. We will know it has worked when late payment reminders stop and the owner's diary shows that day protected."
The tasks may be much the same. But the second version tells you what to ask in the interview, and tells a good candidate exactly what they are signing up for.
The bottom line
Without a clear outcome, a role is a collection of tasks looking for a title. Before you search, write down what must be different after six or twelve months, who will notice, and what evidence would show progress. It does not all have to be a number, but it does have to be observable. Then work backwards to the capabilities you need.