You've read this job spec. Odds are you've written it.

Senior Backend Engineer. Five years of Go or Java. Experience with Kubernetes. Strong communicator. Team player. Passion for clean code.

Every line describes the person walking in the door. Not one line describes what the person should have done by the end of month six.

So the engineer starts. They work hard. They ship things. At the six-month review their manager says, "You're not quite operating at senior level yet." The engineer asks what senior means here. The manager struggles to answer, because nobody ever wrote it down.

The review goes badly because it was always going to go badly. The definition of great lived in one person's head, and it moved with their mood.

"Do Your Best" Is Not a Standard

Edwin Locke and Gary Latham spent 35 years studying goals. Their 2002 summary in American Psychologist covers well over 100 different tasks and more than 40,000 participants in at least eight countries. One finding sticks with me. Specific, difficult goals consistently beat urging people to "do their best."

Their explanation is blunt: "when people are asked to do their best, they do not do so." A do-your-best goal has no external referent, so every person defines it for themselves.

They even cite a study of engineers and scientists. The ones who set goals for their scores on a behavioural index of performance outperformed the ones told to do their best.

A job spec full of skills is a do-your-best goal wearing a suit. "Strong communicator" means one thing to the candidate, another to the hiring manager, and a third to the VP who signs off the promotion.

A software engineer holding a laptop stands in an open-plan office facing an archery target half-hidden in fog

What Dawleys Does Instead

Debra and I talked to Sally Gibson on Corey-osity Unleashed. Sally runs Dawleys, a customer service, data and fulfilment business in Ross-on-Wye.

Every role at Dawleys has a documented purpose, a mission and a clear definition of great. They use topgrading job scorecards. When a manager and an employee sit down to talk about performance, they talk about the facts on the scorecard, not feelings about the person.

Probation works the same way. Expectations build month by month. By month two, you should be able to do X. Nobody walks into a probation review guessing.

I love this because it removes the ambush. Nobody gets surprised at month six by a standard they never saw.

What Goes on a Scorecard

The scorecard idea comes from Geoff Smart and Randy Street's book Who: The A Method for Hiring. This summary of the book puts it neatly: a mission, a ranked set of outcomes, and a set of competencies, written down before you talk to a single candidate.

Three parts:

  • Mission. One or two sentences on why the role exists.
  • Outcomes. Three to eight results, ranked. What must get done, not what the person will be doing all day.
  • Competencies. How the person should operate to get there.

Here's our senior backend engineer again, rewritten as a scorecard:

Mission: Make the payments service something the rest of engineering trusts and nobody fears deploying.

Outcomes, in priority order:

  1. Cut payment-related P1 incidents in half within twelve months.
  2. Move payments deploys from weekly to on demand within nine months.
  3. Grow two mid-level engineers to the point where they run on-call without escalating.

Competencies: Writes design docs other teams adopt. Says no to scope with data. Stays calm in incidents.

Now picture the six-month review with each version. The first asks, "Are you senior enough?" The second asks, "Where are we on incidents, deploys and the two engineers?" One is a feeling. The other is a fact you both look at.

A manager and an engineer sit side by side at a wooden table looking at the same scorecard, coffee mugs beside them

Month by Month Beats All at Once

Sally's month-by-month probation does something smart. It breaks a big outcome into short steps.

Locke and Latham describe the same effect. In a business game study by Latham and Seijts, a distant goal on its own did worse than "do your best." Add near-term goals alongside the distant one, and self-efficacy and profits beat both other conditions. The paper also notes many errors on dynamic tasks come from failing to break a distant goal into near ones.

For our engineer, the first three months might look like this:

  • Month one: ship a small change through the full pipeline to production. Shadow the on-call rota.
  • Month two: own a payments bug fix end to end, including the incident write-up.
  • Month three: write a design doc for one reliability improvement and get it through review.

Each step points at the ranked outcomes. Each one gives you something concrete to talk about.

New starters need this more than anyone. Talya Bauer's onboarding guidelines for the SHRM Foundation list role clarity among the most consistent predictors of job satisfaction and commitment during onboarding. The same report says half of senior outside hires fail within 18 months. It also cites an estimate of $37 billion lost each year in the US and UK from employees not understanding their jobs.

A new employee with a backpack crosses a river on evenly spaced stepping stones toward an office building where a mentor waves

Facts Beat Feelings in the Review Room

Bad reviews feel personal because they are personal. With no written standard, the manager's judgement becomes the standard. The employee hears a verdict on who they are.

A scorecard moves the conversation onto the table between you. You both look at the same page. You argue about the data, not about the person's character.

Most people don't have this. I wrote about Gallup's falling numbers on employees who know what's expected of them in the tomato in the fruit salad post. Fewer than half now strongly agree.

In my own research, 99.5% of people said they'd had one or more types of bad boss. A manager who judges you against a standard they never wrote down belongs on the list.

"Won't This Turn People Into Metrics?"

Engineers raise this objection more than anyone, and with good reason. They've lived through lines-of-code targets and story-point leaderboards. They know what happens when you measure the wrong thing.

A scorecard is not a dashboard. The outcomes describe results the business needs, ranked so everyone knows what wins when two of them collide. The competencies cover how the person works with others, which no metric captures. And the person in the role helps write it.

The alternative to a scorecard isn't freedom from judgement. It's judgement nobody wrote down. Your engineers still get measured. They don't get to see the ruler.

I'd rather argue about a page I helped shape than guess at a standard living in my manager's head.

Start With One Role This Week

You don't need an HR programme for this. You need an hour and one role.

  1. Pick the role you're hiring for next, or the one with the most confused reviews.
  2. Write the mission in two sentences.
  3. List the outcomes and rank them. Cut anything describing activity instead of results.
  4. Break the first three months into monthly checkpoints.
  5. Show it to the person in the role and ask what's missing.

Then ask yourself the hard question. If your best engineer walked into your office tomorrow and asked what great looks like in their job, would you hand them a page, or a shrug?