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:


10K Data Flow Diagram Log Speech
10Q Data Record (row) Lyric Spreadsheet
Abstract Database Manuscript Stanza
Acronym Database Query Map Statistic
Affinity Diagram Database Schema Mathematical model Statistical Model (Regression)
Agenda Dataset Melody Statistical Test
Annotated Bibliography Descriptive Statistic Message Story
Appointment Dialog map Mindmap Subroutine/Module
Bibliography Dictionary Musical Score Syllabus
Block diagram Directed Graph Network Diagram Synopsis
Blog Email Note Term Sheet
Blog post Encyclopedia Notebook Theory
Blueprint Equation Orchestration Threaded Discussion
Book Federated Wiki Outline Time Series Analysis
Book Series File Poem Timeline
Bookmark File Folder Phone Call TLA, ETLA
Bug Report Financial Schedule Phone Number Transcript
CAD Drawing Flowchart Photo Trip Report
Calendar Forecast Podcast Tuple
Card Catalog Formula Précis Tweet
Case study Gantt Chart Presentation Tweet Thread
Catalog Glossary Presentation Slide Url
Chat message Graph RACI Matrix Use Case
Chat log Group Calendar Reading List Voice Recording
Chord Progression Hyperlink Report/White Paper Video Clip
Citation Index Resume/CV Video/Movie
Code Infographic RSS/News Feed Webpage
Code Repository instant message Scene Website
Computer Program Interview Notes Schedule Wiki
Concept map Issue Script Work Breakdown Structure
Concordance Issue Inventory Search query Work Plan
Conference Call Journal Article Search results Working Draft
Consulting Report Journal Entry Simulation model Working Paper
Contact record Journal/Diary Sketch
CRUD Matrix

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.

Essay Scam Busters