Whether it’s in our personal relationships or technical careers, honesty and transparency go a long way. None of us are perfect, and even our best efforts can be undermined by an errant cut and paste, a cocked connector, or any number of soft or hard goof-ups. You know the routine- fix it quick, own up to it, and have a talk with yourself (even if the boss gives you a free pass) about what you’ll do different next time to not repeat the error.
Transparency and honesty show character and confidence- you’re big enough to admit your snafus, because they hopefully don’t happen often. But take it in the opposite direction and your credibility goes in the toilet. Show that lack of transparency or repeat the offense too often, and there may be no salvaging your good name. None of this is news, right? And what does this have to do with networking?
Consider this message that many Meraki customers recently received:
In this case, I lost a handful of floor plans that had APs placed on them from just a couple of my many sites, other people lost more. Meraki came out with guns a’ blazin’, and basically said “we screwed up”. I like the approach, and I also value that the cloud dashboard provides a natural conduit for the vendor to push information in front of the customer.
Then there’s this sort of thing, from Aruba, Cisco, and other vendors:
That one came in my email, and the proactive notice is appreciated as it saves me from having to go out and dig around. But… vendors can do more. Even in the absence of the ability to push notifications as with a cloud dashboard, they can leverage email culled from support contracts to warn of catastrophic bugs ahead of customers hitting them.
I’m not inviting vendors to spam us with every bug that any customer hits, as that does nobody any good and wouldn’t be practical. But I can remember a day when my environment was ground zero for discovering a fairly catastrophic bug that had profound implications for the stated capabilities of a given hardware platform. As best as I can tell, pretty much no other customers were made privy to the information, and I saw at least half a dozen cases over the next couple of years where the same limitation was hit (the product data sheet should have been updated to reflect the discovery- it was that bad and blatant). Customers talk and share information. This situation felt real, real sleazy from where I sat, and seemed a natural candidate for sharing with anyone who had that component on paid support. Instead, vendor credibility was bludgeoned.
I like these from Cisco, released quarterly (some Cisco-sensitive content removed from attached):
This is something all vendors should be doing. At the same time- there is so much bad code out there, customers deserve better communications on what really shouldn’t be used. It’s just confusing as hell when the “recommended” code is several versions behind others that are out in the wild available for download. I propose crystal clear warning labels on the download page, and calling the non-recommended code versions “beta”, as they often feel as such.
In closing, whether “honesty is the best policy” is applicable, or “sunlight is the best disinfectant” seems more appropriate, you get the point. Enterprise systems just cost too much and budget-minded IT teams are being tasked with doing ever more with less resources. We need that transparency thing from vendors, now more than ever. It keeps us from making mistakes that can be prevented if we only knew what the vendor already knows, and keeps the vendor’s credibility in good standing- and that is one thing you can’t put a price on.