Summer in Europe… everything slows down… temperature rises… and Northern Europeans all go south, beyond the Alps, to enjoy the great weather in Southern Europe. People enjoying the pizzas in Italy, the beautiful cities of Spain, the impressive nature in Croatia. Unfortunately, everything ends, also the summer.
I met a friend of mine in Italy, he is a manager, and we were discussing work and the fact that he was not looking forward to getting back to work after his summer leave. Not because he doesn’t like his job, definitely because he likes the way of living in Italy, but primarily because he still had to do 22 mid-year reviews. 22 mid-year reviews… One of the advantages of being self-employed/having your own company is that the mid-year reviews are pretty easy 😉
One manager at one of my customers had the same problem, he had to do all the mid-year reviews in a few days because HR set a deadline.
I never yet met a manager or lead who really likes to do mid-year reviews, or year-end reviews. So how can we can change this? I read a blog about SAP, they are planning to kill the ‘dreaded’ Annual Performance Review and they are replacing it with a “Continuous Performance Management Solution”.
This made me think… continuous performance… continuous development… continuous builds… continuous integration…
I have been working in the Software Development industry for many years now, and I believe that there are some things HR can learn from software development regarding reviews. I will try to explain some of the terms, in case you are not familiar with software development.
Continuous Integration
In the old days, software was merged once a month, once a week, etc. Developers created code on their machine and now and then they would merge their new code with the new and old code from other developers. When you merge work every now and then, you can imagine it will cause problems. You don’t know what other developers are doing, whether they touched the same code and how things should come together… let’s put it like this: I once worked at a company where people spent two days per month on integrating the code, and those days were famous… or infamous, depending on how you looked at it. Nowadays, software developers prefer to merge code constantly.
It is the same with team members and managers. When you don’t often meet, you don’t know what is happening. When you just meet twice a year… it can happen things are not in line anymore and perhaps things are even badly out of sync. So just like software developers, as a manager you should meet your team members often. Not just twice a year, but continuously.
Release Often
Ten years ago, software was released once every two years, or maybe once a year. How often do you get new versions on your phone nowadays? How often do websites add new features? Releasing software is now done as often as possible. The idea is to learn fast from your releases, the faster you receive feedback from your customers, the faster you can improve your software.
So how can we learn faster from team members? Again, not by having meetings just twice a year. You need to learn fast, you need to collect feedback from your team members early and often. Meet your team members regularly, but also think about other ways of getting feedback. Can you set up a happiness door in the office where people can constantly provide feedback, or measure the happiness of the team a few times a week by using the happiness index?
Documentation
It is a good practice to document code, developers should add comments to the code. However, there is a difference between writing documentation and writing documentation. For example, take the following pseudo code:
//When variable sInput is equal to "(y)" print "thumbsup"
if (sInput == "(y)")
print("thumbsup");
Every developer can read this code and understand the code immediately. So the documentation is adding no value at all. It would have been much more interesting to explain why (y) should be translated to “thumbsup”.
It is the same with reviews, you need to write reports of the review meetings. However, do these reports really add value? Or are they just formal reports, where you say somebody is feeling happy about his job (or even worse you rank them… :O). Write down why somebody is feeling happy, write down what were the motivators for someone that made him feel good or bad.
Backlog, Goal Oriented
There are organizations where the customer exactly describes what they would like to have. They describe the features in details, so detailed that there is no freedom for the developer to maneuver anymore. The developer is asked to make an estimate for the requirements. The requirements are detailed, so the customer also expects a detailed estimation and the developer needs to deliver what exactly is specified.
Nowadays, more and more organizations are using a different approach. They use goals, or describe requirements using examples. This will give the developer more freedom to create the software: instead of trying to write everything down, the developer communicates often with the customer.
In reviews you can give team members specific targets, based on KPI’s, revenue, etc. However, the world is changing so fast that often the targets are no longer valid when they are reviewed again. Therefore, why not just, like in software development, use goals? In the book Beyond Budgeting for example, they use goals related to the competitors.
As a manager, give your team members goals that also require some creativity of themselves. Furthermore, review the goals frequently. Not twice a year, but for example with every 1-2-1 meeting you have. If you do it often, it doesn’t need to take long.
In the end…
My friend still has to do 22 mid-year reviews, but more and more companies are changing their review process. Not only small start-up companies but also companies like SAP and Deloitte. Many organizations realize the traditional review process is not a fit anymore. So if you also need to do a lot of mid-reviews, maybe you should start a discussion about the value of this process using this blog, or the blogs about SAP and/or Deloitte. But, I think everyone feels the old traditional review process is no longer adding the value it once did.