Providing feedback on Cisco UCS Documentation

So, who reads documentation? All the RTFM remarks aside, I would say that 3 in 10 of us read the product documentation that companies put out. My son got a new airsoft AK47 for Christmas – a direct import from China and I have to say that in that case, 0 in 10 can understand the documentation. Although I am taking caution to not “super extra charge” the battery. Anyway, I hope you’ll agree with me that Cisco pumps out some great stuff in the area of documentation (although only 30% of you can tell me so). And in the past 18 months we have built up quite a library on Cisco UCS. If you’re looking for the landing page for it, you can start here:

Now for the really cool part – YOU get a say in what we print (when will we stop using the term “print”?). That’s one thing that separates us from the “Big 3” server vendors in my opinion. Having worked at one of the Big 3, I had a small say in what we would print and sometimes would be asked to write it myself. But we never looked to the actual readers of the documentation to provide direct feedback to the author teams on what they were reading. If we did, we certainly never made it obvious or talked about it internally. Does Cisco make mistakes? Sure we do. Do we want to correct them? Absolutely. But the problem is that we don’t always catch the errors in technical review and you notice them when you’re reading. Sometimes you might feel you disagree with something we printed or that the way it actually works is different than what we said. I have a blog article completed and ready to go on a UCS topic, but my testing produces a different result than the docs so it’s on hold until we figure out who’s in error (don’t worry, it’s nothing critical). This is the kind of thing we need to know. If we build a great product and fall down on telling you how to use it, we have not really succeeded.

So how do you provide the feedback? We tell you in every guide we put out. It’s watermarked right into the opening pages as shown below:

Simply send an email to If you’re wondering who gets the email, it’s not being filtered by a computer or an outside firm. You are emailing the actual team that wrote the paper you’re reading. It helps if you can offer some guidance about what title and version you were reading, etc. Your comments will be reviewed and any changes needed will be incorporated. If you’re the guy in the picture above, I can only hope you signed a “pay per use” of your likeness. If so, you literally made a lot of money just sitting on your butt J

Lastly, this is no unique to UCS. Cisco provides similar feedback addresses in other product documentation as well.

Thanks for reading guys and girls.


5 thoughts on “Providing feedback on Cisco UCS Documentation

  1. Documentation is essential, especially when it comes to tech products. I mean, what would I do without programming languages specifications? ; ) Now, really, companies / developers / entrepreneurs should really be more careful about documentation standards for the sake of their own products – if I don’t understand exactly how to use it, I’ll just stop trying… great article!

  2. Pingback: UCS Chassis Discovery Policy | Jeff Said So

  3. Pingback: UCS Ports and Protocols | Jeff Said So

  4. Pingback: Appliance Ports and MTU Sizing with Cisco UCS | Jeff Said So

  5. Pingback: Appliance Ports in Cisco UCS | Jeff Said So

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.