The art of knowledge sharing

I've been recruited to help my daughter write a paper about Isotopes today. During our discussion about how the paper should or shouldn't be structured an idea bubbled through my mind regarding why some people do not share the knowledge they have - or perhaps just struggle to - while others insist on sharing it. As usual when you have a great idea at the wrong time, some sub-conscious thread of my brain kept on mulling on it, until it evolved into lots of analogies and anecdotal evidences that map directly to my life... So I thought I'd share it with you...

Why don't you share knowledge?

Here are some of the reasons I have used to avoid sharing knowledge:

1. The concept that my knowledge equates to my value to an organization
2. The concept that it takes me less time to do something than to teach it to others
3. The idea that - god forbid! - someone else will claim to have reached a given conclusion without giving me proper credit.

OK, number 3 can be a real reason to avoid sharing knowledge, but if you do work with someone that would do that to you, perhaps you should re-think the environment where you work in: join us.


The impact of not sharing knowledge is probably hidden in plain sight for all those individuals that have worked in the same organization for more than 5 years just to find themselves still working in the same position they were hired for, with a very high reputation for what they do, and unable to progress in their careers. Fact is, they made themselves extremely valued at their line of work, and they can work miracles - being in fact so high above everyone else that works with them, that they are looked upon as almost demi-gods. But nobody really likes to work with them, and everyone else knows that these persons will do their job better when left alone.


These are tell-tale signs of someone that for years accumulated knowledge and did not spread it throughout the organization - and now realizes that the reasons why nobody else can do his/her job is simply because he/she never took the time to explain how he/she does it. And therefore, nobody else can do it like he or she can, and therefore he/she must remain in his/her current position, because nobody else can do it.


Sounds familiar?


I am certainly oversimplifying many of the concepts involved in Knowledge Sharing, Knowledge Transfer and the much bigger discipline of Knowledge Management, but in my professional experience through life, knowledge sharing is rarely a result of using a given tool. Actually, I think the usage of a tool will only help if the knowledge sharing culture already exists.

Why do you share knowledge?
 
So, now that I have completely over-simplified why people will not share knowledge (knowing or unknowingly), here's some of the reasons why I think other people do share:

1. Recognition - to be known as a guru, you have to - well - be known. Sharing your knowledge about a given topic, especially when it is something very specialized, will help establishing you as a point of reference about this topic
2. Scalability of results - being able to reproduce the same quality of results while using different resources
3. Being able to move up in the organization

Reason #1 is usually the most visible reason, and also why some people criticize awards, like our MVP program - the fact that the person getting the award is only in it for himself. If that's the case, then I love it. Please go all be ambitious and parade your knowledge on Tridion so that I run out of my budget for MVPs. (I mean it).

Reason #2 is the reason that logic and/or your management will ask from you. Professional organizations produce consistent, high-quality results. If only you are able to produce that same result, then your organization has failed.

Reason #3 is not very apparent at first. Of course, you bask in the knowledge that you are the most successful executor of a given strategy, you positively glow when someone you just met mentions how your reputation precedes you, and you love the fact that people come out of their way to talk to you about something extremely technical. And then you go home, and realize you are doing exactly the same thing you did 5 years ago - except that you're even more arrogant about it now. And you're still being asked to do that same job, instead of being asked to create more people like you.


Impact on Professional Services

Professional Services organizations (excluding on purpose all the off-shore/body-shop organizations from this list) have learned a long time ago that their main asset is the most intangible of all: Knowledge. Working for the Professional Services branch of a Software company puts me often in a position where Knowledge Sharing is the _only_ way forward. My job is to assist you in unlocking the potential of the tool you bought, not to show you how good I am.

If you don't work for the Software Vendor you may be very interested in maintaining the knowledge within your own organization (rather than the client that hired you), but as the software vendor I want you to learn it. The least services you need from us in the future - while happy and supportive of the tool - the more successful I have been. And our team can focus on what it's usually best at: introducing new customers to the amazing flexibility of the tool they chose to buy.

Promoting Knowledge Sharing

So, with all these things in mind - which pretty much sums up what my brain went through in the discussion I had with my daughter - how do you make sure you're making yourself redundant?

If I knew the exact way to do this, I'd be a billionaire. So here's some things that I think will work.
Promote knowledge sharing by rewarding the attitude.
Remember reason #1 why people share knowledge? Promote it. Give the person a public recognition of their great job at knowledge sharing. It does not need to be monetary, and it certainly should not be a contest (no "employee of the month" please). Anything as simple as nod to that person (or group of persons) in the company's internal newsletter will do miracles to that person's willingness to share knowledge.
Give that person additional responsibilities within the realm of sharing knowledge.
Assign a junior resource to tag along with the person, not "to learn and become like you", but to "help you move on by taking care of the more mundane aspects of your job". If you read it attentively, you will see that both sentences carry the exact same result: someone will learn by tagging along, but the second sentence puts more emphasis on the benefit to the person with the highest knowledge, which may also make them more pre-disposed to assist in a mutually beneficial way.

If both conditions are in place, you will naturally progress in your organizations - sometimes without even noticing it.

If you don't do it, nobody will do it for you: start sharing knowledge now, or risk doing the same job forever.

Recursing through Group Members with the Core Service

Yesterday I had to write a simple method to get me a list of all users who are members of a given group, using the Core Service.

Obviously, this is one of those tasks you'll immediately classify as "simple" or "easy" or "low complexity". Which is probably true, if you happen to have done this before...

Only one added twist, the list should contain all users who are members of this group, including sub-groups (groups members of the same group).

In TOM.NET this is a trivial foreach(Trustee trustee in group.Members), but in CoreService-land (and WCF-land) we don't have the Object Model available, only the data model. So I had to twist my mind for a while to get this to work, but eventually got it working as follows.

public Dictionary<string, string> GetUserEmailsByName(GroupData group)
{
    Dictionary<string, string> result = new Dictionary<string, string>();
    GroupMembersFilterData groupMembersFilter = new GroupMembersFilterData();
    foreach (XmlNode groupMemberNode in _coreServiceClient.GetListXml(group.Id, groupMembersFilter))
    {
        TrusteeData trustee = (TrusteeData)_coreServiceClient.Read(groupMemberNode.Attributes["href", Constants.XlinkNamespace].Value, ReadOptions);
        if (trustee is UserData)
        {
            if (trustee.Description.Contains("@"))
            {
                string userDescription = trustee.Description;
                string userEmail = UserEmailRegex.Match(userDescription).ToString();
                userDescription = userDescription.Replace(userEmail, "").TrimEnd();
                userEmail = userEmail.Replace("(", "").Replace(")", "");
                if (!result.ContainsKey(userDescription))
                    result.Add(userDescription, userEmail);
            }
        }
        else if (trustee is GroupData)
        {
            Dictionary<string, string> subMembers = GetUserEmailsByName((GroupData)trustee);
            foreach (string key in subMembers.Keys)
            {
                if (!result.ContainsKey(key))
                    result.Add(key, subMembers[key]);
            }
        }
    }
    return result;
}

The hard part to figure out was how to get the list of "Members" for this group, since GroupData does not expose that information:

_coreServiceClient.GetListXml(group.Id, groupMembersFilter)

Adding one more to the bag of CoreService patterns...