Knowledge Management

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.

Avoid High Modernist Design in your Knowledge Base
Photo illustration by Cortex Futura. Original via (lorem ipsum)

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...

Image of a 'standard tree' planted in soldierly straight rows
Not a forest, but actually a plantation

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.

Image of a forest flattened by a storm
A flattened forest

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.

Screenshot of a text espousing the myriad uses of an elm tree: Elm is a timber of most singular use, especially whereby it may be continually dry, or wet, in extremes; therefore proper for water works, mills, the ladles and soles of the wheel, pumps, aqueducts, ship planks below the water line, . .. also for wheelwrights, handles for the single handsaw, rails and gates. Elm is not so apt to rive [split] ... and is used for chopping blocks, blocks for the hat maker, trunks and boxes to be covered with leather, coffins and dressers and shovelboard tables of great length; also for the carver and those curious workers of fruitage, foliage, shields, statues and most of the ornaments appertaining to the orders of architecture. ... And finally . .. the use of the very leaves of this tree, especially the female, is not to be despised, ... for they will prove of great relief to cattle in the winter and scorching summers when hay and fodder is dear. . .. The green leaf of the elms contused heals a green wound or cut, and boiled with the bark, consolidates bone fractures.
The myriad uses of an elm tree

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

Join My Tana Tips Newsletter

To be the first to know about new Tana features, tutorials, and other material I publish, join the 3000+ smart folks in my Tana Tips newsletter.

We care about your data in our privacy policy.