Knowledge sharing in IT

Hopefully most of you know what Ted Talks are?     A truly marvelous collection of inspiring videos, usually 20 minutes or less that are nearly always worth watching.

I recently watched this one from Stanley McChrystal, former US Army General who gave me a unique view on information sharing. General McChrystal says something at one point that strikes me as phenomenally appropriate to IT (even though he was talking about military secrets).  He says:

“… as we passed that information around, suddenly you find that information is only of value if you give it to people who have the ability to do something with it. The fact that I know something has zero value if I’m not the person who can actually make something better because of it.”


So how does this apply to IT?

I have worked with support personnel who kept all of their secret commands in notepads that they kept concealed in their back pockets.  Luckily in many cases the UNIX history command let me learn all their secret incantations as soon as they were out of the room. I did work with one guy in remote support who would create a file with VI, populate it with his commands of power, make it executable and run it.   He left nothing in the UNIX history but VI, chmod 755 and the name of his secret file.   He was simultaneously a smart guy and a smart alec.


I have learnt that the motivation to keep commands secret often does not spring out of any misguided belief that they are keeping dangerous commands away from inexperienced people.  They are simply trying to make themselves indispensable.   Sadly in the meantime everyone else is left to reinvent the wheel, or wait for the right person to come online, plus relearn things that others already knew and repeat mistakes that others have already made.

This leads me to knowledge sharing.

There are three forms of knowledge sharing in the IT industry:

  1. Knowledge that vendors share with users
  2. Knowledge that users share with users
  3. Knowledge that users share with vendors

Now you may think that vendors sharing data with users is obvious, but three things stand in your way:

  • Portal walls.   Vendors who guard their knowledge bases with portal walls are protecting their intellectual property from free loaders and their inquisitive competition, while simultaneously forcing everyone to rely on their willingness to actually share and denying us googleability.
  • Poor sharing practices, such as readme documents that are vague or incomplete (or even non-existent).
  • Fear of other vendors marketing departments.  This fear drives IT companies to not share information, not out of fear of what their users will say, but out of fear of what their competitors will use that information for.

The good news is that each and every one of us has information we can share with each other.   Whether we do this in blogs, social media platforms (like forums or twitter) or just in hand written notes stuck up on the notice board.  It is in everybody’s hands to share what they know.  Find a forum, start a blog, send out emails.   Just do it.

And if your IT vendors are worth their salt, they will listen in.

And always remember:

…the fact that I know something has zero value if I’m not the person who can actually make something better because of it.




About Anthony Vandewerdt

I am an IT Professional who lives and works in Melbourne Australia. This blog is totally my own work. It does not represent the views of any corporation. Constructive and useful comments are very very welcome.
This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to Knowledge sharing in IT

  1. Assaf says:

    Anthony, well said.
    Lack of Information sharing slows you down… people with knowledge should be interested in leveraging the company empolyees skills and spend less time in redoing things they only know…

  2. Dean Allen says:

    I do agree, Anthony. But I think it depends on your relationship with the “customer”. When I worked in professional services for a big vendor, mainly working on Netbackup engagements, I could usually wow them on the first day by doubling their throughput to tape, just by tuning the buffer size NBU used to match the 256KB blocksize the new (at the time) LTO-1 or -2 tape drives were using. NBU still defaulted to the DLT-happy 32KB blocksize (and still does!). But I was always told not to tell the customer I doubled their tape throughput just by creating a simple text file, for two reasons. 1. It would undervalue the service the customer was paying for, and 2. It might make the customer’s own techos appear inadequate or ignorant.

    I disagree with 1. – if I were a customer and paid a consultant who was able to double my throughput in one day, I really wouldn’t care how he/she did it.

    But I agree with 2. You don’t want to step on anyone’s toes as a vendor tech consultant.

    But when I’ve been working in something other than a paid PS role, ie – working FOR the user of the service, I’m more than happy to share that particular easy-win with any of my co-techos, which I have done many times with this particular “fix”.

    (If anyone is wondering, Google SIZE_DATA_BUFFERS :)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s