How to design a performance management process that fits your organisation

Designing a performance management process means deciding three things: how you set expectations, how you coach people towards them, and how you let people know how they performed. Decide those from how your organisation works rather than from a template, and decide them separately rather than bundling them into one annual event.

Why borrowing somebody else’s process does not work

Ask who decided your current performance process and the trail usually goes cold. A template a previous HR lead brought from their last employer. A vendor’s default nobody changed. A form built for a structure that no longer exists. Someone left and took the reasoning with them.

Borrowing is understandable. The process feels heavy, so you reach for an answer that already exists, or you buy the software with the most features and run whatever the vendor suggests. Neither builds anything for your organisation, and both are a way of not forming a view while feeling like a decision has been made.

The reason borrowed processes fail is that two processes which look identical land completely differently depending on the organisation they sit in. What transfers is the shape. What does not transfer is the fit.

Push and pull

Most performance processes are pushed. HR rolls something out and asks people to comply, and compliance is the best result that approach can produce. You can get everyone to finish the form and still have changed nothing about how the work goes.

The alternative is a process people pull into their work because it is useful to them. Pull is not a framework or a form. It shows up as voluntary behaviour: teams reusing something without being chased, managers referring to it because it helps them do their job.

You cannot tell whether pull exists by looking at the process. You can only tell by watching what people do when nobody is enforcing anything.

This is the difference between an HR team that spends the last fortnight of every cycle sending reminders and one that does not.

The two levers worth designing for

When someone is trying to do good work, they are navigating two questions at once. Do I have the skills to do this well? Is the environment helping or hindering me?

Those give you two levers.

Capability. The skills somebody needs to do their work to a high standard, and how they build them.

Conditions. What needs to be in place around a person to give them the best chance of succeeding.

The instinct when performance drops is to reach for capability: more training, more coaching, more motivation. Frequently the problem is conditions. Priorities change faster than goals get updated. Expectations are implied rather than stated. Feedback arrives too late to be useful. Dependencies sit outside the person’s control.

In those situations asking somebody to perform better is unrealistic, because they are already doing the best they can inside the conditions they were given.

Conditions are the quieter lever and usually the faster one to feel, because a change lands for everyone at once instead of one person at a time. Help managers get clearer about what good looks like in their team. Surface competing priorities in management meetings rather than leaving them to collide further down. Remove steps that do not match how people work.

Decide the principles before the mechanics

The usual order is to argue about mechanics. Which template, what cadence, how many questions, whether ratings are out of five. Those arguments run for weeks because nothing underneath them has been settled.

Settle these first. It is half a day of work and it ends most of the later arguments.

• What does a high performer look like in this organisation, and what conditions help them succeed?
• What do we believe a performance review is for?
• When is feedback most useful: to improve performance, or to help people feel recognised?
• What kinds of goals do we want people to have, and why?
• What is all of this in service of?

Be opinionated here. Being neutral about principles is what leads to borrowing someone else’s mechanics.

How to set performance expectations

What it is for. So that a person knows what good looks like in their role before they are assessed against it, and so two people doing the same job are not measured differently by different managers without either knowing.

What to decide:

• Whether expectations are role-based, goal-based, or both, and how goal setting works alongside them
• Who writes them, and whether the person has a say
• How specific they get, and whether that differs by role or level
• What happens when priorities change mid-cycle
• The rhythm: when expectations get set, and when they get revisited

The failure to watch for is expectations that exist in a manager’s head but have never been said out loud. That is the most common condition problem in the two levers above, and it costs nothing to fix.

How this works in Crewmojo: setting expectations, covering goals, OKRs, role expectations and values.

How to coach employees between reviews

What it is for. So that the gap between where somebody is and what is expected gets closed while there is still time to close it, through conversations that happen near the work rather than months later. This is the part people mean by continuous performance management.

What to decide:

• The rhythm: weekly, fortnightly, monthly, or tied to the work rather than the calendar
• Whether coaching conversations are structured or open, and how much structure managers want
• What gets captured, and what stays in the conversation
• What a manager needs in front of them to make the conversation useful
• Who supports managers who are not yet good at this

The rhythm question matters more than the format question. A fortnightly conversation with no agenda beats a beautifully structured quarterly one, because the work has moved on by the quarter.

How this works in Crewmojo: coaching and support, covering one-on-ones, check-ins, feedback and recognition.

How to run fair performance reviews

What it is for. So that a period of work gets assessed fairly, the assessment is explainable, and the person is not surprised by it. A performance review process, or performance appraisal in older language, is the stage most organisations recognise and the one they most often get wrong.

What to decide:

• What the output is used for: remuneration, promotion, development, calibration, or nothing
• Who contributes: self, manager, peers, skip-level
• Whether there is a rating, and what it means
• How consistency is handled across managers
• The rhythm, and whether it is the same for every team

The thing to get right here is what the review draws on. A review where the manager reconstructs a year from memory is a different product to one that draws on what was captured when it happened. The second is shorter and more defensible, and it is only possible if the coaching stage was designed to feed it.

How this works in Crewmojo: reviewing performance, covering performance reviews, 360s and calibration.

Unbundle these three

Do not run expectations, coaching and review as one ritual. This is the strongest single piece of advice in this guide.

Bundling them is why the annual cycle feels heavy. It is also why people cannot tell what is happening to them. In Thanks for the Feedback, Douglas Stone and Sheila Heen separate feedback into appreciation, coaching and evaluation, and make the case that delivering them together leaves the recipient unable to tell which one they are receiving. They assume the one with consequences.

Separate them into smaller activities, each at the cadence it needs. Expectations might be set annually and revisited quarterly. Coaching might be fortnightly. Review might be half-yearly. None of that requires them to happen in the same meeting or the same form.

When to add onboarding, development and talent reviews

Once the core cycle runs, the next question is what else should connect to it. Onboarding, probation, development and career plans, talent reviews and succession, lifecycle moments like role changes and exits. All of them touch performance, and all of them are usually run somewhere else entirely.

Extend when you can name what the new workflow does that the existing one cannot. Most expansion fails that test. A new process gets added because somebody raised a new need, before anyone checked whether the existing cycle could already carry it.

Two things make extension work.

Start from the process that causes the most friction, not the one that is easiest to build. Proving something on a real problem buys you the credibility to do the next one.

Add one at a time. Pixelogic Media developed around ten workflows within a year, adding each as the need arrived rather than specifying everything up front. That is slower on paper and considerably faster in practice, because each one was designed with what the last one taught them.

How this works in Crewmojo: extending further, covering talent reviews, development plans, engagement and compliance.

How to pilot a performance management process

The fastest route to a process that fits is to run one. Build a first version from what you already know, test it with a small group of real people, ask them what did not work, change it, and widen the scope once it holds. Discovery happens by doing.

Settle the principles above first, including who should own the process once it is running. Everything after that is learnt faster by running something than by specifying it.

The loop

1. Start with what you already know. You have settled the principles, you know how your organisation works, and you know where the friction is. That is enough to build version one. It does not need to be right and it is not meant to last. It exists so that there is something real for people to react to, which is the only way to find out what they think.

2. Build it. The working thing, configured: the steps, the questions, the timing and the people in it.

3. Run it with real people. Pilot it with a team of twenty or thirty. Pick one that will tell you the truth rather than one that will be polite about it, and run the whole thing rather than one stage of it.

4. Ask them what did not work. Specifically, and while it is fresh. Where did they stall, what did they skip, what did they not understand, what felt like administration. Managers will tell you if the form is annoying. Employees will tell you if they could not see the point.

5. Change it. This is the step the method lives or dies on. If a change takes weeks, or a quote, or a developer, the loop breaks and you are back to designing on paper. Changes should take an afternoon.

6. Check it fits. Run it again with the same group, or the next one. You are looking for people using it without being chased, and managers referring to it because it helps them. That is pull, and it is the only reliable signal that the design is right.

7. Widen the scope. Another team, another department, or the next stage of the cycle. Each round starts from what the last one taught you rather than from a blank page.

Why this works

A round takes days rather than months, so being wrong early costs you very little. You are also gathering evidence as you go, which makes the internal case easier to make than a six-month diagnostic does.

The method depends on the process being genuinely quick to change. Where editing a step, adjusting timing or rewriting an instruction needs a vendor conversation, the loop is too slow to learn anything and the organisation defaults back to designing everything up front.

A loop of this shape usually gets a first version in front of real people inside a month, which is early enough that nobody has defended it yet.

Russ Heptinstall, Director of Global Talent Management at Pixelogic Media, has described working this way with Crewmojo in exactly those terms: collaborative design, rapid testing, and the employee feedback that came back from it.

You are finished when the people using it say it is theirs. When a manager would notice if you took it away.

Where to go next

If you suspect the limit is your software rather than your design, read the signs you have outgrown your performance management software before designing anything.

For the experience-led version of this argument, with more on trust and the manager relationship, Megan’s how to design a strong performance process is the companion piece.

If you want to talk through a design before looking at any product, book a conversation and we will start with how performance runs in your organisation today.

About this guide

Written by Mark Lewis, CEO of Crewmojo, drawn from co-designing performance processes with HR leaders across health, government, retail, professional services and not-for-profit organisations.

---