No matter what your goal is, you’ve realized that you need your team to work differently. Now you need to figure out how to do it.
You have succeeded in identifying problems and even possible solutions, you have understood that it was better to co-create your plan with the people concerned than to go it alone and this in spite of the difficulties to engage people in such a process , at least at first.
Now you will come up against what puts off many people and makes them resign themselves fatalistically to the fact that things work badly
1°) There are a lot of subjects to deal with
2°) Once a subject is dealt with, another one arises
3°) When a subject is treated, it is never for long: it is necessary to improve or start again after a certain time.
Improvement is not a “one shot”.
An improvement project should never be a “one-shot”, something that is done, finished and then left in a state. This is a fact that comes from the industrial world, but it is even more true when we talk about human work, and even more so in the knowledge economy.
If we can consider that an industrial process can be “stable” for a certain period of time and that we can be satisfied with improving its components over time, a process involving information flows and their individual and collaborative treatment is almost never stable. Not only, of course, can it be improved over time, but it can also be constantly reconfigured under the influence of the case at hand, the resources and skills available, new technologies at hand, etc. The two are similar in spirit but the second one has an infinitely shorter “stable” life cycle.
Improving the work of a team is therefore :
1°) Improve processes in the broadest sense (formal, informal, rigid, flexible, at the individual and collective level…)
2°) Improve each part of them
3°) Continuously include new elements and remove obsolete ones.
Indeed, it is a process that, by definition, will never end. But that doesn’t mean that one can’t move forward on the subjects one by one.
This must be done in a context that has its constraints:
1°) The improvement process mobilizes resources in addition to their work. The “daily business” must not make us forget the thread of the improvement project and we must not tell ourselves that we will move forward “when we have time”. You have to change the wheel of the truck while it’s moving.
2°) You have to go fast. As I said above, the context is constantly evolving and taking 6 months to provide an answer to a problem that has disappeared or changed in the meantime is not a solution.
3°) You have to give visibility to the team. If we want to involve them and they believe in it, they must see that things are moving forward, that ideas are becoming reality, that deadlines are being met.
So many things that make many people prefer to put up with things that don’t work by telling themselves “I’ll never be able to change things anyway”.
This is a problem that I was confronted with and I have built over time an operating procedure in an empirical way. It does not pretend to be a silver bullet, but it does have the advantage of working.
1°) Sourcing ideas and problems and feeding the process.
At the very beginning, I had individual discussions with each member of my team but also with members of other teams with whom interactions were frequent, knowing that what we would do in one team would have an impact on the others and that solving the problems of one would also require mobilizing the others. My question was simple: “What is preventing you from doing your job as well as you could?
This was enough to “prime the pump” for many months.
Then we were able to improve the process with two things.
1°) An online form to report problems or ideas classified by themes: dysfunctions of tools and processes, improvements to the way we work, feedback on a failure or a major success from which we must learn so that it doesn’t happen again or to generalize a good practice, points of friction in daily life…
2°) A bi-monthly meeting that also serves to capture a number of topics.
2°) Give pace and visibility: treat the subjects in a “pseudo-agile” way
I say pseudo agile because the purists may reproach me for not going far enough in the spirit and for flouting certain rules. But my objective was not to do agile for agile’s sake, simply to find a system that works to give pace even if it means doing “quick and dirty” that we will improve over time.
The various data collected in this way end up in a “board” kept, depending on what you have on hand in your company and your preferences, in an application like Trello or JIRA.
We then divide the time into “sprints” of 15 days or a month (15 days for me) and in a very simple way, at the beginning of a sprint, “we” decide what we are going to process during the sprint, we move it from the “to do” column to the “in progress” column and when it is finished in the “finished” column.
The idea is to do only things that can be accomplished in 15 days, so sometimes that means breaking down some of the larger items into smaller ones.
The decision to deal with this or that problem can be made by the team manager or collectively, following formal or informal prioritization rules. As far as I am concerned, I started to feed and decide alone to prime the pump, the “collective” came only gradually over time.
At first I was responsible for 99% of the tasks, now I can start to distribute some of them.
Every 15 days, a meeting is held to review the various projects.
3°) A bi-monthly meeting to talk and inform
I am not a fan of meetingitis, far from it, and there are many other ways to inform and exchange with a team than holding regular meetings. However, it seemed to me that it was necessary for the purpose.
I therefore set up a one-hour meeting that takes place every two weeks. The members of my direct team are invited to attend on a “mandatory” basis and the managers of the teams with which our respective work “interferes” are invited on an optional basis.
The topic: “improving the way we work”. It’s out of the question to talk about current projects, clients, and each other’s performance. This is not a “business” meeting (there are enough of those as it is) but rather a “how we deliver” meeting.
Agenda:
- Follow-up of ongoing improvements
- Updates on various upcoming subjects or subjects that may concern them (a project that is starting at the company level on such and such a subject, a decision that is progressing on a subject that we had started and where we were waiting for choices to be made elsewhere, etc.).
- Return on the functioning of previous initiatives: we changed something 15 days ago, a month ago, is it working as expected, do we need to improve something, or even give up and go back because our idea was not so good…
- Intervention of “guest stars”. For example, bringing in the person in charge of RGPD and data so that they understand the importance of these subjects in their own operating methods, the financial department to share our points of view on the necessary reporting and to lighten/improve current practices…)
- Other questions.
Now that the thing is well set up I notice that :
- This is perhaps one of the meetings they most enjoy attending because it directly affects them on a daily basis and they are listened to.
- It allows departments that work a lot together but never talk about “how we work together” through silos to do so.
- Moreover, the two managers of other teams who are “optional” come every time. This makes it possible to talk about decisions made by one team that will have an effect on the others and to have allies rather than opponents when you announce that a process that concerns several businesses needs to be overhauled and that you are going to take care of it.
- Discussions on the various topics lead to exchanges that bring out others. But, above all, they allow you to create consensus… as long as you let people talk and get to the bottom of their ideas without interrupting them. Sometimes some people had very specific ideas of what they would have liked but ended up realizing that satisfying them 100% would create problems for others and therefore it was better to put some water in their wine.
In short, it was a moment of exchange and decision that was visibly appreciated and that allowed things to move forward. What I remember is the comment of a participant “it’s nice because it’s subjects that we never talk about, we are always told about our work but we are never consulted on how we do it and how to improve it”.
In other words, “we are responsible for the results of our work but we have no say in how we achieve them”.
A scalable process.
I describe here what a manager can do at his level on a perimeter where he has enough latitude of action. But this type of approach can be “nested” on several levels in order to coordinate things at the level of teams, departments and the company.
It is possible to imagine that some subjects “go up” because they require a decision at a higher level or that others go down to be adapted “locally”.
As far as I’m concerned, that’s what happened. This system of working by subject, by “ticket” is in place at the Executive Committee level for global improvement subjects and I wanted to bring this practice down to address subjects specific to my department. I don’t hide the fact that having a foot on each floor helps to coordinate…
Bottom line
For the moment, the device seems to me to keep its promises and fulfill its objectives.
Namely :
- To make the subject of the improvement of our practices exist and not only talk about it when our daily missions leave us the time…that is to say never or in a too disjointed way. On this point, the adoption of a “pseudo agile” approach was essential with an obligation to show things at regular intervals.
- Avoiding the tunnel effect, moving forward in small steps but moving forward.
- Show the teams that things are moving forward and give them pace.
- Make the manager accountable. When things stay in progress for too long, it is his fault.
- Involve the team.
- Break down the silos on issues that cannot be solved alone in one’s corner.
But one is never free of criticism and no system is ever perfect. Having exchanged on this subject with colleagues from other companies, I have heard two things.
The first is that setting up this process and running it takes too much time from the manager. Maybe, but in this case I wonder what the manager is for. Being focused only on results (which we want to improve constantly…) without questioning how we obtain them is not sustainable. Either you only put pressure on people and in the end it breaks, or you abdicate by saying that you will wait for the company to make the decision to impose change. In my opinion, this is an escape from responsibility.
The second is that, in the end, it is like asking managers or executives to “handle tickets” like a common customer service. So what? A manager or a director is not in an ivory tower. In fact, the more responsibility one has, the more one’s job is to fix what’s wrong. Generally speaking, what is going well in a company is the result of the work of the employees, and what is not going well is the responsibility of the manager, who must fix it and is responsible to his team. In a way, this is in line with the logic of employee service by extending the scope of the “continuous response” that Josh Bersin applied mainly to HR. But we will soon talk more broadly about what I call the “ticketizing of the enterprise”.
Image : continuous improvement de Photon photo via Shutterstock
