The ability to create knowledge together

I would like your opinion.

I have for the last few months been toying with these ideas.

To create a new product, the Team is all about knowledge creation. Not management of existing knowledge but creation of new knowledge.

Note: The picture to the right relates to Nonaka's ideas about knowledge creation, and tacit and explicit knowledge. Nonaka and Takeuchi are the godfathers of Scrum (per Jeff Sutherland).

So, in forming a Team, it is not about bringing together people who have existing knowledge, but about bringing together the right people to create knowledge.

My hypothesis is that, if we really believe that, then who we bring on the Team changes fairly substantially.

Now, we don't do this foolishly. There is Explicit and Tacit knowledge in several domains that is important. That takes years to develop. It is probably not wise to start a team with six really smart 18 year olds. But I do think our criteria have been much too skewed toward: "who has explicit knowledge" at the start of the project. Rather than "which group of people, together, would create the most knowledge, the most creative knowledge" over the course of the project.

There remains still some sort of magic in pulling together a great team.

So, how important is the knowledge creation part?
And how should it affect the Team members chosen?

Against Central Planning

In general, it seems simpler to have one central brain plan everything. And to assume that that brain has it right. And "everything will work out for the best in this best of all possible worlds" if the Central Planner plans it for us rationally. (Cf Candide.)

Suffice to say I do not buy this horse hockey stuff.

Complex adaptive systems rule. You add a few basic constraints and the "system" (with multiple decision units) figures out the rest in real time, and continually adjusts.

This is not to imply that CAS's are perfect. The world is a tough place. Stuff happens. Any given CAS can not always figure it out fast enough nor always adapt fast enough. But a decent CAS will whoop a very good Central Brain every time. Ok, over a reasonable span of time, like a year.

My hypothesis is that one of the key problems is that the world (even one domain of it) is so complex that one brain cannot envision the whole elephant at one time. (See the 6 Blind Man and the Elephant story.) Thus, a CAS, with multiple "views", has a much better chance.

The is true for humans. (Taken as a whole, each of us is a CAS, although some of us seem intent on dominance by one "logic" unit.)
For families.
For Teams.
For small firms.
And, if done at scale, for larger firms.
Clearly the free enterprise system in the US is a CAS (or what is left of the free enterprise system).
The world economy is also a kind of CAS.
(Not to mention other modes (than economics) of how groups interact across the world).
Perhaps there is a higher scale too.

A few people, with Scrum and similar approaches, are enabling CASs to develop at the Team level. Once we have multiple Teams in a firm going hyperproductive, what is far less clear is how to be effective in having Teams interact in a CAS way, as parts of one higher-level CAS. In Scrum we have some approaches to this (Scrum of Scrums, etc.), but it is less clear that we can have a group of 5 Teams then jump to "hyperproductivity" for that group.

This is normal. We have not learned to walk; we really don't need to worry about running well yet. In scaling Scrum.

Let me note in passing that, in the economy, more and more firms are working in explicit partnerships. And the partnerships take many different patterns. The Lean guys talk about "full" value stream mapping, across all the partners needed to bring customer satisfaction. So, we in Scrum perhaps have some more ideas yet that we can borrow from.

Most of us, I included, continue to be seduced by the notion that the overall firm (say, of 10,000 or 100,000 people) must also have some "overall" plan. Which would need to be prepared centrally, right? Certainly it seems this would be more efficient. (At least in one use of that term.) And then I think about efficiency and the firm, and in real life I find firms do quite well being extremely, obviously very inefficient. (In one or two meanings of that term.) They do something or things well, but maybe efficiency (in the way I am thinking of it) is not the key. Umm, maybe the oak tree's innovation approach is wiser than we knew.

Perhaps eventually we will completely give up on the Central Planner "fixing things" for us.

"Calling Dr. Jung, calling Dr. Jung."

Knowledge Decay & Tacit Knowledge

Daniel Brown did an interesting post on this topic. His main area is testing.
Disclosure: He mentions my talk about the Lean within Scrum.

See here.