We continue exploring the seven deadly sins of knowledge management in this week’s post. I explained three of them to you last week. Here are four more.

In a massively distributed world of work, effective knowledge management is a superpower for your people. On this site, we’re already discussed many things you must do, to foster knowledge sharing. This post is the first, in a two part series about things you shouldn’t do.

If you want to grow as a professional or a leader, you must stop doing some work, to take up new work. In this post I explain the concept of “metawork”, why it should be explicit and how it can help you scale yourself.

With the right systems and the right people in community management and curation roles, you can brew the perfect storm of “organised serendipity”. I daresay, that this can often work better than the proverbial water cooler meeting.

In this post, we’ll discuss how you can enhance your knowledge ecosystem by building on your existing collaboration stack. I’ll also go over how to create the right team of people to govern, curate and nurture that platform.

The approach of creating stocks of well structured, organisational knowledge has its limitations. In this post, I argue that you should invest in solutions that create flows and streams of knowledge while stocks move to a supporting act.

Remote work would have renewed your organisation’s interest in knowledge management. Considering one can’t walk up to co-workers for a quick clarification, could we instead ask the system for an answer? In an asynchronous, remote-first culture, a solid knowledge strategy can be a productivity power up.

In this article and a few subsequent ones, I want to share my thoughts about creating a knowledge ecosystem that keeps pace with your people’s know-how.

As a team scales, the need for documentation increases in parallel with the cost of not doing it. Daunting as it may seem, a handbook-first approach has many advantages, and will give your team a way to self-govern and self-organise. In this post, I’ll walk you through some ideas about what to include in such a resource and how you can create and maintain it.

Distributed agile software development projects rely too much on synchronous communication. This not only leaves too little time for deep work, it also leads to burnout, less diverse teams and knowledge and information sharing practices that don’t scale.

Asynchronous work has the potential to transform distributed agile so it’s fun, sustainable, inclusive and scalable.