On September 27, 2017, I participated in a Meetup of the Agile HR community. The theme of the meetup: How to redesign performance management for an agile world. At the meetup I gave a short presentation, sharing some of my views on the subject.
Performance Management: Why?
There are several objectives of performance management.
- Development. Give people and teams feedback, that can be used to become better, for current and future roles.
- Direction. Help people and teams to move in the required direction.
- Recognition. Give people and teams recognition for their accomplishments and efforts.
- Pay. Gather input that can be used to determine the right pay levels, for individuals and teams.
If done well, the performance management process should lead to an increased engagement and increased productivity of the teams and the individuals being part of an organisation.
Performance Management as we do not like it
In the last years, performance management has got a somewhat negative connotation. The typical performance management processes as used in many organisations (still today) had some negative aspects:
- Too slow (often designed around an annual cycle)
- Too much top-down (the manager appraises his people)
- Too paternalistic (“As I am your senior, you can learn a lot from me”)
- Too dependent on managers with generally poor feedback skills
- Too much driven by the organisation (we determine what we would like to see, and then rate against our criteria)
- Resulting in ratings (“Your overall rating is a 3.5”)
- Too complex (often long lists with criteria)
- Not very actionable
- Too much connected to pay, not enough to development
What do we see today?
Recently many organisations have made attempts to redesign their performance management process. What do we see today?
- The frequency of feedback has gone up
- Feedback apps, as Impraise and TruQu, are gaining traction
- Using multiple raters (360) is becoming mainstream
- A move away from ratings (but some early adapters are already moving back…)
- A focus on “Good conversations”
- A tendency to make the feedback more superficial (“Good job!”)
- Still relying very much on humans to gather and give the feedback
- Still very much an internal focus (“We have to organise this for our organisation’)
- Still a desire for a standardised organisation-wide solution
Designing Performance Management for agile organisations
What are elements to consider when preparing your design criteria for the design of a performance management process that is suitable for organisations that have adopted agile ways of working?
1. One or more processes?
As summarised in the visual with this article, the performance management process is serving various objectives. Question is if it is wise to try to serve all objectives with one process. Some examples of alternatives:
- Focus on development, and design other processes for the other objectives
- Carve out recognition. Giving recognition is relatively easy to organise, and probably it doesn’t need a lot of process (more a mind-set)
- Embed goal setting in your agile team processes, and limit individual goal setting to the formulation of developmental goals
2. Do we need a uniform process?
Do you really need a uniform, organisation wide process? You can also give the responsibility to the teams, and accept there is a great variety of solutions. If teams share their approach, they can learn from each other.
3. Employee focus and organisational focus?
The starting point for many organisations is still the organisation. How can we make sure our organisational goals are reached? It is difficult to turn this around, and design the processes with the requirements of the employees in the centre. Most likely there is a lot of variety in the wishes of the employees, which makes it even more difficult to design processes that can meet the different needs. A real employee centric organisation can to do this.
4. Feedback: how frequent?
The question about the frequency of feedback is related to the earlier questions. We see some advanced organisations starting to differentiate. Differentiate per goal, and differentiate per team. Per goal: e.g. recognition as frequent as possible, goal setting reviews very much connected to the OKR process, developmental feedback frequency more connected to the maturity of the employee, and pay reviews related to the labour market volatility of different groups (high volatility = more frequent reviews). Per team: dependent on the maturity of the teams, and the domain where the team is active (E.g. more frequent in client facing teams, less frequent in R&D teams).
5. How do we help good people to become better?
Especially for developmental purposes, feedback needs to be very specific. I refer to an earlier article, Improving Performance Consulting, for more details. I think it is too ambitious to expect all team leaders to be able to give high quality feedback. Maybe it is better to rely on people who have really developed this skill. These performance consultants can be very helpful, especially in helping top performers to become better.
6. How can we become less dependent on human beings?
Today we very much rely on human beings to make observations and give feedback. Tech can help us to gather and interpret data on individual end team performance, and for giving feedback there might also be good technical solutions (Read: “When will we see black boxes in the boardrooms“?). The sports world is more advanced when it comes to gathering data with technical devices, and using the data to improve performance.