How to be a change catalyst

16 Mar 2014 / Flavius Stef / 1 Comment

Do you have a great idea but don’t know how to convince your colleagues? Learn a few techniques on how to initiate change that is supported by everybody.

We live in a world where the only constant is change. If we go back only five years ago, there was no iPad, nobody heard of Big Data and most companies did not care about “Agile”. Flash forward to 2014: if you read the tech news, it seems that every second team uses Scrum to build tablet apps with Hadoop backends.

But human beings have a natural tendency to resist change. We prefer to efficiently do what we’ve done before rather than spend energy learning new ways of working. Unfortunately, staying still is a luxury we can no longer afford. We must embrace a kaizen culture and constantly push ourselves to find better ways to do things.

But how do we make change happen when seemingly every idea we come up with gets shut down by our peers and superiors? I believe the answer lies in changing our perspective on change. New ways of working shouldn’t be driven or rolled-out by an elite few “strategizing” in their ivory tower. Rather, effective change is lit up and catalyzed by anyone while working hands-on on the problem to be solved.

9 Practices

Here are some of the practices that have helped me catalyze change:

Define and communicate purpose
Some teams want to do Scrum/Kanban/unit testing/etc. “just because”. When I work with teams, usually my first question is related to the purpose: Why are we doing this? Whenever I hear “because we want to do it” an alarm signal goes off. It means we need to sit down and figure out exactly what we want to achieve. Until we understand the purpose of the change there is no sense in moving forward. Once the purpose is clear, we communicate it to everyone and solicit input on how we could best achieve it.
Who could help?
Different people have different preferences for change. Innovators will embrace every new idea, while most people will change only after everybody else has done it. Look around in your company. Who says What a great idea! more frequently? Who is more inclined to say That will never work! Don’t spend your energy with the latter, concentrate your efforts to convince the innovators first.
Train everybody
There’s a famous Dilbert comic on agile. The pointy haired boss comes in and says: “We’re going to try something called agile programming. That means no more planning and no more documentation. Just start writing code and complaining. That was your training.”
No matter how small or trivial the change might seem, there is at least one person who won’t be prepared for it. More likely, there will be a bunch of people who won’t be prepared. Ease this burden by training everybody. Internal or external workshops, hands-on conferences, online training, MOOCs — there is a solution for every budget.
Ensure slack in the plan
Whenever we try to change something, at first our productivity will drop. Account for this in the project plans you are making. If you’ve been doing unit testing and now you want to adopt TDD, in the next release you should plan for a smaller velocity. The extra slack will allow people to practice the new skill.
Direct the rider. Motivate the elephant.
There’s an excellent metaphor for our duality when it comes to motivation in the book Switch by the Heath brothers. One part of our personality – the rider – is rational and analytic. Another part – the elephant – is emotional and loves stability.
Often times the messages we send when we try to convince people of our ideas are targeted exclusively at the rider: spreadsheets, studies etc. But even if we hate to admit it, our emotional side guides our decisions quite often. Therefore, our arguments must also appeal to the emotional side of the persons we’re trying to persuade. I remember a story where a developer desperate about the state of his team’s codebase printed the contents of a very “ugly” class and brought it to a meeting. It was 9 meters long. More examples here.
Find and promote small wins
A while ago I was leading a team of developers and we decided to try (read: “I pushed for”) unit testing. The first two days were very frustrating because we weren’t getting anything done due to the new skills we needed to develop. But in the third day one of the unit testing caught a bug. I had never heard a happier cheer from the colleague who ran the suite. We never had to argue about unit testing since.
People need proof that a change works before they invest more heavily in it. Find the first examples where the change is paying off and promote them to everybody.
Coach and mentor where needed
Training people is very useful as a first step. Unfortunately, when you don’t have experience, it’s very difficult to apply the theory to your concrete situation. I sometimes work with teams that have been doing Scrum for two or three years and there still are things which are unclear or misunderstood. A mentor who’s had experience on multiple projects can be an invaluable asset.
Find somebody who has more experience with what you are trying to accomplish and secure their support. Quite often they will be in your own company. Sometimes you can ask for external help.
Keep pushing until it sticks
The most difficult part of a change initiative is people have to adopt new habits. But to form a habit requires you do a certain routine tens of times until it comes naturally. That’s why the catalyst must spend energy to keep the fire of change alive until it can burn on its own.
Give it time
Change takes time. In the best case it will take 3-6 months to fully integrate a new element in your process. Most of the times it will need more than a year. Before you start a change initiative, ask yourself: ”Do I have enough patience and stamina to see this thing through?”

Throughout: Plan-Study-Do-Act

Organizations are complex systems. We learned that we need non-deterministic processes to be able to manipulate them. This is why you shouldn’t create a 20-step process for “driving” or “rolling out” the change. Instead, you should plan your first two or three steps, then stop, look at the result and adjust as you go.

With the companies I consult we use 2-week or 4-week review cycles, similar to the iterations in agile. Sometimes our plans and reality match, some times we see some unexpected behavior emerge. This is why it’s useful to have a purpose — it’s what guides our steps for the next cycle.

Conclusion

Companies need now more than ever the ability to rapidly adjust their processes in order to respond to changes in their environment. We need to create a culture of learning, experimentation and constant adjustment. Change should not rest on the shoulders of a select few but be sparked and catalyzed by everyone. I hope this post provided you with some advice for catalyzing your next experiment.

What about you? What techniques do you use to spark changes in your company?

Do you want to change some things around your team or company? Give us a call. Together we can plan an adaptive approach to change and we can coach you and your teams during the transition.