This is going to be another post that was inspired by sheer frustrationâ€¦
Itâ€™s one thing talking to someone about adopting a totally new platform and meeting with resistance â€“ I get it, itâ€™s not what theyâ€™re used to, itâ€™s new stuff, they donâ€™t know if it will work etc. etc.
However, recently Iâ€™m encountering an alarming percentage of existing users of technology that are not using a lot of the features available to them â€“ and I donâ€™t mean small things, Iâ€™m talking about the features that someone literally buys the equipment forâ€¦
I understand if weâ€™re talking about a feature you actually have to pay extra for, there may not be money in the budget for it. But this is not what this post is aboutâ€¦
Do you use the freely available or already paid for features? How do you know?
Consider this (I have more examples but weâ€™ll keep it simple): I have a handful of customers that use our equipment (NetApp) with VMware that steadfastly refuse to even consider:
- Thin Provisioning
- Rapid, thin VM cloning
Those 4 technologies are frequently the reasons someone buys NetApp in the first place for virtualized environments, since they can lead to:
- Vastly reduced storage footprint
- Faster performance
- Easier management
- Easier and faster backup and recovery
- Tremendous money savings
In my sample base, those customers absolutely would benefit from those technologies â€“ itâ€™s not a â€œmaybeâ€ or â€œyour mileage may varyâ€. I know how their data is laid out and what kind of data it is, and the difference will be staggering.
Iâ€™ve also had customers tell me â€œwhere are my promised efficiencies?â€ They get really irate, and when I tell them exactly what to do in order to get said efficiencies, they start backpedalling and telling me how they canâ€™t turn the features on during production hours. They then promise to turn some on during a maintenance window, then time goes by, they seem to forget about it and call me again, irate, complaining about the lack of features and efficiencies. And the cycle continues.
Is it an education problem? Lack of time?
Maybe itâ€™s just a matter of education, but when someone is presented with the facts, several use cases from other local and global customers (including huge household names everyone recognizes), customers with hundreds of PB of data, all of them using the technology and achieving in many cases more than a 3:1 reduction in storage footprint, and still ignores the advice, thereâ€™s something wrongâ€¦
The other excuse for â€œshelfwareâ€ (software you never use but you just leave on the shelf) is lack of time to implement the features. For complex software I can see time being an issue, but my example is about things that can be done with a few mouse clicks.
The not invented here syndrome
Thereâ€™s a term called â€œthe not invented here syndromeâ€. This is an affliction suffered by professionals in all kinds of fields, not just IT. Some symptomps include:
- Extreme resistance to any new ideas that were not developed within the company (frequently, by that person)
- Extreme resistance to any kind of change, no matter how benign, low-risk, low-cost and beneficial it might be
- Dismissing irrefutable proof
- Thinking that your problems are more challenging than everyone elseâ€™s
- The inability to recognize the real challenges facing their organization (â€œcanâ€™t see the forest for the treesâ€)
This is a perfectly normal human condition. We each have our world view, and some of us really donâ€™t like having that view challenged. The human mind will actually go to amazing lengths to ensure that the existing worldview stays unmodified. The examples are all around us â€“ people ignore what seems to be common sense all the time. History is full of horrific examples. I donâ€™t want to depress anyone, so here are some humorous examples:
"I don’t trust fire, it can burn you!"
"That wheel thing seems like the devil’s own work!"
"Nobody needs more than 640K RAM in their PC".
Some friendly adviceâ€¦
Back to the IT world. There are a few simple things you can do in order to make life a bit easier for all.
- Please read the documentation suggested by your engineer
- Then read it again and take notes and prepare questions
- Be open to new ideas â€“ â€œluddite technologistâ€ is a contradiction in terms
- Be flexible â€“ try new things on copies of data or less important data, thereâ€™s always a wayâ€¦
- Reach out to your engineer, donâ€™t always wait for them to reach out (our schedules are usually crazy)
- Think in terms of the business problems youâ€™re trying to solve, not in terms of technology (you may not know that what you have can already solve your problems)
- If your vendor reaches out to you, maybe itâ€™s not just to sell you more stuffâ€¦ maybe weâ€™re even trying to help out. Imagine that!
- Never assume anything (including that you always know better than the vendor, or that everyoneâ€™s lying to you, especially if you already own their gear!)
- If presented with irrefutable proof of something, consider graciously conceding
- Be aware of your shortcomings and prejudices (we all have them)
- Accept you donâ€™t know it all (guess what â€“ the customer is not always right!)
- And, last but not least: put the business first, and your ego a distant last.
Iâ€™ll get off my soapbox now.