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.
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.
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?
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.
Many, many years ago I used to be a software developer. I loved it, build great software, or after hours of investigation find that bug in the code that made the customer unhappy. In those days, I was convinced I would be a developer for the rest of my life. Code is so easy to understand, it does exactly what you want it to do… at least most of the times 🙂
However, now and then.. I still do some development. Build small tools to make my life easier. One of the tools I build recently is an auto reply script in GMail. I searched on the internet and could only find one good solution. As stubborn as I am (sometimes), I decided to write my own script in Google App Script. Why/ Because I sometimes love to code 🙂
There is no support or whatever, you are on your own if you are going to use this script! But if you run into issues, maybe I can help you. Just drop me an email. If you improve the script, please let me know so I can add a link to this page. If you have no knowledge about java script or coding in general, I advise you to look a the solution that I found.
Click here to open the script.
So what does the script do? It checks my Google mailbox, and as soon as a message comes in with a certain subject, it will send automatically a reply. The reply is stored as a draft email. The rules, to check which messages should get a reply, are stored in a Google Sheet. As soon as a message is processed, a label will be assigned: responded.
You have to create a trigger yourself, in the Google App Script IDE. It checks the email, just once an hour. The limit of once an hour is a limit of Google App Script, can’t help it.
There is no user interface, so you need to create the rules directly in Google Sheets file. When you execute the function Init in the file Code.gs, the Google Sheet file and label will be created automatically.
Have fun with it and please let me know if you like it!
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.
I realize not everyone has a clear understanding of Management 3.0 or what the M30 workshop is about. Therefore, I regular do webinars to introduce Management 3.0 and/or the workshop. Not everyone is always able to attend the workshop, therefore, I recorded the last session. Here it is, 28 minutes. And yes, some feedback will be it was too much for half an hour, I know 🙂 Have fun and just let me know your feedback.
Spotify is cool, Spotify is hip, Spotify is epic, Spotify rules or whatever you call it nowadays. In the last month I heard three (serious) organizations saying they want to implement or copy the Spotify-model and I know some organizations are working on implementing it as we speak.
Why? I don’t know… I didn’t ask. My “fault”. However, when you a take few minutes (27:40 to be exactly) to watch the next two video’s you can imagine why.
I watched them a while ago and I thought: Wow this is cool! Wow this is hip! Wow this is epic! Wow this rules or whatever you call it nowadays. I wanna work there! But moving to Sweden, leaving everything behind did not fit in my plan at that moment (still doesn’t by the way).
I am facilitator Management 3.0 (M30) and part of M30 is Complexity Thinking. I believe an organization is a complex adaptive system (CAS) because it consists of people that form the organization, which shows complex behavior while it keeps adapting to a changing environment. Or simple: the behavior of an organization is hard to predict and it’s structure can be difficult to understand because it is all about people. When I talk about structure I am not talking about the official HR org chart, I am talking about all the communication lines, people working together from different departments etc.
It is hard to deal with a CAS but there are some guidelines. I am not going to discuss all of them in this blog, just the one that relate to I-want-to-implement-the-Spotify-Model-case.
- Use a diversity of perspectives, to handle a CAS you should use different models/frameworks. Don’t just use one silver bullet. There is not one silver bullet. So assuming the Spotify-model will solve all your problems won’t work. The Spotify-model is just one model, you should use different models;
- Steal and Tweak, the most successful complex system is constantly copying and tweaking, it is called Nature. To be handle a complex system you look around, steal an idea, tweak it and experiment with it. Stealing the Spotify-model is a good idea, but don’t forget to tweak it. Understand you need to tweak it!
- Expect dependence on context. I attended a few years ago a talk of Ken Schwaber, he refused to give answer on question like how do you do this or how do you that. His argument was that most time people will blindly copy the practice and it will fail. What worked for him, doesn’t need to work for someone else. As Ralph Stacey says in his book Complexity and Organizational Reality: “Any relationship anyone identifies between a management action and an outcome could have far more to do with a particular time and place where the sample is selected than anything else.”
The fact the Spotify-model works for Spotify is because it is their model, a result of years of experimenting. A constant Agile Mindset, inspect and adapt and be transparent.
They end the second video with the statement “Culture is the sum of everyone attitude and actions”, as we all know every individual is different, it is not possible to copy the Spotify-model to your organization.
So don’t get me wrong, the Spotify-model is super cool (that is what they say nowadays, just checked it with my daughter) and many organizations can learn from it. But, don’t copy it, use as inspiration, steal-and-tweak ideas and use it to start experimenting new things.
What do you think? Let me know your thoughts while I am listening to the music that I uploaded to Google Play Music, a super cool feature 😉