Whether we call them change programs or transformation programs (it’s just a question of scale), programs aimed at adapting the business to its environment are proliferating, but are far from systematically achieving their objectives. Perhaps this is because the way we think about them no longer corresponds to the challenges facing businesses.
The pitfalls of transformation programs
First and foremost – and there’s no need to dwell on this point, on which there’s general agreement – when we talk about transformation and change, we’re talking about scary words.
They’re scary because we like the comfort of a known situation (and even, paradoxically, if it’s uncomfortable) and because change requires effort and involves an element of the unknown.
These programs also fail because of their inability to mobilize people. We don’t change against people, but with them. Yet, more often than not, employees are seen as the subjects of change, whereas they should be the actors, and the existence of identified change agents on whom we can rely, while useful, is not sufficient.
These programs fail because they are supposed to solve a certain number of problems but not those of the employees, or at least are perceived as such. Hence their difficulty in mobilizing employees.
Finally, these programs fail because of their temporality. More often than not, they are designed to deal with an existing situation that will have evolved by the time they reach their conclusion, if they are not abandoned along the way. The problem here is that we have a two-speed business: employees in the field who are expected to be responsive, adaptable and agile, and a management that moves at the pace of meetings of its various bodies. People who think, decide, act and react in quarters impose this temporality on people who have to think and adapt on a day-to-day basis. As a result, they are incapable of answering their questions, solving their problems and accompanying them at their own pace. Management doesn’t move at the speed of business, and that’s a problem (and not just for transformation).
The need for a continuous improvement approach
I’ve been uncomfortable with the words transformation and change for some time now. For the reasons given above, of course, but also because these words imply that we’re in a transitional situation between a starting point and an end point.
The truth is that, in an increasingly fast-moving world, once the arrival point has been reached, and even if by chance the change implemented still corresponds to reality, a new change project will be set up on one subject or another. This leaves employees with the impression that it’s never-ending, and ultimately with a feeling of insecurity and exhaustion.
In this story, everyone is right. The business, which has to continually adapt, and the employee, who feels that it never ends. But maybe it’s just a problem of wording.
I once had to take over a team that I would describe as dysfunctional. Not humanly, but organizationally. We had to throw everything out and rebuild. I don’t like lying to people, but I wasn’t convinced that, given what they’d been through, it would be a very motivating speech – quite the contrary.
What’s more, I needed their help to get things done. This meant making this program for change a reality in their minds and in their schedules, alongside the already heavy workload of their jobs.
So I thought about what would make things acceptable.
The first thing was for them to understand that the aim was to help them in their work. That we were going to change things for them, and that they would be the primary beneficiaries.
The second was that fast results would be needed to convince them that this wasn’t just empty words.
So I decided to leave the words change and transformation in the drawer and talk about continuous improvement, for a number of reasons.
– Improvement suggests that there are benefits to be expected, for them.
– Continuous suggests that it’s an ongoing process. No beginning or end, but something permanent, smoother, smoother.
– Continuous improvement suggests a logic of small incremental improvements, not a big bang at the end of a long tunnel.
I was expecting another benefit: to bring all the subjects under a single program, to make improvement a permanent process anchored in people’s minds, something that would become part of the team’s culture and DNA.
So, in hindsight, here are what I see as the founding principles of a successful continuous improvement approach.
Sourcing issues within the team
Of course I knew what I wanted to do first, but I didn’t presume to imagine that I was the only one, especially since if there were any dysfunctions they were the first to be confronted with them.
So instead of coming up with my list, I asked them what was preventing them from working as well as they’d like. Strangely or not, we came up with the same thing, and they even brought up things that had gone under my radar.
Once again I had confirmation of one thing: it’s easier to get people to change when they know that it solves their problems and when they’re involved in the solution. All the work is done upstream and then it happens by itself. Or almost.
First victory: they understood that the approach was designed to help them.
Adopt an agile approach
The idea of incremental improvements was at the heart of the approach , and nothing lends itself better to this than agility, which I used in a “non-integralist” way, in other words by keeping the principles but without wanting to be more royalist than the king.
A one-hour meeting with the whole team every two weeks, at which we identify areas for improvement. It was important to separate the subjects: there were the meetings where we talked about the day-to-day running of the business and any problems we were trying to solve. In the latter, we took a step back to attack the root causes: why did something go wrong? A more systemic approach that helps prevent the same problems from recurring.
I’ve always been convinced that when things went wrong, the culprit was more often the system than the individual, and Deming tells us no different: 96% of problems have a systemic cause, not a human one. And this has been confirmed: almost all the problems that could have been attributed to an individual had in fact been caused by a poorly thought-out process, a lack of training or information, a defective tool, a lack of clear guidelines in a given circumstance, etc. The system was then broken down into the solutions that could be found.
We then broke down the solutions we had to provide into micro-tasks, which ended up on a JIRA board. We prioritized them and divided them up according to each person’s skills, and we had 2 weeks, until the next meeting, to get the job done. And very quickly we saw concrete changes, gradually but surely.
2nd victory: they were convinced of the merits of the approach, raised more and more issues and were the driving force behind the implementation of initiatives.
3rd victory: the process existed in their minds, and part of their time and attention was devoted to it, because they saw what was in it for them. It didn’t take time away from their work, because it enabled them to work better and reduce the number of problems they had to deal with.
Breaking down silos
When you’re managing a team with a central role in a business, you ‘re quickly confronted with the issue of silos.
Sometimes the cause of problems lies elsewhere, in another team, another BU. Sometimes it’s at home, and the decisions you make will have an impact on others, which is inevitably a source of tension.
So I invited all the bosses of the other BUs to join the meeting. They were happy to do so, as it gave us a chance to hear their voices, sometimes arbitrating on the basis that the solution applied here would create more problems elsewhere (so we all knew why we wouldn’t get as far as we’d planned), and more often than not, solving their own problems. It started out as an exercise in transparency to make things easier, and has become a fruitful exercise in cross-functional collaboration.
There’s no opposition in principle between different professions in a business…as long as you get people talking to each other.
4th victory: I created cross-functionality and gave a voice to people who had the impression that nobody was interested in their problems.
Being benevolent
Benevolence is such an overused concept that I avoid using it, but there’s no other word for it here.
When someone identifies a problem, it’s usually because they’ve found themselves in difficulty, and what they fear most is being blamed for it. No-one wants to be the victim of both an organizational problem and the wrath of a manager who will look no further than the tip of his nose and say “if you’ve had a problem, it’s because you’ve done things wrong”.
The “blame the system, not the individual” approach was a lifesaver. As time went by, reticence faded and everyone dared to talk openly about situations they might not have shared before, so that the root causes could be found.
There were even some unexpected side-effects. In meetings where we really talked about day-to-day operations, people were no longer afraid to say “I’m the one who screwed up”, because they knew we weren’t there to beat them up, but to find solutions (provided the lesson had been learned).
It may seem obvious, but getting people to say “something not quite right happened and I had nothing to do with it, but now it’s all my fault” is something very rare in the business world.
Add a touch of humor to the mix, de-dramatize things and you’ve got a serene atmosphere in which to work, and a team capable of dealing with anything calmly, without stress or fear. Just because you’re doing something serious doesn’t mean you have to dramatize everything.
5th victory: confidence restored and strengthened within the team.
Bottom line
I feel like I’ve written a long post full of platitudes, but the fact is that the most obvious things and common sense aren’t what you find most often in business.
Listening, observing, engaging people, dealing with their problems and solving them, earning trust through results and attitude, isn’t that just not a manager’s job?
I could have gone more vertically, without them or even against them. The actions to be taken would have been virtually the same, but would I have achieved more than 10%? And then I needed them: from a technical and business point of view, they were all infinitely more competent than me, but I wasn’t being asked to do their work, just to create the context for them to do it as well as possible. A nuance that many managers forget. To manage is to animate, to unleash the potential of your team and to make things possible.
In the end, I had a team that I could practically leave on autopilot, so that I could devote myself to the human dimension of management. And a bit of pride in having created something rare: a meeting that everyone wanted to attend and be invited to, that sometimes they would have liked to have lasted longer and for which they looked forward to the next occurrence.
In short, change isn’t complicated when you keep in mind what it’s supposed to do: help people succeed.
Image : Change management by EtiAmmos via Shutterstock
