Changing your organization is always at least a bit daunting. Even if you are genuinely excited about the improvements the change will make possible, executing a reorganization is complicated and taxing. Due to that, many executives waffle for too long, fearing to make a step forward.
The common fallacy here is that we try and find the “perfect” solution. In the quest to find this mythical solution, many hours are spent rehashing issues, anticipating how everything will turn out, and tweaking your approach. That’s letting perfectionism stop you from achieving actual results.
You’re trying to change your organization using a Waterfall-like approach. You try and do a big “design” upfront in order to cover everything possible, hoping that you could then go into implementation without changing anything along the way. I’m sorry to break it to you. That’s just as hopeless as doing Waterfall itself.
Just-Enough Worrying
Rather than trying to tie every loose end and come up with a fairytale equivalent of a reorganization, accept that you’re trying to come up with something good enough to start with. By all means, consider the likely problems and make sure that you do your homework when it comes to risk management. But then, move on and stop tinkering.
Like with product development, you should embrace the fact that you will be iterating on this as an advantage. Find a plan that covers 80% of the problem-space and get on with it.
Accept Iterations
When you go to introduce your reorg, it is crucial that you avoid a common mistake we all tend to do: introducing this plan like Moses coming down with the tablets in his hands. You are introducing a plan that will be changed and tweaked along the way—make that clear and known. This simple expectation setting can help everyone immensely.
Hand in hand with this introduction of iterations should come a demand for a rapid Speed of Change: implementing changes should not be something that takes months on end. Aim for an iteration that’s as quick as possible. Then, observe, learn from your mistakes, and commence in another iteration for improvements.
Treating reorgs like this removes the onus of having to come up with a brilliant solution from you.
Short-Circuit Fear
The last part that you need to consider is the fact that ambiguity, when couples with change, can cause anxiety. That is why the first 80% (MVP-like) iteration of the reorg should cover most personnel-related changes. The rest of the iterations should be aimed more towards improving processes and similar.
Discuss the fact that your intention is to not rattle people too much after the first iteration. Solicit feedback to see what else they are worried about. It’s not going to be a walk in the park, but when the benefits of a reorg outweigh the issues, you should execute on it sooner rather than later.