Category: Knowledge Management

Personal knowledge management is a design problem not a selection task

PKM is a hot topic on the Interwebs. Everyone is peddling an answer; doubly so if you count the resurgence of evangelizing about the magic of notes. Everyone has the answer. No one is asking the right questions.

The questions I keep seeing run along these lines:

  • Which software product is best?
  • Is this the right way to build my Second Brain?
  • Who has the best training course/YouTube channel/e-book?

All of these questions are on a level of “Will this be on the test?” They are anchored in an unexamined assumption that there is a right answer.

Personal means personal.

All of the answers out there are answers that started out as the solution to someone’s personal take on the answer to the questions they had. At the very least you need to figure out whether those questions bear any resemblance to the questions you have.

You need to back up and formulate your knowledge management questions first before you have any hope of assessing the value of what is out there. The other day I suggested four questions that could get you started. Those questions put you on a design path, not a selection path.

This is not an easy perspective to shake free of. We are trained and acculturated to seek out “right answers.” Most of schooling is set up this way. Much of contemporary schooling was designed to prepare its products (students) to operate in a factory world of meeting production targets for standardized outputs. Only a tiny fraction of the workforce was expected and permitted to think for themselves.

We’re not quite sure what to do with the responsibility to understand our work and our unique contributions. And then comes the task of designing and implementing the practices that will let us carry out that work effectively. There is valuable advice out there to make use of. But the value lies in recognizing that what is out there is not the answer but input for the design work that you must do.

Knowledge is personal, manage it that way

Thirty years ago I was the Chief Knowledge Officer of Diamond Technology Partners, a consulting firm attempting to blend the perspectives of Accenture and McKinsey. Leveraging what we knew was the essence of the value we created for clients. With a total headcount at the start of 25 people, the title was more aspirational than practical.

Things got tougher as we grew to over 1,200 professionals over the next six years. The technology couldn’t do what we thought it needed to do. There were no playbooks for how to do knowledge management. Half of what we did had never been done before. We tried programs and practices with variable success.

One of the central challenges was persuading our consultants to share what they knew with one another. The consensus in the field at the time was that sharing was the problem to crack.

Pondering the question of what made knowledge sharing hard led to one of those shower moments where insight happens. Were our consultants hoarding their knowledge to preserve their rank and status? What incentives could we offer them to part with what they had learned for the benefit of the organization? Did we need to find more altruistic individuals who would share because it was the right thing to do? Could I be doing something to set a better example of what good knowledge sharing looked like? Had I done anything recently that was worth sharing more widely? What, in fact, had I learned recently that was of any interest or value?

I had found the culprit!

Knowledge sharing was failing because I wasn’t sharing knowledge with myself. Socrates had it right after all. Know thyself.

It’s hard to share what you don’t know that you know.

The starting point for effective knowledge management in organizations needs to be knowledge management at the personal level. If you are a knowledge worker, effective personal knowledge management matters regardless of whether your organization cares.

In the last several years, we’ve seen a surge of interest and attention to the problems of personal knowledge management. The technology environment has become more welcoming and robust. There are organizational barriers that continue to make this harder than necessary. Organizations still favor standardization and control in ways that clash with the needs of individual knowledge workers. This will resolve over time.

If you are an individual knowledge worker, you should be thinking in terms of your own PKM needs and environment. You may need to work around organizational limitations. Persevere. The improvements in your effectiveness will buy you degrees of freedom in enlightened organizations. If not, your organization may be less enlightened than you’d like.

Do You Need a Second Brain

There’s a lot to like about Tiago Forte’s Building a Second Brain if you are a knowledge worker of any sort. In today’s world that’s most of us. Like any ambitious work, it’s a mix of strengths and weaknesses. Understand the limitations and take advantage of the wealth of good ideas and advice.

The book grew out of Forte’s own efforts to cope with the flood of information that we all swim in. That led to a course/coaching practice to share his insights with others wrestling with similar challenges. Add a growing online platform and you end up with a book deal. As some wags have put it, Forte is trying to lay claim in the Personal Knowledge Management space to the position that David Allen grabbed in the personal productivity realm a few years back.

If you opt for the conventional publishing model, you’re bound by the current assumptions and expectations of that model. Yes, you can compress much of the value of the book into a handful of blog posts or articles. Yes, you will be expected to insert a collection of anecdotes about the famous or important people demonstrating elements of your system in their work. Blame that on Malcolm Gladwell. Forte is working within the constraints of the market that exists.

You have a different set of questions as a potential reader. Does this particular package suit your constraints for adding to your knowledge base? Perhaps you would do better seeking out those blog posts. Or, your time/value tradeoff makes a course environment a better choice. Having good ideas available in multiple formats and environments is a feature not a bug.

I’m not a particular fan of the Second Brain metaphor. Unfortunately, it’s hot right now and marketing momentum takes precedence over actual relevance. If it appeals to you, great. If it doesn’t, focus on the examples and general discussion of PKM issues and principles.

In point of fact, I first encountered Forte’s ideas in his online environment. I paid for access to his online writing. I chose not to invest in his online course. The cost of adding the book itself to my knowledge environment was trivial. The cost of my time and attention to work through the book (a couple of times) was significantly less than the value I’ve realized.

I’ve taken the time to walk through this tradeoff analysis because it makes a point about PKM; you are in control and it is your responsibility to be in control of your knowledge environment. I’ve been advocating for PKM since at least 2005 ([Why You Need a Personal Knowledge-Management Strategy). I might be envious that Forte is seeing traction for these ideas that I never dreamed of, but the universe is a better place for it.

The principal value of Building a Second Brain is as an extended case study/example of one successful strategy for establishing and working within a PKM environment. Forte is at this strongest when he shares and works through examples of how his system works for him. When he tries to meet the Malcolm Gladwell expectations, he has a tendency to reach a bit farther than he should. For example, at one point, Forte claims that

every change in how we use technology also requires a change in how we think. To properly take advantage of the power of a Second Brain, we need a new relationship to information, to technology, and even to ourselves.

I think you can safely ignore that claim and still get full value out of the book. I’ll close with the best advice that Forte offers

As your needs change, give yourself the freedom to discard or take on whichever parts serve you. This isn’t a “take it or leave it” ideology where you must accept all of it or none of it. If any part doesn’t make sense or doesn’t resonate with you, put it aside. Mix and match the tools and techniques you’ve learned in this book to suit your needs.

Personal knowledge management and body of work

Got an email from my old colleague, Chunka Mui, this week that read

Here’s an out of the past question — do either of your archives have a copy of that HBS case study that included the Andersen AI work on FSA and Eloise? I got a message from an old colleague looking for it.

It wasn’t an unreasonable request.

Surprisingly, I was able to track down a copy. How that played out, however, is worth reviewing for what it might reveal about personal knowledge management in the real world.

The case study is a piece of my body of work. I wrote it in 1986, early in my doctoral studies. It’s out of print as near as I can discover. A digital copy, if it still existed, would be in Microsoft Word 2.0 format, predating Windows.

I was pretty sure that I had kept a physical copy. But that was five addresses and two downsizings ago. It wasn’t in the one file cabinet that was on the third floor. Eventually, I did find a hard copy in a stack of articles and file folders up on a shelf in a closet in my office. All of my old case studies are in that pile. At some point, I pulled them together with every intention of scanning them.

So. Is this a win, loss, or draw for my personal knowledge management system? It’s a win for Chunka. He got his answer in less than a day.

I got him that answer in less than a day. But it doesn’t feel like a win to me. Is that an indictment of my system or of my assessment? What I feel should have taken a few minutes turned into an hour or more spread throughout the day. All dependent more on my memory than on anything systematic in my practices. Plenty of room for improvement.

 

PKM Isn’t About Apps

I characterized my most recent post (Putting Personal Knowledge Management in Context) as potentially a grumpy old man rant. The triggering event was a side-by-side software review, Obsidian vs. Roam: Which PKM App is Right For You? – The Sweet Setup. My instant reaction was “PKM isn’t about apps” and thinking that it was will get you in trouble. I thought it might be helpful to explore that reaction and see where it might lead.

The review itself is a very well done comparison between the two apps in question. But it is based on an implicit assumption that is also flawed. Because the assumption is implicit, people aren’t likely to catch it and wonder later why they become dissatisfied with whatever choice they make. There is a clue lurking in one of the opening paragraphs:

It’s impossible to say “just use this one” when it comes to picking the right connected note-taking app for you. On the surface they may seem similar, but there are several important differences that stem from fundamentally different approaches to how your notes are stored and managed.

The author is acknowledging that they cannot, in fact, answer the question they have set before us. They then proceed to explore the question anyway because it’s an easy question to ask and answer and because we are accustomed to expecting questions to have neat answers. Worse, we only ask questions that we expect have answers. 

I expect this bothers me, in part, because the underlying topic is knowledge management. The underlying motivation for knowledge management, whether in organizations or for individuals, is dealing with questions that don’t have obvious answers. Or questions that provoke deeper questions. 

Asking questions has always been a high-risk behavior. Where will we end up if we continue to explore the PKM space as a practice for asking questions that don’t yet have answers?

Putting Personal Knowledge Management in Context

The notion of Personal Knowledge Management (PKM) is experiencing something of a renaissance. This rebirth is being driven by a combination of new apps, new ideas, and new thinkers promoting their wares. The apps, ideas, and thinkers are all worth paying attention to. At the same time. the brightness of shiny new things is obscuring important history and context.

At the risk of sounding like a grumpy old man yelling at people to get off of his lawn, I thought it would be helpful to look at some of that context in the hopes that it might make it less likely that we would repeat old mistakes. We should at least strive to make interesting new mistakes. 

If you set aside the notion that knowledge management could arguably be considered a synonym for library science, what we label knowledge management in organizations today was born in the late 1980s/early 1990s in the efforts of a number of knowledge intensive organizations (HP, IBM, Accenture, McKinsey, Toyota, etc.) to systematically leverage the things inside their workers’ heads. Chief Knowledge Officers were appointed (a hat I once wore), taxonomies were defined, religious debates were held over the relative merits of Lotus Notes and Microsoft Sharepoint. Today, knowledge management is a reasonably well-defined function within most large organizations. 

Enterprise knowledge management was built on the premise that the number of knowledge workers whose knowledge mattered enough to manage was a small and easily identified subset of the workforce as a whole. Knowledge management was a hedge against having the knowledge in those smart heads walk out the door. 

The knowledge management problem changes when the proportion of the workforce classified as knowledge workers represents a significant fraction of the workforce. When everyone is a knowledge worker, knowledge management becomes personal not organizational.

A classic enterprise knowledge management problem is that of persuading the knowledgeable to share their knowledge with the rest of the enterprise. The naive hypothesis was that knowledge workers hoarded knowledge to preserve and protect their organizational status and position. A slightly less cynical take was that knowledge workers needed help to unpack and externalize their expertise so that it could be shared. 

My take is that the average knowledge worker has no clue about what it would mean to manage their knowledge and no useful models to emulate. You see individual executives and knowledge workers using email as their primary knowledge storage structure. You see arguments that enterprise search engines will bring Google inside the organization and prove sufficient to find and reuse knowledge assets when the time comes. You see elaborate folder and directory structures trying to impose order on proliferating documents and deliverables. 

The rise of personal computing and the web encouraged some knowledge workers to experiment with better ideas. Wikis, blogs, and bookmark managers were pressed into service. Ideas that were ahead of the technology curve (Memex, Augmentation, Dynabook, Mundaneum, and, recently, Zettelkasten) have been dusted off and revisited. 

The latest round of innovation and experimentation holds great promise. As an individual knowledge worker, you have several choices. One is to do nothing and wait for the dust to settle. A second is to place your bet on one of the current players and hope your support contributes to that player becoming the winner. 

A third strategy—and the one I am pursuing—is to recall an observation Peter Drucker once made about the productivity gains made during the early years of the 20th Century;

Whenever we have looked at any job – no matter how many thousands of years it has been performed – we have found that the traditional tools are wrong for the task.

Peter Drucker

Those extraordinary gains flowed from examining tools and task and rethinking the combination in parallel. Changing tools without changing the task is a recipe for speeding up the mess. Changing tasks without rethinking tools will make the current mess a morass.

Personal knowledge management has to be one component of a personal quest to become a more effective knowledge worker.

Taking Credit and Responsibility for Knowledge Work

I’ve been writing for more than half a century now. One of the early outlets for my writing was the school paper. Most of that was on assignment and there were no bylines on stories. There was, however, one op-ed piece I wrote that did carry a byline. From my cumulative wisdom of 17 years, I opined that our headmaster should come back into the classroom and teach. Scarcely a rabble rousing call to arms but my schoolmates were convinced that I would soon be summoned to Fr. Timothy’s inner sanctum and suitably chastised. That never happened, although we did have a passing chat on the sidelines of a soccer game weeks later where Fr. Timothy agreed with my analysis but suggested I might lack some necessary perspective. 

This was probably the first time that my words and name were publicly linked. I didn’t give it much thought until recently. I thought about deadlines and assignments, but little about formal credit. 

As a consultant, I’ve written tens of thousands of words for clients. While my participation and contributions to this work were never a secret, my name is nowhere on the final deliverables. The finished work is tied to the firm and its reputation, not to individual contributors. 

Eventually, I began to write things for myself and put them out into the world with my name attached. There’s this blog, case studies, periodic columns, articles, and two books (so far). 

I thought this was about getting credit for my work, and that’s an aspect. More importantly, it’s about taking responsibility. Few of us want to attach our names to substandard work. (There’s another story to be told about learning to calibrate your standards to avoid the opposite problem of seeking unattainable perfection).

There’s a missed opportunity here for organizations that depend on quality knowledge work. Steve Jobs understood this when he had the design team for the original Macintosh sign their names on the inside of the plastic case. We talk of knowledge work products as assets to be managed. Each of those assets should also come with a provenance. 

Learning to Forget

Back in the days when I was a full time consultant working inside a firm, I wore two hats; Chief Knowledge Officer and Chief Learning Officer. The accepted argument was that there was value in capturing and organizing what we knew as an organization so that we could teach it to our consultants and they could do better work for our clients. Knowledge was property—intellectual property—and was as asset to be managed. Good manufacturing firms managed their raw materials. Ideas were our raw materials and, therefore, worthy of active management.

Such a simple analogy. We thought we were more clever than most by tying the knowledge management and learning elements together.

We forgot about forgetting.

Our efforts were all about remembering. There was no attention to the need to make room for new and better ideas. We adopted a scholastic view of knowledge, not a scientific one.

Organizations can be haunted by obsolete ideas as they are held back by failing to remember what they already know. We neglected forgetting practices to go along with remembering ones.

This can be tricky business. Memory hooks are largely about stories; compelling stories make things memorable, even for abstract ideas. It’s hard to simply replace an old story with a new, shiny, story. It’s one of the things making organizational change so hard. The old stories are tightly knit into the fabric of the organization or discipline. The new story, however shiny, can’t compete against the weight of the entire tapestry.

We need to bury old ideas. Celebrate them if we must, but be careful about trying to dig them up when the result is more likely to be zombies than secret treasure.

Idea Management as an Abundance Problem

The best way to have a good idea is to have lots of ideas

 Linus Pauling

I suppose it’s fitting that I have struggled with this blog post far more than most. It began with a desire to improve the rhythm and cadence of completing and published writing deliverables. Having just passed nineteen years writing this blog, you would think I was beyond fits of teenage angst. Maybe the onset of blogging adulthood is more daunting than I realized. 

I’ve always liked the Pauling quote. Having lots of ideas has never been a particular problem for me, so I’ve trusted that some reasonable portion of them would be good enough to share. For a long time, I attributed my occasional struggles to focus on a particular train of thought on my ADD. Bright shiny objects always promise a dopamine hit, but I’ve felt like I’ve been able to keep it enough under control. 

It occurs to me, however, that my ADD simply serves as an early introduction into a world that we all now live in. We all swim in an overwhelming abundance of ideas. Our training and practice focuses on turning individual ideas into a desired deliverable, whether that is a blog post, a client presentation, or a spreadsheet analysis for our boss. 

While there’s much to be learned about that idea to deliverable evolution, there’s another layer of knowledge work practice that we must tackle. That thread of idea to deliverable is one element of a collection of threads and you have to manage the collection as something distinct from any one thread. 

Simply splitting the problem into two layers is a step forward for me. I have a reasonable handle on the first layer; I know how to take an idea,  develop it, extend it, and polish it into a deliverable. As a creative task, however, that process is rarely linear. Ideas are not widgets, you can’t simply plow ahead from idea to deliverable. You often need to set things aside and let them cook. 

Which is where the second layer comes into play. What do you pick up when you set the first idea aside? Presumably another idea that you set aside earlier or a new idea trying to seduce you. You now have a management problem as well as a creation problem. 

The management problem is about selecting ideas, monitoring progress, switching, sequencing, timing, and cadence. This is operating at a different level of abstraction from the creation process. 

At small scales, you can likely manage organically. There aren’t so many threads that you can’t keep most or all of the management issues in your head. With time and the accumulation of a body of work, it’s worthwhile to externalize the management problem and not try to rely on the limits of memory. At the same time, the management process must be subordinate to the creative process. 

Over the past eighteen months or so, I’ve been gradually retooling my baseline creative practices around a more disciplined note-centered practice. Like any retooling, this has led to a temporary drop in output. As committed to improvement as I may be, there’s still muscle memory to be overcome. Even bad habits are still habits that require extra energy to break down and replace. Some markers of this journey that have risen to things worth sharing include:

Early on, what management of the process I did was on the proverbial back of an envelope. Keep a list of ideas as they came to me and pick something off the list when I sat down to write the next piece. Look back at the last few blog posts and write a follow up piece. Do this for any length of time, however, and the envelope gets pretty full

My next thought was to take the list off the back of the envelope and formalize it. I dug into the approaches of other writers who’ve gone through this evolution. Among the appealing approaches I ran into were:

These approaches, however, don’t scale well. As your body of work grows, you risk spending more time maintaining the management control system than you do creating new work. That misses the point entirely. 

Some Zettelkasten advocates claim that the necessary tools and structure emerge as you gain more experience and grow your collection of notes:

This hasn’t played out for me. Setting aside the hypothesis that this simply reflects my personal limitations, what’s missing? 

This comes back to the distinction between creating and managing. Most of the discussion and advice I’ve been able to review is focused almost exclusively on creation. It either ignores managing the process as a whole or presumes that what needs to be managed is trivial relative to making creation work more smoothly and reliably. 

To manage the overall process you need to get above the details of individual work in process (WIP) items. You want to collect just enough data about each item to not have to read the entire piece while you are trying to manage a collection of multiple WIP items. And you need to track the status of each piece of WIP relative to its transition from WIP to final deliverable. Is this item a new idea? A draft? In need of editing? Ready to publish? Published? There’s a life cycle to be defined. This is the metadata you need to make informed decisions about the overall process. Do you have enough WIP to feed your deliverable goals? How does the mix of materials look?

This is a classic data management problem that would seem to call for a simple spreadsheet as DBMS solution. Or a multi-column outline of some sort. Both of those approaches failed relative to the goal of keeping the management system subordinate to the creative system. As I continue the transition to a note-centric creation system, the challenge is to embed the pertinent metadata in the individual notes and create some method of querying the metadata to generate the schedules and lists that will help me manage the creative process. Now that I’ve got a handle on the basic requirements for managing my WIP, the next step is to discover or create the reporting tool. 

Mine experience for design insight

What’s the value of experience in the rapidly changing world we inhabit?

This isn’t a new question. Mark Twain raised it over a century ago:

We should be careful to get out of an experience only the wisdom that is in it and stop there lest we be like the cat that sits down on a hot stove lid. She will never sit down on a hot stove lid again and that is well but also she will never sit down on a cold one anymore.

Experience matters when it offers insight into what action to take next. In a slower world, the insights can be treated as scripts to execute because we know that they work. We may not particularly care why they work if the world is stable enough.

Change makes old scripts obsolete. At one extreme we can adopt Mark Zuckerberg’s observation that “I want to stress the importance of being young and technical…young people are just smarter.” Ignore experience, move fast, break things, hope your IQ points manage to mesh with where the world is going. It’s difficult to argue with Zuckerberg’s success. On the other hand, Facebook is now constrained by its own history and experience. Experience remains a factor.

If change happens too fast for experience to be packaged into scripts, how do we then leverage experience? My hypothesis is that the answer lies in actively processing experience. I think this is part of the argument for knowledge management. However, knowledge management approaches in many organizations focus on accumulating and organizing experience without real processing. They are anchored in an assumption that simple access to experience will be sufficient.

The value of experience in a rapidly changing world is to reveal patterns that can be mined for principles that in turn feed the design of possible responses.