“Respect” is not a team value


Last year, I wrote a blog about how teams can discover their team values. This year, I helped several customers to improve their way of working with distributed teams or got them started working in a distributed environment. This again included the discovery of the team values. Having team values, talking about team values and making them visual are all important activities to grow your team culture. You can’t decide on team culture or assign a culture to a team.

Now when I work with teams to discuss values, there are some values that get mentioned a lot – values such as trust, respect, etc. When a team asks me how many team values they can have, I always tell them as many as they want. Just look at Big Value List of Management 3.0 to get inspired. I believe, however, that it will be difficult to work with 42 values… so most teams end up with 4 to 7 values and trust, respect, etc. are often part of those values.

Then again, it always makes me wonder… please note that I don’t want a team to skip those values, but on the other hand… they are so basic: should you really mention them?

Last week, I read about “The Five Universal Values” by Rushworth Kidder. According to Rushworth the five Universal Values are:

  1. Honesty
  2. Respect
  3. Responsibility
  4. Fairness
  5. Compassion

Values that most teams, and thanks for that, explicitly mention as their team values. So that again made me wonder… next time when I am on a discovery with a team, why not mention “The Five Universal Values” from Rushworth Kidder as a given. Teams don’t need to mention these values explicitly anymore as part of their team values. This will give the teams the room to focus on their unique set of team values, as I believe and hope that the “The Five Universal Values” are always there, in any culture.

But what happens in case the “The Five Universal Values” are not present in a team? Well, then you’ve got a problem. A problem that you won’t solve by just identifying team values.

This blog first appeared on LinkedIn: https://www.linkedin.com/pulse/respect-team-value-ralph-van-roosmalen.

‘I don’t have time for a workshop,’ said the manager

This blog is about the manager and his own development.  I did a lot of recruitment… continue reading here.



End of summer… 22 mid-year reviews left

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.IMG_20160819_134507I 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?


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)")

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.

Back to my roots… auto reply in GMail

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!

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

How To Manage Three Remote Offices

This blog first appeared on the site Collaboration Superpowers, click here to view blog.