Start with small processes and grow them
Too often we try to solve things in one big swoop. The seldom results in a really good process and more often wastes a lot of time. Here are some ways to do it better.
There are a few reasons why we tend to over-complicate our processes.
We chase perfection. Perfect is an illusion that you will never meet. You can come close on a very narrow task: “this magnet is perfect for sticking to flat surfaces with high iron content”. But you will find the cases where it is not perfect: “this magnet will not stick to this highly irregular surface”. It is good to aim in the direction of perfect but folly to follow it to a fault.
While we are there we mind as well add X. This is a huge problem. We are there and building it, so why not design everything we could possibly need into it. This can rapidly grow out of hand, impacting both the design and execution of the process. Having too much specificity can also lead to inflexible processes that break easily.
Everyone wants to contribute and “add value”. If they are not making a suggestion then they feel like they are less capable. This is a huge problem with management. There is a need to show their employees that they bring something to the table. These suggestions are implemented because the boss suggested it. In a team the same thing can happen… everyone wants to feel included by using their suggestions.
Fear of change. There is a peculiar concept that if your work is not getting something perfect the first time you are not good at your job. Not changing a system after its initial release is not because it is perfect, it is because people do not go about improving it. We need to focus on improvement cycles instead and not worry about the impression it makes. We need to start admiring improvement cycles.
There are many reasons it is worth starting small.
The pareto principle. In general, 80% of the benefit will come from 20% of the system. By keeping your new system small, you are more likely to have the key parts in place. Everything you add beyond that adds unneeded complexity.
You can start using the system sooner. One of the most valuable things businesses often ignore is early feedback. Quickly deploying a simple system allows you to learn how it will be used (spoiler alert: it’s often not how you intended). This an OODA loop that can inform what is working, what is not, and what is missing.
It is much easier to add something onto a process than remove something. People, in general, are loss adverse and at some level this affects decision making like this. Asking them to give up something they have is a harder ask that giving them something new. If a process has been around for a long time we may not be sure what is using a specific part. We can find out, but that makes the change harder. If we want to add something, we don’t have these concerns.
Three questions to constantly ask:
This part requires the participants to be candid with each other. If you cannot be candid these questions will not get you very far.
Are we positive this component is needed in the system? Don’t build for “just in case”.
Do we need it in the current iteration, or can it wait until later? So much of what we think is important can turn out not to be.
Does this component make sense in this process? Does it move us closer or farther from our intention for it?
This does not excuse you from thinking big.
You need to have a lighthouse in the distance to aim for. This helps you maintain the direction at each iteration, but letting you ask the question “does this change bring us closer to or father from our lighthouse?” At some point I will write about the Toyota Kata which is another one of my favorites.
