Fast-Paced Organizations tend to have imbricated or overlapping Knowledge generation and use workflows. The reason is simple: in fast-paced environments, where you need to extract value from the knowledge you are creating as soon as possible, you cannot wait until the knowledge is ‘fully prepared’ to use it. Or this would be too late. And, even more, in some cases there is no need/sense in waiting.

For this to happen, though, anyone in the organization MUST take part in the Knowledge creation and anyone CAN use these knowledge assets when they need it. This means using incomplete, not 100% true or tested knowledge. But is there such a thing as absolute true nowadays?

What do you mean by Overlapped Knowledge Generation and Use?

TL;DR Generation of Knowledge and the Use of this knowledge happen in parallel. Or maybe they are the same thing.

Libraries rock. But if you can put it in a book, it is not an Overlapped Knowledge Generation and Use scenario. If you can put it in a research article… in most of the cases neither it is.

What is not an Overlapping Knowledge Generation and Use scenario?

Let’s take the chemical industry. A big factory or a big array of factories, like a tire manufacturer. Knowledge, new rubber composites and, or, new combinations to create products in order to answer to given market niches or customer needs, are created by specifical teams. These teams are usually located in separate, even semi-secret facilities. When they finally give birth to a new product or compound, it is tested in vitro to check their features. Then it goes to a specialy focused factory or workshop where it is produced in small batches. These carefully traced batches are double-checked and tested in specific circuits mimicking diverse cases of use for those tires. (Curious? they look like this).

Finally, with tests results, the final decision can be taken and the product deployed. Mass production can start. This is when the operators that are going to produce the article, thousands of them eventually, take contact with the new product. Same about quality technicians, logistic agents or customer care teams. They had no contact with the new product until the decision was made.

I am deliberatelly making abstraction of all the parallel workflows: marketing, quality… but there are 2 facts here:

• There is a long trip from the idea to the final launch.
• And the on the ground teams does not take part in the process with their feedback or ideas until the product has been launched.

So Knowledge generation and Knowledge Use is sequential. Even happens in different teams. There are teams that exclusively generates knowledge and some other functional areas that are the users of this knowledge.

The palimpsest: where knowledge generation and use are overlapped.

What if the delivery cycle, the acceptable time to market were so tight that the product was given to the factories, quality testers, customer care agents before it is fully created/tested/finished? What if we tap into this scenario to get insights from this on the ground agents to improve the product from the moment of its inception?

Let’s imagine that any functional area shares a common language and they communicate! What if customer care agents -the ones who know the best what clients need and the way in which they use products- have a crucial role in suggesting new products. What if factory operators -the ones who know the best the production challenges- take part from the very beginning in product inception?

Instead of a book where knowledge is venerated and treasured, we would have something like a palimpsest. In a palimpsest, knowledge is kept fresh and useful, by being written by several hands to iteratively adapt it to context changes.

An overlapping Knowledge Generation and Use scenario example.

I’d mention my beloved Automattic, where customer care agents are part of the new features implementation process in several ways. They

• echo clients voices to suggest these new features or changes in preexistent functionalities.
• test these new features once they are implemented: discover bugs, suggest changes or improvements.
• report bugs/improvements, during the testing process or from customer reports, by troubleshooting, investigating, and creating detailed reports on GitHub (#). (This could occasionally mean to fix a bug / create a new feature by themselves or to be very specific about how to solve or create it).
• document these features. For instance, user-facing documentation ownership is shared so anyone can update these docs. And they effectively do.
• are continuously searching, generating, triaging, sharing and categorizing knowledge that helps in providing support to users or to improve the product. This includes new strategies in support, new features, events on the Internet with a potential impact on the support they are providing (from a local ISP service interruption to a change in a related service like Mailchimp or the way in which posts are shared on Facebook)
  

As a recap, Happiness Engineers (this is the name for customer care agents in WordPress.com) are not reading a book when they offer support. Overlapping Knowledge Generation and Use is a fact. They are collaboratively and continuously creating “that book” or, better “the big palimpsest”. They act as a living organization, a learning community, an autopoietic system who learns 24/7 with the shared aim of engineer happiness for users. This including the conventional idea of customer care -answering questions- but also anticipating these questions and even taking part in the new features proposal and implementation. If you are curious about what Happiness Engineers do, you can check it here. Ah! They also blog (about banana splits, Lego or working at Automattic / two / three)