Network engineers love and loathe vendors. Vendors provide us with the shiny technical gear and fabulous nerd knobs that feed our need to tinker with new technologies. They also drive us to the brink of madness with their quirks, and for some of us, that’s a pretty short trip.
Here is a list of what I find to be the most annoying networking vendor bad habits, or as I like to call it, the top reasons I want to send vendors packing. Vendors, I hope you are reading this.
1. The Options Overload. As engineers, we like to have options. We could design 20 different solutions to a single problem without breaking a sweat. However, when a vendor's ordering guide needs an ordering guide to make sense of it, you’ve reached our breaking point.
If I cannot make sense of the part numbers I am ordering or even be sure I’ve got all the part numbers I need, my confidence in the product is immediately shaken. There’s little worse for network engineers than finding out we've missed something critical during a deployment due to this kind of complexity. I guarantee it is a top source of resentment toward vendors.
The ordering process should be logical and licensing structures shouldn’t require a Ph.D. to comprehend. In IT, we deal with enough complexity on a daily basis; removing this type of convoluted hassle would be a fantastic way for vendors to earn customer loyalty, and save some poor engineer’s nerves in the process.
2. The Old “Fixed in Next Release” Trick. As a customer, I grow weary of being the QA department for vendors. No, I don’t want to test your code for you; I want you, the vendor, to test your code, and do so thoroughly. Granted, bugs happen. We in IT know and understand that technology is not perfect. However, unpredictable hardware and software behavior costs us engineers severely in time and energy, and that definitely takes a toll on our goodwill towards vendors.
[Get advice on what not to do during an interview in "Why I Won't Hire You: 3 Interview Mistakes Network Engineers Make."]
Finding out that we need to update code to fix to fix an issue, but being fearful to upgrade due to potential new issues is a vicious cycle, and one we engineers are sadly all too familiar with. Vendors: We do not appreciate this Catch-22 you put us in. Give us confidence with quality code and we’ll return time and time again.
3. The Documentation Disaster Zone. A vendor may be selling the most fantastic piece of gear or software the engineering world has ever seen, but if I can’t find or make sense of the documentation to configure it, rest assured I’m not thinking kind thoughts about it or the company that sold it to me. I shouldn’t need to hire a Sherpa to navigate a vendor's website and I shouldn’t need to be an expert in hieroglyphics to decipher the instruction manuals I do find.
Inaccurate documentation provides an even greater source of frustration. I resent not only the fact that someone wasted their time creating what is clearly wrong, but now wastes my time as I attempt to salvage what little information I can.
Vendors, we engineers want to love you. We want to convince our managers that your latest and greatest technology would be perfect for our new data center or campus deployments or that your new software would revolutionize how our business is done. Help us help you by keeping us sane and avoiding these bad habits. You will be generously rewarded with repeat business and endorsements to fellow geeks. How could you pass that up?Amy Arnold, CCNP/DP/Voice, currently works as an engineer in the public sector with a focus on all things networking. You can follow her on Twitter at @amyengineer View Full Bio