Avoid High Modernist Design in your Knowledge Base

Avoid High Modernist Design in your Knowledge Base. Whether you're using Tana, Notion, or any other tool to manage knowledge and collaborate – that's the one thing you want to avoid.

What is "High Modernism"? It's a term from James Scott's fantastic book "Seeing Like A State" and describes, slightly condensing, "uncritical optimism about comprehensive planning." It's been applied to everything from forestry to city planning – and you should avoid it.

So what does it have to do with team knowledge bases? When we decide to create a system to document things, to build a wiki, to collaborate, it's very easy to start by designing such a system from scratch. Tabula rasa, out with the old, in with the new. Don't do that.

The reason why you don't want to start from a totally blank state is this: You'll ignore "local knowledge" – and open the door to unintended, negative effects of your re-design. Take the example of "scientific forestry", developed in the 18th century: Scientific forestry was a concept developed in Prussia that later spread to France, the US, the UK and throughout the British Empire. It's goal was simple: maximize the constant output of timber from forests. And it worked! For a while...

To maximize the constant output of timber, a new measurement was created: the "standard tree" or "Normalbaum". This "standard tree" had a certain height, developed at a certain speed, and was planted in soldierly straight rows. Same type of tree, straight lines, no underbrush...

And the first crop was fantastic! Huge yields, much profit, oh wow! But the second yield...sucked, to be frank. And it didn't get better. Why? Because mono-crop trees planted in straight lines without underbrush destroys the eco-system of the forrest. Soil doesn't build up, beneficial species lose their habitat, pests for that one type of tree can munch on a whole forest at once, and storms devastate whole areas instead of felling individual trees.

What does this have to do with knowledge management again? Destroying the eco-system of the forest, replacing it with a tree plantation, effectively, also destroyed "local knowledge" of forests. There are myriad of uses of the elm tree – but if all you plant is Norway spruce, all that knowledge dies.

Let's apply this to team knowledge: If you design your knowledge base "from the top down", without tightly coupling it with the local knowledge of the teams working with it – it will break eventually. And "break" here can simply mean "no-one uses it" – because a knowledge base that gets ignored is useless.

Concretely: If I say "all SOPs for all departments go into this folder because it makes finding them easier" but there are SOPs with details not everyone in the company is supposed to see... I've ignored the "local knowledge" of that split and designed a system doomed to fail.

Now this is not meant to say that you shouldn't consciously design your systems, quite the contrary! Purposeful design is really important to building systems that deliver on what they are supposed to. The point is that a purely top-down, "rational" approach won't work.

What you want to do is set out with a simple goal for your knowledge base system and then do three things:

1. Let the system develop naturally for a bit
2. Then ask the people who are using the system where it's failing
3. Iterate on the system and do the loop again

And this, of course, applies to any app you might be using: Tana, Notion, Logseq, whatever. Start with a simple design, take in the "local knowledge" of the people using the system, and iterate – avoid the high modernist, top-down-only approach.

Related Topics