In one sense, the key to adoption with employees is simple: Provide a service that is genuinely useful to everyone, not just to HR. Much of our effort at Appraisd is spent talking to users, learning from the feedback we receive and iterating our product quickly to keep people engaged, and it's an approach you can take yourself.
So how to you know you're providing a service that's useful to users?
An agile approach
Of course you can use surveys, polls and other methods to ask employees what they think of your performance management system. But we suggest you go further, and take an agile approach to the project delivery. An agile approach (borrowed from the tech development world) will ensure your performance management system continues to deliver on its promise long after you've rolled it out.
As opposed to the typical 'waterfall' project management, the agile approach dispenses with a long list of requirements or a full specification of the final, complete, performance management system.
The agile approach assumes you don't know what the perfect system for your company is yet, but that you'll find it along the way. Agile delivery means the project doesn't start or finish, but that it's a constantly evolving process. Agile is inclusive and responsive to users (your employees and managers). Agile, while flexible, has clear principles which you can hold on to if you're responsible for delivery.
Minimum Viable Product
- Start with a "Minimum Viable Product", the tech phrase for a simple, cut down system that does enough for it to be useful to your employees. Ask yourself and your colleagues, "What is the simplest incarnation of a performance management system that will give us 80% of what we want?". Cut out any bells and whistles and focus on the core features.
This could mean that you omit end of year ratings, requested by a single head of department but unpopular elsewhere or you wait to implement fully cascading and connected objectives for the time being. You might decide at the beginning, you simply use Appraisd's instant feedback feature instead of the more formal 360 feedback you used in the past or choosing to drop competencies for a bit, or altogether. Find the simplification that fits with your organisation.
- Obey the mantra "Release early, release often". Get your MVP up and running as soon as you can. Then it's all about iterations, fine tuning and adjustments to improve the performance management system. Some of our clients tell us they're going to launch Appraisd with just check-ins and feedback enabled. Then when it comes to the end of the year, they'll see if there's an appetite and a need for a broader year-end review. This is exactly the right approach.
- Make sure everyone understands the agile approach and why you're taking it. It's important that employees realise that their input matters and that the system will be evolving frequently, based on their feedback. Everyone needs to understand that you're not trying to deliver 'perfect' from the outset. What you're trying to deliver is an evolving system that will become the best possible approach for your organisation and culture.
- From time to time (every six months or so), invite interested people to a "retrospective". During this meeting, participants are encouraged to jot down suggestions for changing the system on post-it notes which are stuck to a board in columns: Start, Stop or Continue. Everyone reads all the notes, and votes on their favourite suggestions. Limit each person to two or three votes.
Then pick the top three ideas with the most votes and act on them, or at least present them back to senior decision makers and get a clear response. Discard the rest - they'll come up again in a future retrospective if they're truly worthwhile.
You could always take a photo of all the suggestions and distribute them to people who couldn't attend. This will help everyone understand the agile process and see how you reached decisions that you did, and that the process is fair and pragmatic.
- Repeat the retrospectives regularly and keep iterating. When someone challenges an assumption "Why do we have to do X?" or "What do we actually need that data for?", encourage them and others to debate it in a non-threatening, non-blame way. Convert those questions into a proposal: "OK everyone, let's imagine we don't do X any more. How would things work? Would anyone miss X? Why? What could we do instead?"
Some quick wins
There are also some key tips we've learned along the way that can make a huge difference.