Are You a Server Hugger? - Ownership Disease, How it Can Hurt You in IT?
Ownership has several important connotations and I use it to define my take on personal responsibility for pretty much every aspect of my life. However, it can also mean a "systems" approach to "owning" all aspects of a specific service, solution or function (I.e., I own the Data Center top to bottom). While both of the previous "ownership" definitions are positive, there is a "darker" aspect of owning (hugging) "things" in IT.
The audible symptoms of being Positive for Ownership Disease
I've been in IT for over 20 years now and I've seen all the symptoms as we move from one service strategy to another or make an effort to transform the technical architecture of a component of the infrastructure. Maybe some of you will recognize the following paraphrased quotes that are examples of the symptoms of ownership disease;
"We can't move to client server, there's no way it will ever be as rock solid as big iron"
"No, Mr. CFO, we shouldn't move to VoIP, it's not ready for production. Our current switch has been running without interruption for years, why take the risk?"
"Virtualization isn't production yet, when you really want to ensure performance you have to stay on hardware"
"If you want storage performance and dependability it has to be SAN, and it has to be from (three letter acronym here)"
"We can't use outside air for the data center. It's too dirty and it will increase the failure rate of our hardware"
In it's current form the disease is most often identified through the following phrase:
"We shouldn't adopt cloud, it's not secure"
The reality is that in any one of the above quotes there is just enough truth to scare the unaware executive into staying the course. What is generally not explained is lost opportunity vs. a realistic risk value. I'm sure most of us can quickly look at these examples and see the issues (I.e., how important was 100% uptime on the legacy phone switch vs. saving $2 million a year by going with a VoIP solution or even outsourcing it?). In reality if the CEO/CFO understood the real risk value vs. the savings or business benefit, they would likely have said make the change.
You can call the above quotes myths, FUD, or lies, but in most cases it really boils down to "ownership" and the fear that not being the owner of something (that I know better than anyone else) will put my job at risk. The truly unfortunate aspect of this fear of job loss or at a minimum status reduction, is often generated or perpetuated (mostly inadvertently) by leadership.
The visible effects of being Ownership Disease Positive
There a number of places you can look to find the visible symptoms of the disease, but the most obvious is the delayed adoption of solutions that can bring real change to your business and consequently to your IT team. While it's true that technology should never be adopted for the sake of "technology", it's also true that real opportunity for improvements in cost, management agility, and business execution can be lost when the disease strikes. Let's look at a couple current examples:
Virtualization - As a commonly utilized building block for efficient IT, and improved execution, virtualization is also the most often used tool for on-ramping to the cloud. Companies that failed to make real investment in a strategy for virtualizing their environments now find themselves behind the curve in the adoption of cloud computing.
Data Centers - Being the beating heart of the IT organization, it's strange that the data center is often overlooked as nothing more than an expensive room that we occasionally have to throw lots of money at. Lack of adoption of things like virtualization or outside air will now mean that you're stuck with a beast that is at max capacity with only one quarter of the actual space utilized. You're also stuck with an inflexible design that won't allow you to quickly take advantage of new business opportunity or to just as quickly scale back to avoid wasting cash during a difficult business climate.
Why am I Blaming The Leadership?
Who do you blame when your favorite team doesn't win the championship? You might blame the team owner, or maybe there's one player you really dislike, but in most cases it falls on the coach. So, if your IT team isn't dealing effectively with ownership disease, you have to look to leadership first. What can we do to reduce the risk? This is the tricky part, I know I don't have all the answers, but the following are a few of my recommended strategies to help protect your team from becoming infected.
Recognition and Job Comfort (or freedom from fear)
I'm a huge believer in appropriate recognition:
Example Role: In a high impact support function with lots of customer interaction, getting regular positive feedback (daily) is critical. I'm also a believer that you find the job for the person. If you find yourself perpetually having to explain customer service principles to the same person, you need to find what they are good at. If you spend too much time trying to change negative behavior, instead of reinforcing positive behavior you end up with nothing. Why expend 80% of your energy to get a 20% solution when if you focus on natural abilities the good stuff practically happens by accident and even weirder is the employee likes their job.
When recognizing someone be sure that the message you convey is the right one. If you find yourself saying "Gosh George, without you knowing the phone switch so well, I don't know what we'd do" then you're reinforcing the wrong things.
Recognize your teams for working themselves out of a job. One of my favorite leaders used to tell me all the time "if you work yourself out of a job, I'll find you a better one" and he meant it. This particular form of recognition is the riskiest for the manager, because if you don't plan to follow through (yes that means you have to actually work at future proofing your team) you will immediately lose the trust of your folks.
Be sure to recognize individuals in the manner that they not you are most comfortable with. Yes, I know its novel, but everyone is different.
You must recognize taking "smart" risk as a positive behavior. Talking about it once a quarter isn't enough, it has to be visible and real (promotions, new job options, mentions, etc).
If you do the above and maintain regular communication (not just monthly 1:1s) with your staff, you're likely to build a strong team who is willing to speak out about waste and inefficiency, even if they're talking about their own function. The hard part is that you'll know you're successful when your team tells you when you've screwed up. When your team no longer believes that their future is tied to knowing a specific vendor technology, or architectural strategy then the natural fear we all have of change will be dramatically reduced.
Now go out there and vaccinate your team. Or if you recognize some weakness in your leader(s), then point them to this blog. You'll know your disease free when you're the first one to say "we should consider reviewing alternatives" with full understanding that the alternatives could affect your role.