Once you have become aware of what employees really do at work and have identified all the factors that generate frustration, pain and inefficiency, the next step is to know how to improve things for the benefit of your employee experience and, ultimately, for the benefit of your customers, your company and your employees.
In this area, improving things rarely means being satisfied with superficial measures. Yes, sometimes part of the problem lies with the employee and it is up to him to work on it. Problems of organization, prioritization, letting go, separation between his professional and private life in the context of imposed and badly lived remote work, or even problems with remote work in general …
Yes, these cases exist and are to be treated for all or part of the individual through (auto?) coaching and a soft skills oriented program. But that is not all and in terms of experience in the operational field the remedy is at the system level and not at the individual level.
How to proceed given the scope and complexity of the subject?
Learn how to change the wheel of a moving car
Before deluding ourselves, we must remember the context that we all know but that some like to forget as much as others use it a little too willingly as an excuse to do nothing.
Your teams have a mission, a job to do every day. That’s why they’re there, why they’re paid and the criteria by which they’re measured.
Besides that you will have a transformation plan. A real transformation insofar as we are going to touch on processes, workflow, roles, tools, management interfaces, control and coordination? A task that will constitute a project as such. In addition to the day-to-day projects that keep the company running.
You will even have different transformation projects. Having done it and doing it myself, you will not be able to address all the activities of your team through a single site. This is unrealistic. For my part, I identified 5 components to my project from day one, knowing that others have emerged over time. So I had to prioritize them or even move them forward at times, either simultaneously or alternately, depending on their interdependencies.
You will therefore need to lead the transformation of your business model (because that’s what we call the more salesmanlike and experience-intensive term used) at the same time as the current model and organization are functioning. At the same time and often against!
Indeed the heritage of Taylorism is strong in today’s companies and even in the so-called service companies or those whose job is to transform and produce information or knowledge. They are conceived according to the historical industrial model whose objective is to “replicate perfection ad infinitum” by considering (rightly in this very precise context) that deviations and exceptions are the enemies. Today when one tries, precisely, to make an organization make a deviation in a context where exceptions become the norm for certain industries, the protective model simply scores against its own side.
Companies (especially in France) are also vaccinated against what they haven’t invented. The “NIH” syndrome for “Not Invented Here” kills every year many viruses (or seen as such) that are only “imported” ideas from outside. But today in many fields good ideas have already been invented elsewhere, the experience already exists elsewhere, it remains to be understood what to retain and how to adapt it without copying stupidly. But there is still a filter that too often prevents this from happening.
So transforming the operational experience of its employees means not only changing the wheel of a moving car but, what’s more, with a wheel equipped with anti-theft nuts!
This is what distinguishes the startups that are constantly being held up as examples for their innovative models from existing companies. Starting from scratch and transforming a running organization are two radically different things. I don’t know what the founders of Amazon, Tesla or Spotify would have done if they had had to take over one of their legacy competitors. Besides, in the case of Tesla we also realize that their manufacturing model is not scalable and that they have to copy the “old” ones in the industry. The example of how Netflix (which initially rented DVDs) transformed itself or how GE, IBM, St Gobain, Peugeot and in general all these century-old companies, or almost all of them, have transformed themselves over time, is at least as interesting.
Big bang or small steps ?
In the digital world, when a wave seems to push companies to change all at once, we often speak of a revolution. We’ve seen what’s happened with all the revolutions we’ve seen in recent years: digital revolution, data revolution, new generation revolution, web 2.0 revolution in the 2000s…. in the end all this has happened or will happen, but in reality it will take at least 5 to 10 years. Not really a revolution.
Unless you can stop everything, stop working, and start again, forget the big bang. It will be necessary to do it incrementally. The Big Bang will be for when you start a new activity, create a new department. For the rest you will have to move forward step by step. Firmly but step by step. And, as has been said, it is precisely to improve a device little by little while running it.
Build trust, fast!
I have some bad news for you: your teams will have, at least at the beginning, nothing to do with your project. Then it’s up to you to earn their trust.
In fact, they have seen many transformation projects and almost none of them have gone through to completion. In addition, for good or bad reasons, they feel that it has never benefited them or even made things worse for them. So in order to get their support, you will have to prove your credibility and win their support.
The first way to do this is to show quick profits, the famous quick wins. You make an announcement and very quickly they take advantage of what’s being set up. It’s simply a matter of setting an example and proving it by example.
To be honest I have never been a fan of this approach but I have adopted it because it works. That’s all, you have to be pragmatic. It’s also a question of personality :
- I like to do things in order and with logic.
- I like to deal with substantive and “infrastructure” (human, technological, organizational) issues before building on them.
- Even though I know that everything changes over time and that new subjects/problems can only emerge over time I like to anticipate as much as possible.
- Sometimes it is necessary to deal with in-depth, invisible subjects before doing the visible things. But to make change a reality, sometimes you have to know how to tinker with visible things and make them work, even if you have to come back to them later to finish the job or make them better.
Others are more comfortable with the notion of “temporary do-it-yourself” (in the noble sense of the term) but as a believer in the principle of reality I quickly converted to it.
Visibility and pace please!
Another problem that arises with this type of background project that takes place in parallel with the “real work” is:
- That they can slow down or even be forgotten or put to sleep because there are always other subjects that can monopolize our attention and without the ability to distinguish between short and long term the tyranny of the short term will always prevail.
- That employees don’t like tunnel effects. Quick wins, sure, but if nothing happens afterwards it’s as if nothing had been done.
It is therefore necessary to give these projects visibility and pace. And I won’t go into more detail here, as this will be the subject of many posts to come.
Let’s just say, to give you a few pointers, that:
- Agility is not only for IT teams
- It is an ideal approach to bring substantive projects to life alongside the daily business.
- It allows you to focus on the value for the end user, for the company and nothing else.
- Based on the delivery of increments.
I won’t say any more, we’ll have the opportunity to go into details later.
Alone we go faster, together we go further!
If your teams live in a bubble you are lucky. Usually for all or part of their activities they will work with people from other teams.
- Because their functions mean that they share a subject and must collaborate.
- Because the input or output of their activity comes from or goes to another team.
- Because you need people from other departments to make a difference (starting with IT…)
Working only to improve the operational experience of your own teams without taking into account those with whom they work is a bit like changing your plumbing without connecting to the building’s supply/extraction: it doesn’t work and can even make the situation worse.
- Create side effects on others and only displace the problem
- Create workflow and information flow breaks between your teams and others
I see risks here only in terms of their impact on the organization and on the employee experience. There are of course some associated human impacts, the friction that this can generate in different teams, the resentment towards you…
It is therefore useful to integrate the people concerned (in any case the managers) in a permanent or punctual way in the governance of your project.
Another dimension of the “collective” subject: the design of the target employee experience. The more people involved, the more relevant solutions are found and the better they are adopted. But for the reasons mentioned above, don’t overestimate your employees’ ability to get involved. At least not all of them, not from the beginning, not all the time and not with the same level of involvement. It will be necessary to find the right articulation between the willingness to involve and the need to keep up the pace and move forward.
Knowing which fights to pick
As you have seen in the post I quote in the introduction to this one, improving the operational experience of employees is a human and operational subject that requires a certain technicality and above all to get your hands on more or less sensitive, complex (or even complicated) subjects and in areas where you are not legitimate and where you are not decision-makers.
So depending on whether you are just a “simple” manager who wants to change things at his or her own level, the director of a department or a member of EXCOM who is responsible for this transformation for the entire company, not all areas will be easy to access, and some will even remain off-limits to you.
It is useless to provoke an internal war and to go and fight battles lost in advance that will only weaken you, even if you are very confident and with deep convictions.
Because when you move the lines, there’s only one thing that limits what you can do: the ability of your management to protect you and take the hit for you.
The employees’ operational experience: a structuring transformation like any other
If you have experience with “structuring” transformation projects, this post has taught you absolutely nothing, just reminded you of what you already knew.
But if you thought that improving the employee experience was mainly about adding surface initiatives without touching the operational side of the job, you now know what you’re missing. If this doesn’t fit your profile, whether you’re a manager or, more importantly, the leader of an employee experience program, it’ s understandable that you wouldn’t risk it.But in this case, please leave your job to someone who has the convictions, the shoulders and the skills to do it, because in the meantime you are wasting everyone’s time and contributing nothing to the main dimension of the subject.
It remains to be seen how this translates in ” real life “. We’ll talk about it in a future post…