How to change at the speed your business can handle

Most businesses want to improve. Not many want to live through another change programme.

That is totally understandable. People have customers to serve, deadlines to meet and ways of working they have spent years refining. When a new system or process is announced, the immediate question is often, “How am I supposed to do this as well as my day job?”

It is easy to label that response as resistance. I think it is more useful to find out what sits behind it.

Why change feels difficult

  1. Sometimes people do not understand the reason for the change. Leaders can see a problem across the whole business, while the people doing the work see a process that already works well enough for them. If nobody explains the wider problem, the proposed solution can look like extra effort for no clear benefit.

  2. Sometimes people understand the reason but worry about what they will lose. A familiar process gives them confidence and a degree of control. A new one may expose gaps in their knowledge or change responsibilities they have held for years.

  3. And sometimes their concern is entirely practical. They have seen previous initiatives announced with enthusiasm and then left unfinished. They know that learning a new way of working takes time, even when the eventual result will be better.

None of these concerns disappears because leadership sends another email about the benefits. People need to be heard, involved and given the time and support to work differently. Trust and employee involvement in organisational change is vital. And getting the pace right means understanding how much change people can realistically absorb while doing their day jobs.

What happens when the pace is wrong?

There are public examples of what can happen when a major change reaches people before the business is ready to support it.

In 2018, TSB moved its services to a new IT platform. The data migration succeeded, but technical failures on the new platform caused significant disruption to branch, telephone, online and mobile banking. The Financial Conduct Authority later identified failings in how TSB had managed the risks of the migration, specifically calling out an excessively ambitious migration timetable and inadequate board scrutiny of the timetable and readiness in its final penalty notice.

For me, the lesson is that a successful technical transfer is only one part of a successful business change. The service still has to work for the people depending on it. It’s a lesson that I’ve learnt over and over in my career and one which I hope shows in the way I operate.

But moving slowly brings problems of its own. In another example, Universal Credit’s implementation took substantially longer than originally intended. In 2018, the National Audit Office reported that the extended rollout had delayed expected benefits and left uncertainty about whether the programme would deliver value for money. A more gradual approach can reduce some risks, but an extended transition has a cost too.

These are very different programmes, and neither can be reduced to a simple argument for or against gradual change. They do show why the pace matters.

Start small, but know where you are going

My preference is to introduce change gradually – I hate a “Big Bang” approach. Choose a useful part of the business, try the new approach with the people who do the work, and learn what needs fixing before widening the rollout.

That gives people a chance to ask questions and see a benefit for themselves. It also gives the business evidence about whether the change works in practice. This approach is reflected in the UK Government Service Manual’s guidance to test with users, learn from feedback and deliver in iterations.

But gradual must not become indefinite. If an old and a new process run side by side for too long, people may have to do the same work twice. Reports become difficult to reconcile. Teams choose different ways of doing the same thing, and the business waits for benefits that never quite arrive.

The answer is to give each stage a purpose and an end point. What are we testing? What would tell us it is working? What must be fixed before the next group moves across? When can we retire the old way of working?

Those questions keep the change moving without asking everyone to take the same leap on the same day.

Make room for the work

A change programme is often treated as an addition to everyone’s existing responsibilities. That is one reason it slows the business down.

“It also helps to be honest about the awkward period between the old and the new. ”

If people need to help design a process, test a system, learn new skills and support colleagues, they need time to do it. Managers may need to adjust priorities. Leaders need to make decisions when problems are raised, rather than leaving teams to work around them.

It also helps to be honest about the awkward period between the old and the new. There may be a temporary dip in speed. The aim is to keep it manageable and short, while making sure the new way of working genuinely improves what came before.

Find the right pace for this change

There is no universal timetable. A small change to an internal process may be introduced quickly. A change affecting customers, sensitive information or a critical service needs more testing and a stronger plan for what happens if something goes wrong.

What’s more, people are more likely to accept change when they understand why it is needed, have a hand in making it work and can see that their concerns lead to action. That is how change becomes part of the way the business operates, instead of becoming another initiative people have to work around.

So I ask three questions before deciding the pace:

  • What is the cost of moving too soon?

  • What is the cost of waiting?

  • What evidence do we need to move to the next stage?

The balance will vary, but the principle is straightforward: make the steps small enough to learn from and decisive enough to make progress.

Previous
Previous

What would technical due diligence reveal about your business?

Next
Next

The Hierarchy of Data Needs