You spent a few weeks on it and it was agreed that orders would go into the software instead of the notebook. On day one everyone nodded, on day three someone said their hands were full and they would enter it later, and by the end of the week you found the team back at the same old notebook.
The software was not the problem. What never happened was getting the new method to settle into the team, and that job has a name: change management.
What does change management mean in a small team?
Go looking for change management and most of what you find is about organisational transformation, with examples drawn from companies of several hundred staff. That material was written for places where the message has to pass through several layers of management before it reaches the person actually doing the work.
In your team of five it is far simpler. Change management means bringing a new method into the team’s work in a way that they do not abandon after a few days. With systemization you build that method, and with change management you make it stick, and if you cannot do the second, the first stays on paper.
Why does a new method get dropped after a few days?
When a team abandons a new method they are usually neither lazy nor being difficult. Every time I have watched this happen up close, one of these four reasons was behind it.
- They do not know why. It is not clear to them what problem logging the order in the software actually solves, so they assume it is extra work you happened to want.
- Habit. The old method is settled for them and the new one is slower in the first few days, so without thinking they go back to the one they know.
- Fear. They think the new method exists so they can be watched more closely, or so the places where they have been cutting corners come to light.
- It really is extra work. Now they have to write the order in the notebook and enter it in the software, without anything being taken off their plate.
The first three are settled by one short conversation, but the fourth is yours to fix. As long as the old notebook is still there, nobody fully accepts the software.
The advantage a small team has and a large organisation does not
In a large company the message passes through several layers, and much of it is lost before it reaches the person doing the actual work. You, on the other hand, stand every day beside the same four or five people whose way of working is meant to change, and the moment one of them gets stuck you can sit down next to them and sort it out.
That closeness has another side to it, because in a small team the relationships are close and a new rule easily feels personal, as though you are picking on that particular person. The way around it is to attach the rule to a role rather than to someone’s name: instead of saying that from now on Ali checks the invoices, write that checking invoices belongs to the sales role, which is exactly what you do in a job description.
How do you make a change stick?
Making a change stick needs no complicated theory. It comes down to five simple things that we usually skip in a hurry.
- Say why first, then say how. If you only say that from tomorrow orders go into the software, the team has heard an instruction and nothing more. But if you say that orders were missed a few times and customers were unhappy and you want one place where no order gets lost, that same team has understood the reason and wants it too.
- Start small. Land one change completely and let the team see the result, then move to the next, because if you start several changes together none of them gets finished.
- Put one person in charge of following it up. If it is not clear who is chasing this change, after a week nobody asks about it.
- Follow it yourself before anyone else. If you set the rule and you are the first to skip it, the team learns the rule is not serious, because in a small team everyone watches what you do rather than what you say.
- Write the new method down. As long as it has only been said out loud and written nowhere, a week later each person does it differently. One page of documentation is enough for everyone to have the same version in front of them.
There is one more thing that usually gets overlooked. Any new method is slower than the old one in the first few days because the team is not used to it yet, and that slowness makes you think the method has failed and go back to the previous one, when all it needed was a week or two.
Where to start
Do not go changing several things at once. Instead, think back to the last change that never stuck, the checklist or the software or the rule that was dropped a few days later, and ask yourself which of those four reasons was behind it.
Then take that same change and try it again with a clear reason, one person responsible and a written version, and give it a week. If you find that everything you build gets dropped in the first week and you cannot work out why, in a free diagnostic session we look together at which change needs to land first.