References:
(from the book The Strategic Management of Intellectual Capital and Organisational knowledge edited by Bontis and Choo):
Chapter 19, (p278): Aligning Human Resource Management Practices and Knowledge Strategies by Bierly and Daly
In its basic form, a knowledge strategy can be viewed as a firm's set of strategic choices regarding two knowledge domains:
- the creation or acquisition of new knowledge and
- the ability to leverage existing knowledge to create new organisational products and processes
The most cruicial element of a firm's knowledge strategy is whether the firm focusses more of its resources on generating new, radical knowledge or on incrementally enhancing the existing knowledge base. According to Argris and Schon (1978), organisations tend to focus on one of two distinctly types of learning processes,
single-loop or
double-loop. Thos organisations that strive to incrementally increase the current knowledge base do so within an existing frame of reference, thus engaging in single-loop learning. In contrast, organisations that seek out new radical knowledge must challenge existing assumptions, values and mental models in order to move forward, a process Arygris and Schon call double-loop learning.
March (1991) also addressed the trade-off associated with either (but not both) a radical or incremental knowledge strategy. The continuous and incremental exploitation of current knowledge maximises profit in the short-run, whereas the exploration of radical new knowledge is more likely to maximise long-term success. Pursuing a strategy of exploration is more likely to lead to a sustainable competitive advantage.
Chapter 24 (p443) A dynamic theory of organisational knowledge creation
Since the first integrated theory of organisation learning presented by Agris and Schon ... can be very difficult for organisations to implement by themselves.
At this point, organisational theory leads to the notion of the Ambidextrous Organisation as a means to achieve both stability and innovation. Basically it means you run a variety of subprojects in separate organisational structures so that they are free to experiment - and fail - with radical processes and methods whilst not affecting the stablity of the main organisation and its highly standardised processes. "Radical innovation must be performed in a separate unit, which is not burdened by the path dependencies of old structures and ways of doing things, and must be later integrated to replace the obsolete traditional businesses (Christensen and Bower, 1996; Christensen and
Overdorf, 2000; Gilbert and Christensen, 2002)."
The independent project is needed because "Further studies have shown that ‘architectural’ changes in design will be problematic for established leaders (Henderson and Clark, 1990)." - leaders see the existing processes as being incrementally better yet are vulnerable to myopia: There are numerous examples of established firms failing in the face of radical technological change (Cooper and Schendel, 1976; Majumadar, 1982; Tushman and Anderson, 1986; Henderson and Clark, 1990; Utterback, 1994; Tushman and O’Reilly, 1996; Christensen, 1997). Various research streams have explored this phenomenon. Firms struggle with radical innovation because (a) they fail to invest; (b) they
invest, but in the wrong capabilities; and/or because (c) their dominant logic hinders them to invest.
Open Source
Successful projects such as Linux run two organisational streams; TWiki needs to be no different.
--
MartinCleaver - 06 Feb 2004
I can see what you're hinting at, however playing devil's advocate, it could be argued that TWiki already does run two streams - the Codev web & the Plugins web. I won't go into whether they do/don't should/shouldn't overlap, but those two streams do exist.
Codev is bound by the legacy of the long term development, whereas Plugins is free to get on with it without worrying about things like "Advocacy". (If they did, there wouldn't be so many
good and different skins and wouldn't be so many different ways of handling database type functionality and so many different calendaring options) It's also worth noting that there are two very different approaches to the way
code is handled between the two webs. (In Plugins code is released and accepted the instant the page is created and zip uploaded... People don't like the way I view/categorise the process in the Codev web, so I'll leave it at that.)
--
MS - 07 Feb 2004