Manging group knowledge – you aren’t doing it wrong because it can’t be done right

My group at work is supposed to grow fast and there is a real concern that we will fragment and knowledge will be lost. I argue below that this is inevitable and largely unavoidable. But, more to the point, it’s probably not worth avoiding. And when it is worth avoiding? Know that you will need to pay someone on an ongoing basis to fix it. Data does not self organize.
There are lots of different kinds of group knowledge, in this case, for a software group. Below I’m going to walk through the main categories and explain why nobody should really care in most (but not all) cases.
Individual Updates For many years now I’ve sent around weekly updates (you can now seem them publicly here). This has proved useful for keeping my management chain up to date and for informing people I work with what I’m up to. It would be kind of cool to have a fully automated system to manage this. I could just post updates and people who are interested could click one button to get them. This wouldn’t be hard to build but it doesn’t really exist (and no, this is most certainly not Facebook or Yammer) and I really don’t care. The thing is that it only takes a handful of different people sending you updates before your overwhelmed. This just isn’t the kind of thing that scales. So handling it in an ad-hoc manner is fine. For everything else we have blogs.
Communicating within a project team We have lots of small teams in our area who work on specific projects and folks need to share knowledge with each other. This is ’insider’ knowledge. Knowledge created by people in the group to be shared with other people in the group. This isn’t the sort of thing that will make much sense to folks outside the group. For that we just use Sharepoint. It actually works pretty well.
Awareness of what other project teams are doing The whole area of the company I’m in has lots of people working on lots of things and it can sometimes be useful to know what other people are doing. We do have an internal CRM system to manage customers and engagement but it’s so complicated it requires training to use. It might be nicer if we could actually have some standard write up on each project and some way to discover the ones that are relevant. This is doable but it requires real work. You pretty much must have someone who is working at least 5-10 hours a week going to each project, making sure they put up a small write up and coming up with some kind of standard taxonomy and making sure the right tags/categories are applied. I’m not completely sure if this is worth doing but if it is worth doing then you must hire someone whose job it is to keep it going.
Knowledge Sharing This is often the holy grail of groups. “Hey I know somebody already solved this problem, how did they do it?” Wouldn’t it be great if we could solve that? The answer is - we have! It’s called Stack Overflow. Go use it.
Managers communicating to their groups Just about every pointy hair I’ve ever had has had the same fantasy that if they could just write the correct kind of group status email then everyone in their huge sprawling mess of a group would be aligned. It won’t work. Really. All you will do is spend hours of your time (and the time of your reports) crafting so amazing mail nobody is going to read. Please stop. Please.
Email I’m calling this one out especially because it just keeps coming up. I’ve had multiple pointy hairs who had this fantasy that if we could just somehow archive emails we could maintain knowledge in the group. The funny thing is that I got to test this theory out. For the last year I’ve been working with nothing but open source software produced by groups whose emails are all public and archived. I can literally count on the fingers of one hand the number of times any of these archived emails were useful. What was useful was stack overflow. I believe the reason for this is because email is a messy organic beast that is used to build consensus and help solve very specific problems. It’s not really good at reporting what the consensus is or stating problems in generically useful ways. So in general you really don’t want to read anyone’s archived email unless you are a sociologist.
So my general recommendation is - don’t worry about it. Groups tend to form their own ways of communicating that meet their needs. But when that fails please understand that it can only be fixed by making it someone’s job (for which they will be rewarded) to manage those communications on an ongoing basis. Data does not self organize.

Leave a Reply

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