It still amazes me to this day how IT organizations, even up to the CIO, seem to enjoy pain.  

Unlike the characters on Mad Men, my IT career was in the land where employees did not “mix business with pleasure”.  Perhaps that’s the reason for the pain.  Most of it is self-inflicted.  For me, the entire point of being in technology is “innovation”. It’s to automate processes and functions so that they no longer need to be handled manually, or at least to take the complication out of the process and make it easier. Our motto became “Work Smarter….Not Harder”

We read articles about agile development.  Then we read about how it can be quite misguided when used for ‘infrastructure’ projects, where stability and security are key. We read about how Dev/Ops is supposed to be the bridge to agility. We read how new technologies like containers, such as Docker and, Kubernetes, ease the deployment of applications.  How virtual cloud infrastructures make sizing and deploying applications a breeze. There are new tools like Chef, Puppet, and Ansible, all created to make technology easier and less painful to control and deploy.

Alas, timeframes on getting technology out the door in good order, stable, and secure, have not improved much. The quality doesn’t seem to improve either. Now I’m not speaking from the office of upper management (though that’s where I now sit). I’m speaking from being part of it, interacting with, and being privy to rollouts in major corporations. I’m speaking from the feedback I receive from the technology people on the front lines. I’m speaking from hearing the timelines of the ‘actual’ project implementations vs. what was forecasted before the project began.


It’s not the plan that makes a project successful, it’s the planning.


Though we have all this technology at our fingertips, it comes at us fast and furious. It comes at us from someplace where it worked, for various reasons, for someone, at some time. The Amazon Cloud for instance, comes from their own need to handle IT sizing and speed to market as a result of their growth. That doesn’t mean that it’s a match for EVERY company. It really depends on the business model, on the current infrastructure of hardware, OS, software, tooling; on whether there are legacy applications to consider, etc. A recent visit with a client revealed that they were ‘moving to AWS’.   I said, “but your applications all run on zOS and AIX.”  After a brief conversation of whether those applications would be ported internally to Linux as a first step and the realization that was never in the plan, the response was “well, we told our executives that, but it didn’t really seem to change their plan.”


Patient: Dr. It hurts when I do this.

Dr: Well then don’t do that.

Many times, pain can be traced back to communication:  I can’t believe they put that there!  Why didn’t they move the #^$% thing out of the way?   Why did someone leave that rake there for me to step on.  Why didn’t anyone tell me about the bridge being closed for repairs? Now I’m going to be late!

It’s much the same with IT. Smart people who do challenging tasks need to communicate with clarity (that means providing detail).  Corporations are reluctant to send people for training or industry tech shows these days; leaving everyone to learn these technologies on their own time and on their own dime. The operative word, ‘own’ = ‘lone’. Nothing against working from home, but getting a Skype text vs. the old fashioned face to face sit-down with TCM (tone, content, and movement) is not the same.

So, then where does a person learn best practices?  Where do they learn what to avoid? What shortcuts to take (a