In previous posts, we’ve covered companies and their departments (which we’ll call “orgs”) and how they function like organisms. We’ve also covered vision, strategy, and tactics, which are the principles they use to arrange really big outcomes in the world.
But to get outcomes, we’re going to have to know how to do a lot of stuff! A really important thing about companies is what they know and how they manage all of that information. Often this is just as important or more than the actions they take.
Why This Matters
Most businesses (and even private lives) are now driven by knowledge, instead of production of tangible goods. The “Knowledge Economy” is not like a grocery store or a manufacturing plant. If you were to take the knowledge out of a consulting company, a software company, or even a therapeutic massage business, you would be left with nothing.
This makes the study of knowledge management important. How we manage what we know is tied to our effectiveness, and we’re unfortunately very bad at it. Let’s start by looking at what the problem is, and how we do it today.
So Much Knowledge…
In order to run something as simple as a grocery store, you have to know so many things. How to buy hundreds of different items from possibly dozens of suppliers. How to hire people, stock the shelves, take credit cards, and on and on. Most of this isn’t really interesting, but someone has to know it, otherwise your store doesn’t function.
Really quickly, you find it’s unreasonable for any one person to know it all. We’re only talking about a grocery store, which sells goods. An enterprise like Microsoft or Google is exponentially more complex, not just “more”.
If it’s impossible for any one person to know everything, then we have to “chop up” this knowledge and distribute it across a lot of people in order for the org to function.
Dividing and Partitioning
Most orgs have an “org chart” that show lines of authority. Most people think of these org charts in terms of who is the boss of who – but really they are equally “knowledge partitioning schemes”. In a pure information business like software, the company might have a product management group that decides what the software will be, an engineering group that builds it, and a sales group which sells it.
Who knows best how to describe the software to customers? That would be sales. Who knows best the limitations of the software today? Engineering. All of this is critical information to keep; so we see that each department is a partition of knowledge not just a set of decisions & authority.
All knowledge is kept, but all of it isn’t in any one place. Again almost no one thinks of the problem in these terms. Org charts are usually about power, authority, and decision-making. But the buckets we design for the authority game often also neatly describe “who knows what”.
If we define neat organizations, and they know things; notice that this creates an unavoidable issue of “seams between the sub-orgs” and potential overlaps. And it fundamentally puts knowledge in those areas in a gray space. In the case of a software company, communicating what the software will do in the future to customers is often a point of contention; in part because this knowledge doesn’t neatly fit in product management or sales alone.
Orgs pay general lip service to the need for sub-orgs A and B (like product management & sales) to “coordinate” but frequently that coordination is ad-hoc and unspecified. When that coordination is well understood, it is almost as if you’ve created yet another org (the org coordinates A and B). And in very complex situations, you may have solved one problem only to create more seams.
It’s a bad idea to put all of the facts about any one topic in one person’s head, because people get sick, they quit, and so on. Teams that have all of the knowledge in one person’s head are said to have a low bus factor. So there’s a tradeoff here: the more people who know some important information, the safer it is. But you can only be but so safe, remember we have too much for everyone to know, so it can’t get anywhere close to “everyone knows everything”. People need to let go and not know certain things, in order to function in their area.
Humanity is Very Bad At This
Looking at knowledge management in these terms, it’s easy to see how just about everything becomes a trade-off. We have to come up with a way for any org to partition knowledge, without too much redundancy, but with some – minimizing overlaps, but neatly organized.
Almost no one in modern business gives thought to these types of considerations though, and in knowledge businesses it shows in the form of many business dysfunctions whose root cause is in poor knowledge management. This takes many forms:
- Inability to learn from past mistakes
- Going to the market with the wrong product or service
- Inability to spot opportunities when, across organizations – the knowledge of the opportunity is actually there!
Tactical Hell: as discussed in the vision, strategy, and tactics post, most orgs are stuck in tactical hell where they have no strategy or vision for knowledge management, but are very busy doing things like content management systems, cross-training, and documentation. And if the overall org does not have a good vision & strategy, choosing an effective approach for knowledge management is close to impossible; if we were to think of a wise way to partition & manage information, surely it would have to be based on what we are trying to do!
Bring the Pain
The pain of this immaturity has been there for a long time. The two most common frames on “how to fix this” though we know are wrong:
Tally the Dollars: Articles which purport to put a specific dollar figure on what bad knowledge management costs often appear to speak to business reality, but really they’re silly; first because economic estimations always follow a “lick your finger and put it in the air” approach. And second because to estimate what bad management costs, you would have to know what good management looks like to have a basis for comparison – and we simply don’t. Finally — failing to recognize that orgs are like biological organisms with lots of complex drives, and not just profit maximization – makes this approach rather naive in the large.
Make Another Org: we could also make a C-level officer, and enable a “knowledge czar”. This is generally useless, because it changes nothing about the organization of the rest of the whole, and in our example above, serves to create new seams between the (now larger) set of sub-orgs. It further doesn’t identify a real problem, but an amorphous set of problems, and simply shoves responsibility for those to a new person, who often does not control the levers necessary to affect change.
A Different Frame
Thinking back to orgs as actual organisms might force us to confront what this organism actually wants, and how it needs to develop at this point in time. Maybe it is old and stuck in its ways, or it’s fast-growing and is in constant pain as a result of that. There is a “zeitgeist” to being in these orgs as much as there is a balance sheet, but almost no one ever looks at it.
Viewing orgs as stable loops of organic behavior, as we can readily see people and their personal challenges, is the better frame. In that linked article, we go through how to identify behavioral loops, their context and cues, and the lessons are equally valid for large orgs. The only difference is what those stable loops consist of.
Starting with concrete problems, instead of a desire to “fix knowledge management” is the first step. Examining the existing behavioral loops and what reinforces them is the second step. And then designing interventions to disrupt those loops and encourage better ones is how to get there. In a future article, we’ll take a particular large org as a case, and step through how we can do this in practical terms.