There are two key issues with organizational changes – starting and not quitting. Interestingly, not quitting is harder than starting.
It's difficult to start when significant changes are planned. This issue is easily resolved – you need to start small, in increments. For those in the know, this is called agile, and also fail fast, fail cheap. You take a step, evaluate it, either discard it or keep it, and then take the next step. For those with a more serious education, I'll say this is just the Deming cycle, not some trendy hipster invention.
But then the changes fade away. Enthusiasm wanes, new steps are not taken, and not even conceived. Gradually, even the changes that were made roll back, and everything returns to square one.
In my observations, 'quitting' almost always happens in the second month.
From my factory experience, I remember that the same thing happened there. The first month - hooray, everyone runs around, hustles, shows effectiveness, enthusiasm overflowing, 'now everything will be different!'.
But in the second month, there is almost always a failure. Indicators steadily decline back to previous levels. Enthusiasm fades, burnout occurs, everyone argues, curses, and collectively abandons the changes they started. Much to the joy of critics and observers. Naturally, the initiators of the changes will no longer engage in such nonsense afterwards.
This is indeed the curse of the second month. Because of it, changes stop. But the worst part is that participants in the changes refuse not only what they did in the first month, but also the very idea of any changes at all. To the extent that they join the ranks of critics and observers ('I couldn't do it, so you shouldn't try either').
In reality, there is no curse if you break it down. Let's try.
First – where did the month come from? It's quite simple – most companies have traditional monthly reporting. The goal of changes is set for the month ('this month we need to...'). This can be easily overcome – work by weeks (that's what we did at the factory), by decades (that's how one familiar factory operated), or use sprints of appropriate length.
The second aspect is the start of changes through action. In the first month, processes, systems, and tools have not yet been established. Everything is done hastily, using the simplest methods, with a 'hurry up' mentality, and so on. The result is quick but not systematic. A real transformation has not yet occurred; everyone has just tightened their belts and rushed to the finish line.
By the second month, the realization arises that running with tightened belts is inconvenient. There is a desire for systematization, order, clarity, and transparency. Furthermore, everyone wants it. The initiator of the changes is tired of running in circles, dealing with micromanagement, monitoring all tasks, and reacting to any deviations. People are exhausted from constant course changes, daily shifting rules, ongoing pressure, and prodding.
The third point is that some methods from the first month need to be discarded. Unfortunately, these are often methods that provided significant results. In the short term, they were effective, but they cannot be applied consistently.
All of this combines into the curse of the second month. There arises a choice: to keep running with a burden in tow, or to stop, think, and systematize activities. It’s not hard to guess which option people choose.
But then a new problem arises – it turns out that systematizing the experience of running with obstacles is not so simple. It is one thing to outline a process that delivers efficiency. It is quite another to actually be that process. This is often referred to as being immersed in operational management.
While you are running around and giving nudges, everything works. As soon as you go on vacation or sit down to rest, people stop working with the same dedication. Because there is no process, instructions, or methodology on how to act. There is only you with your nudges, persuasion, and help.
So what should be done? Accept the curse of the second month as an inevitable evil. Of course, try not to fail, or to fail not too severely.
But the main goal is to turn the experience of the first month into a system. The first month is intended for this — experiments, hypothesis testing, that very agile approach of failing fast and cheap. Its purpose is to quickly understand which methods work and which do not. Avoid spending too much time and money on automation, technical resources, or discussions. Create a snapshot of a functional process.
And in the second month, turn it into a system. Without worrying about a potential drop in results.
However, there is a second side to consider — the change requesters. You seem to understand that there will be a setback in the second month, and everything needs to be stabilized and set on track. Yet, the requesters are unaware of this and demand new growth.
Let them, the requesters, read this text. If they expect instant results and significant losses, they will continue to pressure you. If they want sustainable growth, they will give you time to systematize the changes.
However, don’t forget that the curse of the third month does not exist.
Source: habr.com
