Getting a better handle on knowledge stuff

Back when I was a Chief Knowledge Officer, I struggled with the problems of how to better tap the collective knowledge and experience of an organization filled with extraordinarily smart people. There were the technical problems of what to collect and how to organize it. There were the organizational change problems of how to persuade those same smart people that sharing their expertise my way was in their best interest.

I had an epiphany when I came to see knowledge management less as an organizational problem and more as a problem for individual knowledge workers. From that problem, the first task was to figure out how to get better at sharing knowledge with yourself. Which led me to the notion of observable work. Dave Winer’s thinking on narrating your work was an excellent entry point to that train of thought.

During that process, I sketched the following diagram as I collected my thoughts:

Scarcely rocket science but it was helpful to me. The next step was to think about what larger scale patterns or clusters might be discernible That led to this picture:

I thought it could be useful to revisit this and unpack it from the perspective of more experience and insights culled from other smart people. Let’s start with generating a new list of “Stuff” that seems to have something to do with knowledge:

You could continue to add to this list. Or, you could explore what subsets organized by discipline—mathematics, economics, programming—might reveal. I think the broad distinctions between notes, working papers, and deliverables remains useful I’ve been looking at those questions myself of late (notes, working papers, deliverables). My advice used to be to start with deliverables and work your way backwards. That grew out of years of consulting work focused on the needs of clients.

Lately, I’ve been wrestling with the problem of managing at scale either as an individual or as a larger group. Techniques and practices that work for a single project or a handful of clients/projects break down as both time passes and numbers grow. Organizations address these problems by dedicating resources to them. They create and enforce the rules that annoy individual knowledge workers who haven’t yet run into scale problems in their own work.

These kinds of problems often surface in data management settings. The simplest example that springs to mind is sorting a list of names and addresses. Someone setting up a spreadsheet to invite friends to a surprise birthday party might set up one column for name and another column for phone number. Simple enough. Someone who’s been burned before will start by splitting the name into separate columns for first name and last name.

The point is that the “obvious” solutions to knowledge work data management problems have lots of unanticipated flaws that don’t surface until you cross scale thresholds. It seems perfectly reasonable to file project deliverables away by client and project until you have a hundreds of clients and projects and none of that information helps you track down the regression analysis you did sometime last year for one of three clients but you can’t recall just which.

Zettelkasten advocates make a compelling argument that the classification schemes natural to a knowledge manager actively inhibit the creativity meant to be the defining characteristic of knowledge work (good tags and bad tags). There is more worthy thought and discussion about categories of notes and emerging structural layers of notes.

The conclusion that is slowly emerging for me is that part of being an effective knowledge worker is a need to design your own knowledge management environment and that this design needs to anticipate that your needs and understanding are a continually evolving driver of that design.