You Scared Bro!?!?!

Have you ever found yourself in a situation where you wanted to make big changes in your life but those changes were so big that it ended up taking a lot longer than you originally planned to put those changes into effect?  You planned, replanned, scrapped those plans and laid it all out again and then once you pulled the trigger you still ran into speed bumps and roadblocks along the way but still overcame them.  Once you’re done you look back and realize that your plans helped guide you through the known but the unknown always seems to be the factor that has the most impact.  How often do you make that change and then think to yourself, “I should have done this a lot sooner!”

As an IT organization or a business you can fall victim to the same kind of hyper-cautious fears.  In this case, however, it is most often because there has been some kind of fallout or repercussion due to changes not going as expected in the past.  In business we all too often consider “outages”, however short they may be failures or surround them with talk of incompetence or mistakes.  In my experience incompetence is much, much more often the exception rather than the rule.

Businesses evolve over time.  Along with that evolution your people, processes and technology evolve along with it.  Most often that evolutionary process happens so rapidly (by necessity) that technology and the processes themselves become so intertwined and have so many connecting points that it becomes hard to know what impacts a change can have.  I call this the “Spaghetti Effect”.  Eventually, when left to its own evolution, time, and the desire to create solutions and resolve problems quickly technology and processes become a tangled mess of “spaghetti” that becomes more and more difficult to unwind.

So, this leads us back to the original premise of this post.  Eventually we need to make big changes in the environment to become more “agile” and make changes but the “Spaghetti Effect” is crippling our ability to do so, therefor we need to unwind it all and start making changes.  Although, now we are in a situation where we’re afraid to touch it because something might break.  We know what most of those break points might be and plan for everything we can but know something, either a vendor, an integration, or an unknown dependency that an employee long since gone from the organization put in place years ago will rear it’s head and bite us.  This leads us to spend an enormous amount of time digging and planning and delaying avoiding the pain.  Yet somehow the pain still comes along when you go to implement and after it’s done you eventually think to yourself, that was a little painful but we got through it and it wasn’t nearly as bad as I thought.

Your organization hires smart, motivated people, right?  If this is true then blame shouldn’t be the default response to issues for any department.    Blame induces the fear factor which tends to delay progress and provoke more NO responses when you ask for changes and input on new ideas.  If you want to keep up with the competition and make things happen quickly I find that brainstorming and a “Get it done” philosophy works much better.  Take account of all the things you know, talk to people, not just those people immediately involved with the change but people that you may suspect the change could impact.  If the answer is “I have no idea what you’re talking about” or “I never use that system” you’ve just produced an impact assessment for that user or department.  This will provide quicker answers to your data collection and start the informing process.  Once it’s done, no matter how rocky, you evaluate the learnings, you catch your breath and start with “Nice Work!” and then document the information and start getting ready for the next one.

In the beginning this process is slower as your team will still be shaking off old Pavlovian learnings but with encouragement and support they eventually start trading fear for confidence based on their learnings and move faster and faster.  Changes can become more frequent and somehow outages become minimized or if not minimized put to rest much more quickly than before.  All of this is not to say that appropriate safeguards should not be taken to minimize impacts and save your stress levels.  Pay attention to the data you have available and schedule changes when they are least impactful to the organization.  If that means you need to start a change at midnight or 3AM when the user load is at its lowest, sorry, you’re taking a nap and spending a late night with some friends from work, it’s just the smart thing to do.  In your planning performing test runs is always appropriate whenever possible to learn ahead of time whatever you can.

Changes in an organization, just like life can be scary but getting yourself and your people to a mindset of constant change and adaptation leads to innovative people who are willing to take calculated risks and move your organization forward and accelerate the rate of change and progress.