Modernising performance management at scale

Replace a fragmented review cycle with a practical operating model for medium and large organisations. This practical guide to modern performance management brings together a step-by-step approach, illustrative examples, a reusable worksheet and answers to common questions. Start with the section closest to your current challenge, then use the working session to turn the guidance into a clear next action.

Diagnose the friction before choosing software

Modernising performance management means improving how expectations, evidence and development connect across the year. Start by following one employee’s experience from goal setting to the final review. Identify duplicate forms, unclear decisions and conversations that arrive too late to help.

Include different parts of the organisation: operational teams, knowledge workers, new starters and people with several managers. A process designed only around head-office roles may fail elsewhere. Describe the problem in observable terms before creating requirements.

Define the common core and local choices

Standardise what enables fairness and coordination: the purpose of the process, responsibilities, review periods, evidence expectations and correction routes. Let teams adapt useful details such as the check-in rhythm or examples relevant to their work.

Set rules for changes in role, manager, leave and project assignment. Decide who coordinates a review when several leaders contribute. Do not expect software to resolve conflicting accountability that the organisation has not discussed.

Plan the transition as a people change

Map the current process, the proposed process and the behaviours that must change. Managers need practice preparing a conversation and responding to disagreement, not only instructions for a new form. Employees need to understand what information is visible and how to correct it.

Decide which historical information should move. Importing every old note can carry irrelevant or poorly controlled material into a new system. Test migration quality, permissions and the treatment of former employees before moving approved records.

Worked example: a matrix organisation

Illustrative scenario: project leads give feedback in separate spreadsheets, while the line manager owns the annual review. Employees spend time reconciling contradictory requests.

The redesigned process names one review coordinator. Project contributors provide observations against agreed questions and periods. The coordinator discusses differences with the employee and records the final reasoning. A pilot checks whether relevant work is represented and whether employees know who can resolve a disagreement.

Transformation worksheet

• Problem: Which repeated failure affects employees or managers?
• Common standard: What must work consistently across the organisation?
• Local variation: What can a team adapt, and who approves exceptions?
• Evidence: Which information is useful, proportionate and accessible to the right people?
• Capability: What must managers practise before launch?
• Pilot: Which groups will test ordinary and difficult cases?
• Decision: What evidence would justify expansion, revision or stopping?

Assign an accountable sponsor and a delivery owner. Include people who use the process in design reviews, not only those who administer it.

Measure outcomes and expand carefully

Track whether employees understand expectations, receive useful feedback and see follow-through on development. Completion rates and administrative time provide supporting information; neither proves the conversations improved.

Run a defined pilot, review failures and publish changes before extending the approach. Keep a fallback for critical steps if tooling is unavailable. Use the continuous performance playbook to establish the everyday rhythm and the HRIS selection guide to test technology against the agreed operating model.

Put the guide into practice

Set aside a working session with the people who own this process and one or two people who experience it. Use a fictional or appropriately authorised case, so the discussion can be specific without sharing unnecessary personal information. The purpose is to leave with a usable decision or document, not just agreement that the topic matters.

Prepare the case

Map a full review cycle for two contrasting roles, such as an operational supervisor and a project specialist. Identify where expectations are set, evidence is collected and decisions are made. Include manual work outside the official system. Ask which steps help the conversation and which exist only because the previous process required them.

Write the starting assumptions down before discussing solutions. If the group disagrees on what happened, identify the information needed to resolve that difference rather than building a plan on an untested story.

Work through the decision

Design a common minimum process that both roles can use. Specify the shared purpose, responsibilities and evidence expectations, then identify legitimate local variation. Decide who approves an exception and how it is recorded. Test whether the common model supports matrix relationships without creating competing final review owners.

Ask each participant to explain the proposed decision in their own words. Differences in interpretation often reveal an unclear criterion, a missing responsibility or an instruction that will be difficult to follow.

Test an exception

Introduce a manager change during the cycle and an employee whose priorities changed after a reorganisation. Decide which evidence remains relevant and who can access it. The redesigned process should preserve useful history while explaining changed expectations, rather than pretending every employee followed an uninterrupted annual plan.

Record what changes in this situation and what remains the same. An exception should lead to a clear next step, with an owner, rather than an informal workaround that nobody can explain later.

Agree the handoff

Prepare a pilot brief for managers and employees. State what is being tested, what support exists and how feedback will change the design. Give the sponsor a decision record with evidence and unresolved issues. A launch date should follow readiness rather than substitute for an assessment of it.

Finish by confirming the owner, the next action and the date when the result will be reviewed. Give the person receiving the work enough context to continue without repeating the whole discussion.

Frequently asked questions

Should we remove annual reviews?

Start with the purpose the review serves. Some organisations still need a formal reflection point for development, performance or other decisions. Regular check-ins can improve the evidence and support around that point. Removing the annual form without replacing its useful functions can create a gap. Redesign the relationship between everyday conversations and formal decisions before deciding which meetings to remove.

How much should departments be allowed to adapt?

Keep standards consistent where they support fairness, clear accountability and reliable records. Allow variation where the work requires it, such as examples, conversation frequency or project contributions. Explain the boundary and who resolves exceptions. Excessive standardisation can make the process irrelevant, while unrestricted local design can make employee experiences difficult to understand or compare.

When should we select performance management software?

Define the operating model and priority scenarios first. Then evaluate whether a system supports those scenarios, including difficult cases and access changes. You do not need every detail finalised before exploring options, but avoid allowing a demonstration to become the process design by default. Include migration, manager capability and ongoing administration in the implementation plan.

Review the first cycle

Look for evidence that employees understand expectations and managers follow through on support. Compare the administrative burden with the old process, but do not use time savings as the only outcome. Document what the pilot changed before extending it to teams with different work or reporting structures.

Keep a brief record of what was tried, what participants found useful and what needs to change. Compare the result with the original problem rather than judging success only by completion. If the process created extra work without improving clarity, quality or support, simplify it and test again. Share the agreed change with the people who will use it, and name the person responsible for keeping the guidance current.

About New Dynamics

New Dynamics connects goals, feedback, recognition and reviews around the way organisations work. This guide is published by the New Dynamics Editorial Team as part of our practical library for HR leaders, managers and People teams.

Use the examples and worksheets to structure your own discussions and adapt them to your organisation. Illustrative scenarios are not customer case studies. Policy and employment guidance needs appropriate local review before adoption.

For questions about this guide, corrections or a conversation about your performance management process, email contact@new-dynamics.com. Explore the complete guide library for related resources.