You sit down for a performance review with one person and open a dashboard bearing their name. It shows the tickets they closed, the story points they delivered, and the defects assigned to them. The discussion focuses on whether their numbers are good enough.
The person already knows what you will see. They have known throughout the review period which numbers would be used to judge their performance. That knowledge has influenced the choices they made along the way.
When you measure individual performance, you tell each team member that individual performance is what you value. People will try to improve the number attached to their name. Some of the choices that improve that number will not produce the result you want from the team.
Metrics that encourage teamwork direct people’s attention toward the delivery system instead of asking them to protect a personal result.
See the Choice That a Personal Metric Forces
Consider what happens when you measure tickets closed by each developer. Someone can spend an hour helping a teammate overcome an obstacle, but the completed ticket appears under the teammate’s name. The help benefits the team while adding nothing to the helper’s personal result.
I don’t see many teams recording the time people spend helping each other. That contribution is therefore missing from the personal dashboard, even when it helps the team finish its work.
The same problem affects story points delivered by each person. That number depends on which work the person started, which work became blocked, and how much time they spent helping teammates make progress. It describes the system around the person far more than it describes the person.
When helping the team competes with improving a personal metric, the measurement gives people a reason to protect their own number. Managers create that conflict by deciding what to measure and attaching the result to someone’s name.
I have watched that conflict produce a damaging outcome. During my consulting work, a manager wanted to improve the quality of the team’s deliverables. The manager treated the number of defects against each team member’s name as a quality measure. If someone’s count exceeded a set threshold, the manager concluded that the person was probably cutting corners.
The dashboard displayed each person’s defect count from highest to lowest. Picture your name appearing in red at the top, with twenty defects against it. The following day, you receive an email from the technical director saying that having so many open problems is unacceptable.
Would you be more likely to report the next defect you discovered? You wouldn’t.
The number of defects recorded on the dashboard went down, while customer feedback stayed negative. The team had adapted by keeping newly discovered defects out of the tool. The manager wanted defects to be reported, but the metric gave each person a reason not to report them.
Tracking defects by person had told the team which behaviour would protect their personal results.
Put Delivery Metrics at the Team Level
Removing person-level delivery metrics doesn’t mean abandoning performance reviews. You can still review the skills each person is developing and the help they give to other people. The delivery discussion moves from the person to the team.
In Kanban, managers focus on the work while team members organize around it. Delivery metrics should follow that approach by measuring the flow of work without placing workers on the chart.
A throughput run chart counts the work items that the whole team finishes each day. It doesn’t divide those completed items among individual team members. The discussion can then focus on what the team finished and what prevented it from finishing more.
This distinction matters because flow metrics applied to an individual can lead people to make choices that managers don’t want them to make. A measure intended to improve delivery can instead reward the protection of personal results.
You can identify that risk by checking whether a metric can put one person’s name at the top of a list. If it can, the metric targets a person.
Audit Every Metric You Report
Write down every metric you report across your dashboards, status decks, and review templates. Next to each metric, record whether it targets a person or the system.
Classify each one using the same test. Tickets closed per developer target a person. Defects per engineer target a person. Throughput per week targets the system. The cycle time of work items targets the system.
For every metric that targets a person, change the unit of measurement from the person to the team. Count what the team finished instead of counting what each team member finished. If you cannot move the metric to the team level, retire it.
This audit changes what your measurement system asks people to protect. A number attached to one person directs attention toward that person’s result. A system-level measure directs the delivery discussion toward how the team handles the work.
Tomorrow, list every metric you report in one column.
Next to each one, write whether it targets a person or the system.
Then move every person-targeted metric to the team level or retire it.
System-level metrics depend on visibility into the work rather than rankings of the people doing it. Nave helps delivery teams visualize their workflow, identify aging work and outliers, examine workflow stability, and use past performance to support delivery decisions. Learn more at getnave.com.
Metrics that target the system give the team a shared basis for improving the work.
I’ll see you next week, same time and place for more managerial goodness. Bye for now!
