How do you create pain? – How to get change started

I live in The Netherlands in a small village a couple of kilometers from the city of ‘s-Hertogenbosch. When you grow up in The Netherlands, you most probably will have learned to ride a bike, because it is very convenient to know how to ride a bike here: a flat country with bike lanes everywhere . Additionally, when you live in a small village, it is also very convenient when you know how to drive a car. Most villages only have just a small supermarket and the connection to public transport is simply not that great.

My girlfriend is not from The Netherlands. She joined me quite recently and she quickly realized that it is important to be able to ride a bike to get around, to refresh her driving skills, to learn Dutch, to build up social relations, to get to know your way around: a lot of things she needs to adapt to quickly.

At this moment she just focuses on one thing… refreshing her driving skills. She knows all the things mentioned above are important, but commuting daily via public transport for almost four hours “hurts” the most. Therefore, she gives priority to something that is important and urgent because it pains her the most.

It is the same in organizations. If it doesn’t hurt, you won’t change. – (c) familymwr494

Many of you will have been participating in some kind of transformation program, will have worked as a change agent, or maybe you were involved in some kind of important project. It probably often happened that resources were not available as you would like, or that other people didn’t cooperate as you would like. When you asked management or other team members: is this project important? They all will have said: Yes, very important because… whatever. But if you would have asked does it hurt somewhere because this project is not progressing as expected, they probably would have said: “uh… now… you know… well… uh…”

In his book Leading Change, Kotler describes eight steps for managing change. The first, and one of the most important steps, is to create a sense of urgency. He describes nine ways to create an urgency level. The first and most powerful one is to create a crisis by allowing a financial loss, exposing managers to major weaknesses vis-à-vis competitors, or by allowing errors to blow up instead of being corrected at the last minute. The reason this one is so powerful is because it hurts. There is money involved. Now, as one of my friends always says: “Never waste a good crisis”.

ADKAR is a method created by Prosci. They researched organizational change, and believe that change is a cumulative product of the personal change journeys of each individual within the organization. The first condition, the A, that you need to experience is: Awareness of the need for change. The second condition is D: Desire to participate in and support the change. The desire represents again the pain that you have of the current situation. If there is no desired change, then you won’t change although you are aware you need to change. According to Prosci, if any of these five conditions are weak, the change will stall and fail.

Creating urgency is good, making sure that people realize the project is important is good. However, when people or organizations feel pain because a project is not done, it is one of the best motivators to start change or a project.

How do you create pain to realize a change in your organization?

“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:

‘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.

How To Manage Three Remote Offices

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