Getting started with Performance
Performance runs the cycles by which people are reviewed: assessments that ask questions, goals that set targets, and skills that record what someone can do. This page is the map.
Where: Performance You need: performance rights — see Performance user rights
The three things this module tracks
| What it is | Answers | |
|---|---|---|
| Assessments | Structured questions, answered and reviewed | How is this person doing? |
| Goals | Targets with KPIs, tracked over a period | Did they achieve what we agreed? |
| Skills | Capabilities, endorsed and verified | What can this person do? |
Assessments and goals both run as cycles — a defined period with a start, a set of participants and an end. Skills are continuous rather than periodic.
How a cycle moves
pending on employee → pending on reviewer → completedBoth assessment and goal cycles use the same three states, which makes the question "who are we waiting for" always answerable. A cycle stuck for weeks is stuck on one of two people, and the status names which.
The numbers underneath
Two things are worth knowing before you design anything, because both are numeric and both surprise people:
- Goal priority is a weight. Critical counts 1, Major 0.5, Minor 0.25 — a Critical goal is worth four Minor ones. See Goals and KPIs.
- Multi-select assessment questions always score maximum, regardless of the answer. They cannot distinguish between people. See How assessment scores are calculated.
Getting these two right is most of the difference between a review process that measures something and one that produces numbers people quietly ignore.
Where to go next
Running cycles
Reviewing
For employees
What Happens Next
- Cycles you create appear for their participants, who are notified.
- Scores and ratings feed team reporting and the talent grid.
- Nothing in KAMI acts on a score. What follows a review is a management decision.
Tips
- Design the questions before you announce the cycle. Editing a live cycle changes what people are being scored against after they have answered.
- Run one small cycle first. A pilot with one team surfaces every design problem while it is still cheap to change.
- Decide what the output is for — development, pay, promotion — before running it. The design differs, and people will ask.
- Brief your reviewers. Consistency between reviewers matters more to the result than anything in the configuration.