Until recently, I did not like this phrase. It was used by people to do all sorts or random things, and it is a phrase that people could use to condone their misdemeanors. It is even more difficult for people like me to digest, who want a reason behind any change or decision.
However, as soon as you step into the IT world, or the world of any business, it starts making a lot of sense. Let me explain.
In the past, an industry had two ways of approaching change. They would seek change, and try to do something drastically different. Sometimes this resulted in miracles, but more often than not it would result in failure. As a result of this, they would shut themselves from experimenting completely, because there was too much to lose. Failure was costly. Then they would reach a point where they realised that they have been closed to change for too long, and would then want to change everything. The cycle would then repeat.
Recently, people started realising the value of controlled change through experiments. That, to me, is the only sustainable way of making change over long periods of time. One of the most popular texts on that topic is The Lean Startup. This way of doing things has become popular in the software industry recently, but it has existed for a while in all domains. In fact, this methodology of conducting experiments and adopting the right path by measuring results has been the basis of all modern science.
There are two ways of adopting this approach. Both approaches are listed below.
The first method. This should be used when you have a hunch that a new product, feature, process, or change would be useful, but are not sure:
- Think of what you want to achieve, and create a hypothesis on what approach could help you achieve it. So far, you can only make a guess on whether this approach will work or not. This is your experiment.
- If you feel the approach might have even a slight chance of success, try it out. You can do it in a small step, or with less resources, or try it on a small set of people or systems.
- Measure whether your experiment was successful or not. Build on it if successful, modify or revert if unsuccessful.
The second method. This is for scenarios when you have multiple ways of doing things, but are not sure which one is correct:
- List down the approaches that you want to try, and pick the top two that you feel have a chance of success.
- Try the two things on different people, systems, or times. If you have two ways of showing the dashboard, show one way to some users, and another way to another set.
- Have a way to track what works better. This could be qualitative or quantitative.
- Go with the one that gives better results.
I was a part of a team where change was difficult. People were scared of change. I realised that if 4 out of 5 people were okay with making a change, and the other 1 was quite vocal about not changing anything, the 1 usually won. The only way out was to make a small change, and see how people react. Often, the reaction would be okay if the change was wildly successful. If it failed or was partially successful, it got people flustered, and the change got reverted. This way, the change got reverted more than half the time, but there was still a higher chance of it going through.
In conclusion, it is easier to analyse than to predict. Design an experiment where change is fast, and easily measured. Mark it as success or failure, and move on.