"The only way to transfer somatic tacit knowledge to someone is through long term coaching.
He describes Relational Tacit Knowledge, which is about social interaction and how this keeps some knowledge unspoken. Basically its the things you could explain but don't, for one reason or another. It includes secrets, the things you don't know that you know, and the things you can't explain because you don't know what the other party needs to know. This knowledge remains tacit for social reasons, and the work of the knowledge manager is to go through the social barriers and retrieve this knowledge through questioning processes - for example in Knowledge Interviews.
Finally, there is collective tacit knowledge. This is about the way WE work. Its about knowledge held socially and collectively. He gives the example of riding a bike. The mechanics of riding a bike are all about somatic tacit knowledge, but the knowledge of riding a bike in London traffic are collective and tacit; you need to understand the unspoken social conventions, otherwise the taxis and buses will get you. It is the collective tacit knowledge that the interviewer seeks for in team knowledge processes such as After Action Review and Retrospects, and the facilitator seeks to exchange in Peer Assists and Knowledge Exchange meetings."
"This episode taught me a few things about innovation and creativity, which I list below:
Interesting opportunities lurk in unexpected places: A kitchen sink – who would have thought….
…but it takes work and training to recognise opportunities for what they are: If I hadn’t the background in the physics of fluid jets, I wouldn’t have seen the stationary waves for what they were.
A sense progress is important, even when things aren’t going well: Tony left me to my own devices initially, but then nudged me towards a productive direction when he saw I was going nowhere. This had the effect of giving me a sense of progress towards a goal (my degree), which kept my spirits up through a hard time.
It is best to work on things that interest you, not those that interest others: I stuck to my primary interest (mathematical modelling) rather than do something that was not of much interest but may have been a better career choice."
My stint in the polymer lab, very different from my solo research experience, taught me a few more things about creativity and innovation. These are:
Collaboration between diversely skilled individuals enhances creativity. It is important to interact with others, particularly professionals from other disciplines. I’m grateful to my colleagues from the lab for drawing me out of my “comfort zone” of theoretical work.
Being part of a larger effort does not preclude creativity and innovation – although I did not do any experiments, I was able to develop models that explained some of the phenomena that my colleagues found.
Even modest contributions add value to the end product – great insights and epiphanies aren’t necessary – none of the modelling work that I did was particularly profound or new. It was all fairly routine stuff, done using existing methods and algorithms. Yet, my contributions to the research added a piece that was essential for completeness.
"Mikhail Bulgakov spent his first couple of years (1916-1917) after graduating as a doctor in the depths of rural Russia. He wrote a number of semi-autobiographical short stories about the experience. In one of them, he is called out in the middle of the night to deal with a difficult and dangerous pregnancy, a transverse lie, in which the baby is lying horizontally with its shoulder nearest to the birth canal. His two experienced midwives looking on, Bulgakov tries to give an impression of competence, but while he aced his obstetrics paper, he knows the task of turning the baby – called a version – in the womb is hazardous, and all his book knowledge flies from him. On the pretext of getting his cigarettes while the midwives prep the mother, he rushes to his room and goes through his obstetrics textbook. Then as he scrubbed up for the procedure, his midwife “described to me how my predecessor, an experienced surgeon, had performed versions. I listened avidly to her, trying not to miss a single word. Those ten minutes told me more than everything I had read on obstetrics for my qualifying exams…”
After the procedure, which was successful, he returns to his room and starts flipping through his obstetrics manual again. “And an interesting thing happened: all the previously obscure passages became entirely comprehensible, as though they had been flooded with light; and there, at night, under the lamplight in the depth of the countryside I realised what real knowledge was.”
We sometimes think of explicit technical knowledge and tacit experiential knowledge as distinct things, because they come in different forms. In knowledge management we certainly manage them in different ways. But Bulgakov’s story reminds us of how intimately connected they are. The knowledge in the obstetrics manual is codified for reading no doubt. But it is itself a hardening and crystallisation of centuries of experiential knowledge. And getting the words into your head gets some knowledge into your head, for sure, but the experience of working with bodies is what brings that technical knowledge to fruition. What Bulgakov describes is a process of reciprocal enrichment and fusion between outer and inner knowledge, making the outer knowledge more accessible than before. So now I’m thinking, how do we manage for that kind of process? "
My hypothesis is that social intranets afford an alternative way to codify what you know, typically via first-person narrative (blogging), story-telling, less formal, less “structured” means of expression (or let’s say less “fielded” in that last bit, as all stories clearly have intricate and meaningful structures). Going back to the principles of KM, these modes of expression are closer to speaking; and as such, help get us closer to “what we know” if we believe that we truly “know more than we say and say more than we write down.” We move through Boisot’s I-Space, from problem-solving in a concrete/un-codified/not-diffused personal knowledge space, through to an increased level of abstraction and codification that allows for knowledge to be more easily diffused across the organization (hopefully on its way to absorption and impacting, helping others gain value from the knowledge asset).
Defined roles, such as the Marine Corps Center for Lessons Learned, and Crites' role which he describes as “a mixture of consultant and reporter.”
Supporting technology, such as MCCLL’s secure web site
Processes for capturing knowledge, such as the After Action Report.
Processes for synthesising and publishing knowledge ("The information is collected and analyzed. The lessons learned from that particular battle or event are extracted and published once a week")
Processes for Learning Before Doing (“A Marine that comes to war studies Lessons Learned, studies what his predecessor did before him, and that’s how he gets ready for deployment.”)
Governance, for example a top down steer on what needs to be learned ( “The command ... guide me into what lessons they want recorded, what lessons they’ve learned, according to their operations").
The process of the pilot revealed several insights that will help Domino’s bring PKM to more people.
First, learners want some guidance about the changing boundaries of professional development. Traditional models of learning involve taking a chunk of time to step out of the workplace. PKM makes learning a real-time activity within the flow of work. The company needs to clarify what people are allowed and expected to do in terms of learning during the workday.
Second, information services, particularly information security, needs to be a partner in the effort. The director of information security consulted throughout the effort and attended the workshop, where he was able to offer some valuable insights.
Finally, as learning practitioners, we’re awash in information about social tools and technology-enabled learning. It can be easy to overlook how unfamiliar busy professionals are with some of these technologies—especially in a work context. We need to take the time to help familiarize them with new tools, using practical, realistic examples.
It's hard to change someone's mind, but my hope is that John and the people who are greatly influenced by him come to realise that taking the story out of narrative does everyone a disservice. The idea that corporate narratives are important makes sense. The idea that the narrative should invite, perhaps propel, us into a future is what inspiration is all about. But divorcing story from narrative extinguishes the spark that brings narratives to life.
Presidents and CEOs aren’t the only executives building bridges between their organizations and the outside world nowadays. Take Beth Comstock, the chief marketing officer of General Electric. She is famous for her weekly “BlackBerry Beth” blog, in which she shares what she has learned in her external role for busy (and perhaps more internally focused) GE managers. The pithy and provocative blog goes out to thousands of GE’s sales, marketing, and technology leaders. In it, Comstock passes along interesting information that people might have missed, taking care to tie it back to challenges and opportunities GE faces. For example, in a recent post from the World Economic Forum, she reported that a panel of scientists had come to the same conclusion that a GE survey had—that technology alone cannot ensure innovation and that more training in creativity is needed.<br /><br />“I work hard to curate information that I don’t believe many at GE will have heard and to translate information in a way that is relevant to our challenges,” says Comstock. “I probably spend half of my time immersed in worlds beyond GE. I hope this encourages my colleagues to be more externally focused. The message is ‘If I find it important to spend some of my time this way, maybe you will, too.’”
The simple exercise typically gets a quick and easy solution. One player suggests something obvious and the others follow.<br /><br />The complicated exercise needs a bit of planning, typically everybody suggests something, a quick decision is made and process is adapted according to feedback during the build.<br /><br />The complex exercise doesn’t get better with more planning. The right process emerges and is continually adapted. The sooner teams start to build, the sooner they feel comfortable. It helps if all team members know what the animal/vehicle they want to build actually looks like.<br /><br />The chaotic exercise leads to quite surprising, sometimes not very good solutions (see the building without roof in the picture). People feel uncomfortable all the time, the solution takes longer than before. Especially for managers, this is an aha-experience: “So this is how it feels to change a team...”
Forcing people back to the workplace is not the solution because too often when they are in the workplace they are either sitting in a meeting listening to endless presentations, or in a cubicle sending emails to each other. Neither of those activities is worth the cost in time or travel. The only reason to come together face-to-face is for people to be in conversation with each other! And real conversation happens all too infrequently in workplaces, as my own research has shown.
Here, as in the hospital world, the phrase, "what happened to him could happen to anybody," is usually evidence of a systemic problem, not a personal problem. The Commonwealth of Massachusetts solved the problem of bus crashes on this road 30 years ago. A lack of maintenance or will or understanding on the part of the state administration caused this problem to recur this past weekend. It was, in a sense, inevitable.
Many writers believe they are just "not good" at certain things. Many face periods of doubt where they believe they are "not good" at writing. But writing, like anything, can be improved with practice. If you are not "good" (in whatever parameters you've set for yourself, given how fluid a term like "good" can be), this doesn't mean there's something essentially wrong with you. Failure is part of the process, not an indicator that you've chosen the wrong dream. Maybe you just need to gain a level or two.
My discomfort really comes down to a distrust of the concept of "knowledge representation" that underlies some ontologies (especially earlier ones). The complexity of the relationships among parts will always outstrip our attempts to capture and codify those relationships. Further, knowledge cannot be fully represented because it isn't a thing apart from our continuous invention, discovery, and engagement with it.
In all such cases, there seemed to be a consistent theme. Very few companies had actually defined what knowledge meant to them and therefore what the purpose of these processes and systems was meant to be. There was an almost blind belief that, having defined their vision and procured the solution, it should just work. So why doesn’t it?<br /><br />If the management of information and knowledge is to be for the benefit of those who are actually doing the work on a day-to-day basis, the starting point must be to determine the value of it to them and to the firm.
If you’re in a similar situation, here are a couple of ideas about how you may lessen the (over-) reliance on a few individuals:<br /><br /> Create regular knowledge sharing sessions where the central/program team don’t act as ‘experts’, but as brokers<br /> Rotate the role of ‘chair’ for meetings so more people take ownership<br /> Make ‘site visits’ a part of the induction process to foster sideways collaboration<br /> Short exchanges of team members. Working along side someone else creates a stronger connection<br /> Peer reviews of major deliverables before ‘top down’ approvals<br /><br />Organisations should be acutely aware of the risk of relying on a few passionate souls. The first step to mitigate this risk is to map out exactly how reliant you are and on whom. Once you understand the exact gap you can put in place very targeted interventions to minimise the risk. Finally, map the relationship patterns at regular intervals to check the effectiveness of your interventions.
Avoid deﬁning knowledge within functions or silo-oriented communities of practice; instead deﬁne knowledge at the level of business processes.
Remember that knowledge is operationalized by people; hence, a knowledge management initiative must relate knowledge to people’s day jobs.
Tacit knowledge resides within people and their behaviours; hence attempting to apply Information Technology to tacit knowledge is fraught with difﬁculty. Instead, it is explicit knowledge that is most susceptible to the application of Information Technology.
Knowledge is context-speciﬁc. It should be owned and maintained by people within the organization. Hence, external input to knowledge management initiatives must be carefully managed to ensure people within the organization are in control of the initiative at all times.
Implementing knowledge management involves change in the organization. Understand the organization’s willingness to change and manage people’s expectations appropriately.
Embedding Knowledge Management means making part of the normal work process, rather than an add-on. You do this in four ways.<br /><br />Firstly, you write Knowledge Management roles and accountabilities into the Organigram. You introduce new roles where needed (lesson teams for example, leaders and coordinators for the big Communities of practice, Practice Owners and so on), and change some of the accountabilities of existing roles (the most senior experts, for example, need clear KM accountabilities, as described here. You need to change their job descriptions, so that they are held acountable for stewardship of the company knowledge). Then you measure and reward people against their performance in these roles, and against these accountabilities, just as you measure and reward them against any other component of their job.<br /><br /><br />Secondly, you write Knowledge Management processes into the work cycles (using the principles of Learning Before, During and After). Change the project requirements, to include mandatory processes for capture of knowledge at the end of the project or after key milestones, and mandatory processes for reviewing past knowledge at the start of the project. Change the rules for project sanction, so a project gets no money if it hasn't done any learning.<br /><br />Thirdly you change the technology suite so that Knowledge Management tools are available, and used, as part of the working toolkit, and linked into the existing work tools. While email remains the number one work tool for many people, then link your KM tools into this, rather than requiring people to acquire a new habit. New habits can develop later, when KM becomes part of natural behaviour.<br /><br />Finally you change the governance. Make KM part of the company values. Write it into the policies. Write it into the way people are rewarded. Change the reporting requirements, the HR appraisal mechanism, change the incentive scheme to reward collaboration and discourage competition.<br />Do these, and KM will be fully embedded as part of "the way you work"
Click in to find related links.