Start by Changing Change

This is the third post in my ongoing series around principles for organisational development. The earlier articles were:

1. Nothing Ever Lasts but Change
2. Include the People Involved

Image may be NSFW.
Clik here to view.

Start by changing change. What do I mean by that? What I mean is that I believe that the most sensible way to start developing an organisation is by improving how they work with change¹. I think we need to make change itself and the skills associated with change an integral part of the start.

Otherwise, if you don’t start with change, all change will need to be imposed on people. And that’s a much harder proposition than involving people right from the start².

What’s all too common is to start with a framework, a bundle of practices that may be “Turing complete” but not make sense in our context. “All teams must use Scrum”, is an obvious example. By doing this, you are pushing a bundle of practices onto a team of professionals, which is rarely appreciated, to put in mildly².

If you are skilled change artist, then any change after a first change cycle will become more manageable. The first changes will be slow since everything is new. Every vision must be created, every current state measured, every new skill learned. But gradually, the pace of change will increase.

For example, let’s say the leadership team in a typical enterprise of today (with managers and an IT department) demand more transparency from the Development department. Stakeholders outside of IT have been getting increasingly more annoyed.

Before actually starting we need two things: 1. A large-majority commitment to a new direction², and 2. Everyone involved trained in how systematic, sustainable change works. I would suggest using a meta-model like the Improvement Kata³. People need to understand how we will follow up results (excellence is good experimentation, not necessarily great results). Most of all, participants should be asked to entertain the idea that daily improvement is important, that change is actually real work.

With this out of the way, I would consider working in this fashion.

1. Facilitate establishing a shared vision or North Star, an ideal that we may never reach. In this case, two items of the vision could be “Every stakeholder can pull accurate and understandable information on all software changes on demand” and “We respond to each idea or change proposed to any of our teams without delay”.
2. Coach the teams in assessing the current situation. In our example, the stakeholders only receive information once a month from some of the teams during their software demonstrations. Most ideas seem to disappear into to the void. Stakeholders are frustrated.
3. Facilitate setting a challenge for the department. Consider using something akin to the OKR format, combining both an engaging objective with metrics on progress. In this case, one objective could be “Give business developers a good understanding of our work in progress”. One metric could be a survey to assess the way business developers rate their understanding of ongoing work; one baseline and then metrics relative to that.
4. Coach each team in setting up their own improvement cycle. They will need an objective (a desired state) in harmony with the transparency direction, an assessment of the current situation, and a first experiment. Actively support them through that first one. Help them set up a metric for the result. Facilitate assessing the result and setting up the next experiment. Help them visualize progress.
5. Coach leaders coaching teams on improvement. It is vitally important that they ask the right questions. Good question: What is your current experiment? Bad question: When will you be done with the improvement? Support them in their first attempts at following up on team progress and visualizing the overall progress towards the objective. It is essential that managers are involved and engaged. Otherwise, people will assume it’s not that important.
6. Keep doing this until the challenge is reached or we feel it’s good enough for now and should move into another area of improvement. Go back to step 1 to refine the vision and start again. By now, the managers and the teams have not only improved, but actually learned the basics of continuous, sustainable improvement at the same time.

That was a short description of a first run through the improvement cycle. For the first run, I wouldn’t put too much at stake on the actual improvement. It’s not the point right now, more of an excuse to practice.

The next lap will be easier. Most of the structure will be in place and everyone knows the basics and what is expected of them. With each iteration, the coach may step back a bit until they can fly on their own.

After a number of these cycles, if handled mindfully, people will now see real benefits of not treating improvement as a possible side-project when we have time. And the organisation will have the basics of a learning organisation and culture, an essential capability in a digital world.

Warm thanks to Mike Burrows, Agendashift and Mike Rother, Toyota Kata, for your wise thinking around improvement.

Notes
¹This is not always the best way to start. One reason for not starting this way could be that the working climate of the organisation is toxic or just unproductive. In that case, nothing will work and you need to start there.
²See my previous post: Include the People Involved
³See Toyota Kata by Mike Rother