Competency-based feedback: behaviour into development

Define observable competencies, collect relevant examples and build useful development actions. This practical guide to competency-based feedback 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.

Define the behaviour behind the label

A competency describes a capability needed to do a role well. Labels such as collaboration, judgement or ownership become useful only when people understand what they look like in practice. Start with the work and describe observable behaviours at the relevant level.

For example, collaboration might include sharing information before a handover, clarifying responsibilities and resolving a dependency constructively. Avoid describing an ideal personality. Someone can contribute effectively without being the most vocal person in the room.

Distinguish expectations by role and scope

The same competency may look different for a new starter and a team leader. A new starter might identify an uncertainty and ask for help. A leader might establish a decision process for a whole team. Neither should be assessed against responsibilities they were not assigned.

Use a small set of competencies and concrete examples for each level. Include contributions that are less visible, such as careful maintenance, mentoring and preventing avoidable errors. Test the language with employees doing the work before using it in a formal process.

Collect examples rather than adjectives

Ask contributors to identify a situation, what the person did and the effect on the work. “Reliable” is a conclusion; “flagged the missing dependency before the release decision and agreed an owner” is evidence that can be discussed.

Consider opportunity as well as behaviour. If someone has not led a cross-functional project, a lack of examples does not prove a lack of capability. Record “not observed” and discuss an appropriate development opportunity instead of filling the gap with an assumption.

Worked example: decision quality

Illustrative scenario: a review says an analyst should “be more strategic.” The manager and employee identify the actual need: explaining trade-offs when presenting a recommendation.

They agree that the next proposal will describe the problem, two viable options, assumptions and a reasoned recommendation. A colleague reviews the draft before the meeting. The follow-up examines whether the decision makers understood the trade-offs, rather than whether the employee sounded confident.

Competency worksheet

• Capability: Name the skill or behaviour relevant to the role.
• Role expectation: Describe what good practice looks like at this scope.
• Observed example: Record situation, action and impact.
• Context: What resources, constraints or opportunities affected the work?
• Development experiment: Identify one behaviour to practise in real work.
• Support: Name a coach, example or practice opportunity.
• Review evidence: Agree how progress will be discussed and when.

Use the worksheet for a small number of priorities. A catalogue of every possible competency rarely produces a focused development conversation.

Calibrate interpretations and follow through

Ask managers to compare how they apply the definitions to fictional examples before assessing employees. Discuss differences in interpretation and improve ambiguous wording. Do not force a distribution of ratings simply to make the process look consistent.

Review whether examples cover the full period and the employee’s actual responsibilities. Let the employee add context or correct facts. Connect the agreed action to the career development guide and revisit it at a check-in while there is still time to practise.

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

Choose one competency used in the organisation and ask participants to describe observable examples at two levels of responsibility. If the examples depend on personality words, rewrite them as actions in a work situation. Check whether people doing less visible work have a fair opportunity to demonstrate the capability.

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

Use a fictional contribution to practise writing feedback. Separate the behaviour from the result and explain why it mattered. Ask whether the evidence supports the claimed level or only one aspect of it. A successful outcome can involve luck or other contributors, so discuss the person’s actual actions.

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

Consider an employee who has not had access to the projects that usually demonstrate the competency. Decide whether to record insufficient evidence, offer a practice opportunity or use another relevant example. Do not convert a lack of opportunity into a confident statement that the person lacks potential.

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

Agree one development experiment with a clear observer and feedback point. Give the employee an example of the desired behaviour and the resources needed to practise. The manager should confirm what work will be adjusted if the development task requires additional time or coordination.

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

How many competencies should a framework include?

Use a manageable set that reflects important work and can be explained clearly. There is no useful universal count. A long list can lead reviewers to tick boxes without evidence, while a very broad set can hide meaningful differences. Test whether managers and employees can apply each definition consistently and remove overlapping labels that do not change a decision.

Should competencies have numerical ratings?

Ratings can summarise an assessment when their meaning is clear, but they do not replace examples. Define the anchors, check how reviewers apply them and include a way to record insufficient observation. Avoid treating a small difference between numbers as a precise measurement of ability. The development conversation should remain understandable from the evidence and context behind the rating.

Can the same framework apply to every role?

Some shared behaviours may apply widely, but the examples and scope should reflect the role. A junior specialist and a senior leader can both exercise judgement while making very different decisions. Use common language where it helps coordination, then define role-relevant expectations. Check that the framework does not reward only one communication style or one type of visible achievement.

Review the first cycle

Review whether feedback became more specific and development actions became easier to practise. Ask employees whether they understood the expectations before assessment, not only after receiving a rating. Improve definitions that repeatedly produce disagreement and check whether the process gives people meaningful access to development opportunities.

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.