Last week’s Build issue on reorganisations that never end sent me down a bit of a rabbit hole about change. Right now I’ve got two live projects where change is a particularly strong theme (although of course it’s a common strand across everything I’m working on, as ever).

The thing that’s been buzzing away in my mind has been about we build organisations that can cope and thrive on constant evolution. For the theory geeks on this stuff, it’s a rejection of Lewin’s unfreeze-change-refreeze model of change which has its origins more than 80 years ago – a different time.

So I’ve spent the last week reading everything I could find on organisations that change continuously rather than in big bangs. From all this reading the thing that’s stuck with me most is an admission:

Some of the people, like me, who’ve championed radically new ways of working for the last ten years have started saying fairly openly that a lot of it didn’t work. A lot of the case studies being cited about where new ways of working made a difference seem to be the same ones I first read in Reinventing Organisations a decade or so ago.

What went wrong (roughly)

The story goes something like this: lots of organisations adopted the visible bits of new ways of working – retros, new meeting formats, new operating model diagrams, radical transparency etc.

But then in reality they grafted them onto the same old way of making decisions and the same old relationships between leaders and everyone else.

So the new practices sat on top of an unchanged system, giving the veneer of meaningful difference. And then when the leader who’d championed them moved on, things drifted back to roughly how they were before.

The other reason they give really struck a chord with me. Teams were so stretched delivering the day job that they had no capacity left to actually get good at anything new.

To be honest, I recognise every part of that. As an MD running a digital agency, I introduced more than one new ritual that felt great for a quarter and then got lost in the managed chaos of agency life. Back then I often thought the problem was the ritual, so I’d usually go looking for a better one.

The pattern I see with founders

A lot of founders I work with (and leaders more generally) treat change as a project. It has a start, a plan, a launch and (crucially) an end date. Once it’s “done” everyone gets back to normal work.

The trouble is there isn’t really a normal any more. Maybe there never was. The team keeps changing and AI is changing how the work itself gets done almost month by month.

So the change project ends, the world carries on moving and a year later there’s another change project. And it’s usually a bigger one.

I’ve come to believe the perfect new design matters a lot less than the ability to keep changing well after the project is over.

I think of that change-ability a bit like a muscle. It gets stronger the more you use it and it wastes away if you only go to the gym every January.

Building the muscle

If you’ve been reading Build for a while you’ll know I tend to look at things through the lenses of people, practices and technology. Getting good at change touches all three, but most of what I’d suggest trying sits in how you run things day to day.

Here are a few things I’d suggest based on my work with founders grappling with the volume and velocity of change:

• Make room before you add anything.
  Overloaded teams can’t absorb change, however good the idea. Before you introduce a new process, ask what you’re going to stop doing to make space for it. Cancelling a recurring meeting or killing off a few low-value projects is part of the change, not a distraction from it. I’d also argue for keeping a bit of deliberate slack in the system even though that feels uncomfortable for most founders.
• Give change a rhythm.
  Change that only happens when someone has the energy to push it will always fall back to the old ways. Planned regular team retros and a periodic reset of priorities are what make it continuous. I like doing this quarterly, but go for what feels right. I’d say the rhythm matters more than any particular individual change you make through it.
• Sort the reversible from the irreversible.
  This is a favourite of mine. Some changes are harder to undo, like a restructure or a senior hire. Those deserve careful thought and probably sit with the founder and leadership team. But most changes to processes, rituals and tools are easy to reverse. Let the team members doing the work try those as small experiments for a set period and then decide together whether to keep them. Remember: if almost every experiment “succeeds”, they probably weren’t really experiments.
• Plan for what people lose.
  People don’t really resist change so much as losing things – for example a bit of control or the sense of being good at their job. If you know who’s losing what, you can design for it rather than being surprised by the pushback. And start with what people will actually do differently on Monday morning rather than a carefully wordsmithed announcement. In my experience visible behaviour shifts attitudes far more than messages do.
• Change the leadership team first.
  Your leadership team sets the ceiling on how fast everyone else can move (that’s a very mixed metaphor but hopefully you know what I mean). If the way you make decisions together and run your meetings hasn’t changed, asking the rest of the business to work differently is going to be a hard sell. Your team will notice the double standards pretty quickly.
• Judge by whether the work got better.
  It’s tempting to measure change by whether people have adopted it – everyone’s using the new tool or every team runs the new style meeting. But adoption isn’t really the point. Are decisions still sticking? Is there less rework? Are the same problems coming back round less often? Without some signal like that you can’t tell useful change from churn.

Why AI makes this more pressing

I want to be clear – I don’t think AI changes the basics here. But it does speed everything up (a lot).

How you split work between people and AI tools today probably won’t be right in six months. The tools will be better, the risks will look different and your team will have learnt a lot.

So I treat every decision about how AI fits into the work as provisional. I suggest you try things in real work, keep what genuinely makes a difference and agree upfront what would make you look at it again (this avoids a couple of the usual biases we have when evaluating effectiveness of trials).

That’s only manageable if revisiting things is already a normal part of how you run the business. If it isn’t, I wonder if AI just becomes another source of big, disruptive change projects for many businesses?

The bit I keep coming back to

The best measure of a change is probably whether your business is better at changing tomorrow, rather than how good the new org chart or process or whatever today’s favoured change initiative comprises.

That’s a different way of thinking for most founders I work with. It means caring a bit less about getting the design right and more about building a business that can keep adjusting it without everything grinding to a halt.

So as usual here’s a few of the things I’m currently asking my founder clients as a result of the thinking behind this issue (I like to think they love me for asking the difficult questions):

• What did your last big change actually stop your team doing to make space for meaningful change to happen?
• Which recurring moments in your or your team’s calendar are there specifically to notice what needs to change?
• Has your leadership team changed how it works in the last six months – or have they been more concerned about only how everyone else works?
• How would you know if your last change made the work better rather than just different?

As ever I’m always happy to chat any of this through. Helping businesses get better at changing (rather than just getting through the next change) is rapidly becoming one of my favourite parts of my work.

​