Your mechanism for change must match your desired end state

Issue No. 11

I'm back after taking a break over the summer. One of the things I love about living in France is how seriously people take their holidays. Rightly so too. France is a fantastic place to be on holiday.

It wouldn't be a proper holiday for me if I couldn't read a few books. So, thankfully, I read a few great books while I was off, and I can't wait to share what I learned with you in a future episode of this newsletter.

This week I wanted to talk about something I struggle immensely with and which I care about massively, "how to help an organisation change".

As an engineering leader, the thought, "How can I build healthy, empowered and autonomous teams that deliver outcomes for our business", keeps me awake at night. I've been trying to build organisations aligned with these principles for a long time, and I'm still learning what it takes.

Thankfully I have worked with some great people, and one of the things I heard that has stuck with me is:

"Your mechanism for change must match your desired end state."

or said another way

"The means must match the ends."

If you want autonomous self-organising teams, enforcing a framework of how you expect them to work, such as Scrum, will not work. Or, to put it another way, you cannot impose a democracy but instead use participative design.

One of the places this idea comes from is the first of nine socio-technical design principles in a paper by Albert Cherns.

Principle 1: Compatibility
The process of design must be compatible with its objectives [...]
If the objective of design is a system capable of self-modification, of adapting to change and of making the most use of the creative capacities of the individual, then a constructively participative organization is needed. A necessary condition for this to occur is that people be given the opportunity to participate in the design of the jobs they are to perform. In a redesign of an existing organization, the people are already there.

In my experience, this principle holds.

I've struggled with this. I guess I will always wrestle with it. Whether you are building an organisation from scratch or trying to change an existing one, you will struggle with this too.

When you are trying to help a hierarchical organisation full of learned helplessness ("this is just how things are around here"), your first instinct as a leader is to rush in and try to move everything into the right place. Plus, your boss hired you with high expectations, and the weight of that is on you. So you have to deliver results fast.

The problem is that quick results and lasting change are not usually the same. If you push in new changes top-down and then market these "early wins", you can probably put in place quite a few changes and then prop them up through your position as a leader. However, if your goal was also to build an autonomous self-organising team, you missed the mark!

Hierarchical, top-down methods are usually much easier to deploy and feel more natural for a leader. So, if your desired result is a Tayloristic feature factory, go right ahead and use them.

On the other hand, if you are trying to build an agile "sense and respond" organisation, you will have to try different methods.

The approaches needed to encourage a bottom-up organisation to flourish are counterintuitive; they don't feel natural to us, and our instincts can work against us.

The good news is that these approaches do exist, and the changes, when they happen, won't be tied to you as a leader. Instead, they will spring up and self-replicate from person to person.

I'm still learning my way around all of the ways to create generative organisations.

Next week I will share with you one of the change methods I have used with great success from small groups up to hundreds of people!

That is all for this week folks. Have a great week!

Jeremy (he/him)

Don't ignore your dreams, don't work too much, say what you think, cultivate friendships, and be happy.

📌 Follow me on LinkedIn and Twitter.