Conversations
with Tom Stewart -- Part II
Bursting Bubbles
Table of Contents
(Click
on list item to go directly to each topic)
 Training Beyond Rote
Learning
David
Hawthorne, Corporate Learning Services, NYU School of Continuing
and Professional Studies:
Haven't we heard Tom's argument about every business fad that
has come down the pike. It's like puppy love, full of promise
but then, reality gets in the way as we gain experience and mature.
The problem with
KM was and is that we don't have a lot of experience with it
in real life. The technies tried to tell us . . . and we bought
it, hook, line and sinker . . . that networking information was
knowledge management. No more than tossing a ball around is baseball.
The ideas embodied
in KM principles seem absolutely right. They ought to work. The
problem is that almost all of our experience is with organizations
(including educational institutions and businesses) that are
hierarchical, compartmentalized and competitive at the individual
level (and our business processes such as accounting practices,
ROI calculations, and reward systems reflect that reality in
how they keep score).
At the Delphi/AOK
conference I was struck by Hubert Saint-Onge's presentation of
the "teaming" concept. Here was a way to "practice"
KM principles and, to the extent that Clarica's teams out performed
competitors and predecessors, "proof" that KM works.
(In the end, that does not mean that KM will out maneuver the
business cycle, or any of the other countless things that can
go wrong with a business, but it should be able to show superior
results against other organizations drawing on similar resources).
Not every organization
is going to be able to make the commitment to KM practices that
Clarica has. However, nearly every organization does engage in
training at one level or another. I don't want to underestimate
the difficulty, but organizations that train and don't use that
opportunity to introduce and practice KM principles are missing
their best opportunity to effectively adopt these organizational
practices. Unless people have favorable experiences with "collaboration,"
"knowledge sharing," "teaming," and a host
of related challenges, they are never going to carry over these
concepts into on-the-job behavior.
First, of course,
we have to completely renovate the way we do training and the
way we think about training. We need training goals that go beyond
rote learning toward true learning experiences that make us think
and reflect. We need to break training out of its episodic mode
and make it JIT and continuous (integrated, opportunistic, accessible).
We need curricula that offer "coaching" and "mentoring"
that go beyond the "training group" into the "workgroup."
We need curricula that teach teams and not just individuals.
Training budgets,
missions, and practices can be aligned with KM principles. We
have the technology, we just need to use it wisely. (If we need
an example, check out the performance of our Special Operations
teams in Afghanistan. Their success is due to training that foresaw
a need for the "integrated battlefield" concept that
links a soldier in the field to the vast and complex resources
of all the branches of the military.)
Tom
Stewart:
Absolutely agree here. KM is not an application. It's a suite
of activities, social and technical, that improve the use of
and development of knowledge in organizations. Training is, in
an of itself, a knowledge management activity. And the best training,
as I write in my book, is built around knowledge management principles,
including sharing, collaboration, and, above all, action.
Three top-of-my-head
thoughts: Training is, by definition, knowledge-sharing -- from
trainer to trainee, at the very least, and knowledge management
ideas about how to make knowledge sharing work should improve
the efficacy of training. Second, done right, training helps
to honeycomb an organization with networks of contacts and communities
of practice -- old-boy networks, in effect. Third, I think there's
a real opportunity for corporate training centers (the corporate
university, in big outfits) to become the publisher and maintainer
of expertise directories and corporate yellow pages.
John
Barrett, principal, ITI Associates:
During Hubert Saint-Onge's presentation at the Delphi/AOK KM
Summit he briefly but very clearly stated that training and development
should be done away with!!! As I recall the context, he was indicating
that CoPs were where "all" learning should take place.
While concurring
that CoPs should be key in promoting knowledge transfer, I must
say I respectfully disagreed with the notion that training and
development should be eliminated. It would appear that Tom Stewart
and David Snowden, who also keynoted at the Delphi/AOK Summit)
would also disagree.
It would certainly
be great if Hubert were able to jump in and add his views to
Tom's response to David Hawthorne's question. Regardless I would
like to ask Tom for his thoughts about, or examples of integrating
CoP's into the training/knowledge transfer equation.
David
Hawthorne:
I had a similar moment during Saint-Onge's presentation (at the
Delphi Group/AOK Summit) when I thought he was arguing for the
elimination of training, but as he continued I thought I heard
something that sounded more like an argument for the elimination
of training as it is practiced today.
In academia you'll
find little acceptance of the idea of "training" beyond
the sports field or the professions (e.g. medicine, law).
"Training" is generally presumed to be episodic and
comprehensive, i.e. it contains everything you need to
know in order to perform a specific task. It is in the domain
of "experience" more than "knowledge." Education,
on the other hand, like knowledge, is deeply embedded in culture
and about a beginning, not an end. Business, with its interest
in speed and competitive advantage, is trying to develop a "strategy"
based on "learning" rather than training because "learning"
holds out the promise of being able to act based on perceived
opportunity while "training" produces a specific response
to a specific trigger. No trigger, no action.
Tom
Stewart:
I didn't hear Hubert's presentation, but I do remember what he
did when he was at CIBC, and I suspect that he's still thinking
along similar lines. At CIBC, he did away with mass-produced
training. He worked to develop lists of competencies and skills
that were expected for each job -- you should know how to do
a, b, c, d, e, f, and g. And then he put the monkey on the employee's
back: You are supposed to know a-g. You are missing d and e.
Here are various ways you can learn them. Go to it. It's your
responsibility.
Adding communities
of practice to that makes sense: Here are your allies, network
partners, friends, coconspirator -- learn from them (and from
the local college with which we have a deal, and from various
training modules we have available to you).
So Hubert -- if
I got that right -- isn't really saying: "no training, ever"
-- he's saying, "let's abolish the traditional training
modules" -- and he's quite right.
There's lots of
evidence that communities of practice are essential to learning,
knowledge transfer, knowledge sharing, "training,"
and executive/leadership development. Study after study shows
that people get more from informal training than classroom training,
learn more from their colleagues (on the line, in the office)
than from the manual or from course work. A few years ago the
McKinsey Quarterly had a piece (Helen Hanfield Jones, How Executives
Learn, McK Quarterly 2000 #1) showing that executives learn most
from mentoring, informal feedback, and the structure of their
jobs (how much stretch, e.g.) than from anything else.
A report from the Center for Workforce Development, called "The
Teaching Firm" (1998) shows the same at all levels. Especially
-- almost by definition -- is this true of tacit knowledge, which
simply can't be shared except by osmosis.
In my book Intellectual Capital and
the Twenty-First Century Organization, I recount a story
about Japan Roche's pharmaceutical sales reps. The company faced
a crisis because of falling sales of some key drugs, with no
new ones in the pipeline. But -- since some sales reps consistently
outperformed others -- it realized that if it could raise the
performance of the less good reps, it could reverse the sales
decline. Training couldn't do it. What they did was a program
of sending the superior reps out in small groups to hang out
with the other reps. It's a terrific example of using the community
to solve a knowledge problem that underlaid a business problem.
This said, a caveat:
There seems to be a growing tendency to try to mandate the existence
of communities of practice. They don't work that way. They are
part of the informal organization, not part of the formal organization.
The medical reps already were part of a community. What Japan
Roche did was use the pre-existing informal community; and used
it in a way that didn't violate the informality that is an essential
part of it.
Back
to top
Project Teams Are
Not CoPs
Jack
Vinson:
In the excellent discussion of abolishing training "as we
know it," Tom said "This said, a caveat: There seems
to be a growing tendency to try to mandate the existence of communities
of practice. They don't work that way. They are part of the informal
organization, not part of the formal organization. The medical
reps already were part of a community. What Japan Roche did was
use the pre-existing informal community; and used it in a way
that didn't violate the informality that is an essential part
of it."
In Hubert's (Saint
Onge) talk he discussed the idea that some communities _could_
be forced. He used a two-axis description of communities: One
axis ranged from Structured to Unstructured, and the other from
Project to Functional. His argument was that structured communities
tend to be appointed, accountable for a specific goal and probably
part of the formal organization/hierarchy.
Hubert also referred
to this under the general name of "virtual collaboration,"
rather than communities. I believe he categorized communities
of practice/interest under the "unstructured" type
of collaboration, where participation is voluntary based on common
needs. So, I come back to agreeing with Tom's statement after
all.
I also like the
idea Hubert mentioned that no project should be longer than 90
days. We are in the process development branch of the business,
and our initiatives last a year or more. However, in that time
there are many sub projects and the overall goals of the project
keep mutating with changing business requirements. I can really
see that a 90-day project length could be easily coupled with
longer functional teams (project - functional being Hubert's
other axis).
Tom
Stewart:
Jack Vinson reports that Hubert's Saint Onge talk discussed the
idea that some communities _could_ be forced. He used a two-axis
description of communities: One axis ranged from Structured to
Unstructured, and the other from Project to Functional. His argument
was that structured communities tend to be appointed, accountable
for a specific goal and probably part of the formal organization/hierarchy.
Those are called
teams, or projects.
This may sound like
nit-picking or pedantry, but it's not -- it's actually central
to the problem knowledge management is having and that has been
discussed at length during my stint in the STAR seat. You might
call it "jargon creep" and consider it the linguistic
cousin of what project managers call "scope creep."
That happens when a project, which was supposed to do A, B, and
C, is asked to add in D, E, and Q as well, usually with no additional
time or budget. Quite often D makes sense, E sorta fits, and
Q is the pet idea of a senior vice president. Scope creep kills
projects -- stretches them beyond their limits, beyond their
business case, and beyond the possibility of coming in on time
and in budget.
Jargon creep is
the same thing. It happens with natural insidiousness. A term
becomes sexy. Communities of practice is such a term. (It's so
sexy that the phrase "community of practice" just got
me "about 18,000" hits on Google.) And so everybody
with an idea to pitch or a software package or consulting service
to sell crowds in around the term. Just as a heavyweight boxer
magically attacks an "entourage" (best friends from
kindergarten, shady accountants and investment advisors, and
drinking buddies whose chief skill is using your Platinum Amex),
so every hot idea attracts people who want to bask in or exploit
its glow: "We're like that." "We're part of that
idea." "Kosmo.com and Webvan are avatars of the New
Economy." "Project teams are communities of practice."
They are not. Sorry for shouting. But
it's important to have the language clear. Project teams are
great things. They are where the work gets done in flat, knowledge-based
organizations. They have deadlines and budgets. Communities of
practice do not do work, except incidentally. Communities of
practice are where human capital gets created and shared. They
have no deadlines, no agendas, no fixed budget. They have a shared
passion. (Please everyone read Etienne
Wenger's books on communities of practice.)
Yes, they can overlap.
Sometimes a community of practice can emerge out of what began
as a project team. And sometimes a project team can grow out
of a community of practice, when a bunch of people who were already
part of a community decide to undertake a specific job. But they
are not, not, not -- emphatically not, in case you missed the
point -- synonyms. And Hubert, whom I love and admire, is, for
the first time in his life, wrong, wrong wrong. Project teams
and communities of practice do not belong on a continuum or as
points on a grid. They are on different planes of existence.
(This reminds me
of a talk I heard Dave Snowden give, in which he pointed out
that the idea that there's a continuum from data ---> information
---> knowledge ---> wisdom is wrong, too. Basically, as
Dave said, data and information are qualitatively different from
knowledge and wisdom. You can't take 8, 16, 32, 64, or a zillion
bits of information and add it up and say it's now one unit of
knowledge, for example.)
Roger Wright, Take
Hold Training writes:
"Meanwhile,
rumblings of 'knowledge Management' would bubble up out of MIS
where a steady stream of software vendors took possession of
the term as has previously been described on this post. Sometimes
I would whisper the words "knowledge management," amongst
the people charged with retaining a customer. But I would never
say it very loudly, never say it in front of a customer, and
almost never say it in front of my boss.
And, Jack Vinson,
writes:
"Do we need
to begin a new push for measures of intangible assets?"
Yesterday Adrian
Slywotsky, the Mercer Management consultant who is the author
of The Profit Zone among other books (and maybe the smartest
guy around, except for those of us reading this list, of course)
was in the office. I won't try to summarize all he said, but
the gist was this: When companies look for new growth opportunities
(the product-services business that lies inside many a manufacturer,
for instance, or channel management, or even traditional new
product lines) their success depends on "hidden assets"
in the organization that are the product of its original core
business.
He mentioned, inter
alia, brand, customer relationships, core competencies, intellectual
property, network assets like your installed base, information
assets (e.g. all the stuff data miners want to mine). He didn't
call them intellectual capital or knowledge assets -- just hidden
assets -- but they all fit comfortably into the categories we
intellectual capital types are used to (human, structural, customer).
These things, he said, can help a company with a strong core
business move into a new market more effectively and for less
money than if it had to start from scratch. (Indeed, he offered,
you could probably put a value on the assets by figuring out
the difference in cost.)
I put to him --
and he agreed vigorously -- that one of the (many) difficulties
in putting these assets to productive use is the fact that they
are often "owned" by people who think of themselves
as functional specialists, not business people, who probably
have never seen a live customer, and whom you might even want
to keep away from customers. The assets are produced and owned
by people who live in cost centers.
This little ramble
doesn't really answer the issues raised by Roger and Jack, but
perhaps it helps to describe the problem. I do suspect -- and
this gets to what Jack said about projects having to have an
ROI -- that one element of the solution is, as much as possible,
to design work so that it is not done in a series of departments
with a corporate staff overlooking all, but in a book of projects,
which are cross-functional. That way the owners of the hidden
assets -- the HR guys, IS guys, finance guys, etc -- are involved
in operations work, not just staff work, bringing those assets
to the place where value is actually added, and sold.
I believe we need
to ascribe value to intangible assets from some sort of accounting
point of view. But I think that's a separate track, and can even
be distracting. I.e., you're not going to make your case
by saying "our knowledge assets are worth $3 kabillion."
The CEO knows that, intuitively if in no other way. Her question
is, is "Nu?" -- which is untranslatable Yiddish meaning
approximately "So?" as in "That's all well and
good, but what does it do?"
Back
to top
Role of Six Sigma
in KM
Keith
De La Rue:
This may be a slight digression (I love digressions), but I would
like to ask a question prompted by your reference to the role
KM plays in Six Sigma projects. I am interested in how well the
underlying philosophies of KM sit with those of Six Sigma. My
(maybe ignorant) opinion of Six Sigma is that it is very similar
to its predecessor TQM, and places an emphasis on process, rather
than people. In contrast, I see KM as placing the emphasis on
people instead. Is this a conflict?
I work in KM in
a company that is ramping up Six Sigma in a big way, with high-level
endorsement, and I wonder if this creates an environment less
amenable to KM initiatives.
The problem I see
with a process-driven philosophy is that it disconnects people
from results - if something in a business is not working, blame
the process, not the people. The logical extrapolation of this
(never mentioned by the TQM experts) was that if things were
working, it just meant that you had your process right, and there
was no need to reward people. In my experience, KM only works
in an environment where people are rewarded for their achievements
and knowledge sharing. To illustrate further, see Fred Schoeps'
quote that I am currently using in my e-mail signature . . .
.
Tom
Stewart:
Six Sigma is TQM, yes, with more statistical rigor and stronger,
more detailed methodologies. But I don't see why processes and
people are at odds with each other. Six Sigma seeks to drive
out variation -- i.e. errors, things going wrong, processes
getting out of spec, etc., etc., etc. It does this with pretty
rigorous methods. But people do this. People set up tests. People
make hypotheses. People analyze the statistics. People brainstorm
and experiment to see what changes will reduce the defect rate
or bring a process "under control." And people are
trained in the tools -- black belt and all that -- that enable
them to do this job better. Six Sigma is, at its heart, fact-based.
What's really going on? That's a good thing, as Martha Stewart
would say.
I think you've very
much got the wrong end of the stick when you say "The problem
I see with a process-driven philosophy is that it disconnects
people from results -- if something in a business is not working,
blame the process, not the people. " I think it's immensely
humanizing to say "We believe that you are trying to do
a good job -- are doing the best job you can. And if things go
wrong, we believe that we corporately -- through our madly designed
processes -- share part of the blame for that. Therefore we want
you, whom we trust, to help us improve the process, so that you
can do the best job of which you are capable, and not be hamstrung
by our idiot processes." That's not inconsistent with personal
responsibility. Nor is it inconsistent with individual (and team)
rewards for improvements -- gainsharing is a powerful thing,
and frequently part of Six Sigma programs.
The dark side of
personal responsibility is scapegoating and the blame game: To
say "it's all your fault" when nobody could have overcome
the obstacles created by a stupid-ass process. Deming's great
contribution was to say "First, drive out fear."
Look at the medical
world, where the culture of blame (reinforced by lawsuits) is
so strong that nobody admits responsibility for anything. Result:
It's very difficult to have a candid conversation about the causes
of problems -- because if you admit your share, you'll be sued.
So everybody points the finger away from himself. We all know,
further, that in complex systems our actions are interdependent.
Just as two drugs, perfectly safe by themselves, can interact
with catastrophic results, so two people (or teams, or departments)
can do the right thing individually but cause a catastrophe because
of their interaction. One out of 100 surgical patients gets an
infection in the operating room. That's 10,000 per million --
whereas six sigma tolerates just 3 per million.
I think you're letting
a false choice get the better of you. It's perfectly possible
for Taylorism to become dehumanizing, but there's nothing in
TQM or Six Sigma that's inherently Tayloristic. Gardeners use
rakes and hoes, after all.
Keith
De La Rue:
Thank you! I was being purposely harsh in my comments on Six
Sigma, as a way of searching for a more human side of this discipline.
My view of it has obviously been somewhat jaundiced by some seemingly
"non-human" individuals that were pushing TQM in a
previous life. It is refreshing to hear that there does not have
to be a choice (between people and process).
Which I guess leads
on to another set of questions -- Does anyone out there have
experience in applying KM in a Six Sigma environment? How do
you fit these together? Can Six Sigma in fact be used to build
knowledge sharing behaviours into business process? Bring in
the rakes and hoes . . .
David
Hawthorne:
I think our approach to training needs to be completely renovated.
We ask it to do too little, not too much. Our training methods
and processes reflect the vertical thinking of the industrial
age. By the way, I am not arguing for an approach to learning
anything like that practiced in institutional education, which,
for the most part, hasn't even reached the Industrial Age. I
am arguing for a totally integrated approach to organizational
learning which emphasizes collaboration, teaming, knowledge sharing,
a complete set of resources, and curriculum design that matches
learning objectives and learning environments to business strategy.
We ask people to
adopt KM principles and behavior when they have virtually no
prior experience with it and when there is little evidence of
support for it. Where do we expect people to learn successful
KM practices and behavior? They won't learn it in conventional
education (where collaboration is "cheating.") And,
they probably aren't going to learn it on the job where rationalization
leads to back sliding. Anything we need to teach or learn in
business can be taught or learned in a "training" process
that is based on KM principles. Our training departments can
become learning laboratories and KM-simulators that can "train
for competency" just as well and just as effectively as
our current training departments.
They can also do
more by breaking out of the confines of traditional training
practices and metrics. Maybe we need to change "training"
departments into "Learning Departments" that look different,
are staffed differently, and are tooled differently. Maybe, the
Learning Department has to be a virtual -- or virtually virtual
-- department (e.g. a handful of "learning specialists"
collaborating with departments and teams to design appropriate
training content, resources and "learning experiences").
The Learning Department
has to be around (at least virtually) when knowledge in used
in practice so that new knowledge can be accounted for. It has
to operate formally and informally. When I think about a Learning
Department, it operates in Snowden's four domains as depicted
in his "Third Generation KM" paper at the Delphi/AOK
Knowledge Exchange conference.
The goals of corporate
learning should be no different than other business goals. Did
we do more deals, better deals, sell more, spend less, innovate
more? Do our most productive people want to stay or go? If KM
is difficult to measure in ROI terms when it is practiced on
a compartmentalized rather than enterprise basis, then Return
on Expectation (ROE) is probably a better measure. (A colleague
once suggested creating a Knowledge P&L, metaphorically,
I hope.)
When we adopted
a virtual classroom technology for our corporate learning service
we ran a number of pilots (with financial services companies
and a global advertising company) and intensely observed how
this new delivery environment impacted learning. We had to develop
team teaching techniques, then team learning techniques. We had
to completely change our approach to instructional design and
develop criteria for what can, could, or should be done synchronously
or asynchronously, or self-directed. We changed the role of the
SME. We had to build and manage virtual communities to help keep
the learning behavior going informally during intervals between
formal training experiences.
While the content
was highly rated by the participants, the greatest value to many
was the new learning environment that helped them learn to work
collaboratively and help them form "informal" communities
that spanned departments, companies, and continents (And, by
the way, costs compared favorably with those of conventional
training approaches.) With every successive assignment, we learn
more and adapt. I'm not sure that the process can be separated
from the human component -- not as long as knowledge is both
particle and flow.
John
Barrett:
Two responses:
First to Roger Wright
-- I suggest that we as KM Professionals (KMPs) and Professional
Consultants (PCs) have a dual role at this point in the life
of Knowledge Management. By "point in the life," I
mean that while every one in the business world has a mental
model to describe and accountant (accounting) or a lawyer (law)
or an educator (teaching), none yet exists for a KMP (knowledge
management professional).
So, on the one hand,
the KMP's role is to educate as to what KM is and what we do.
Our role as PCs, on the other hand, requires that we understand
client's issues and design solutions that address these. Since
many prospects/clients don't yet understand exactly what KM is,
they rarely think of their own issues in KM terms.
In my approach I
try to start where the clients are and, through our discussions,
work to help them develop a model of what KM is and how implementing
KM principles and practices can help their business issue.
From a marketing
standpoint to interest the largest potential client at this time,
we need to first focus on the business issue, then the solution,
and then as KMP educators help the prospect understand link.
To Keith De Le Rue
-- If the Six Sigma environment means an organization that using
this technique to drive our variation in their processes, then
I would say by all means KM can fit. I'll comment on this further
below.
However, if a SS
environment means the specific initiatives of employee SS tools,
then I am not certain there is a significant KM opportunity,
but there is some. By nature, these initiatives are intended
to make a process very deterministic with minimized opportunity
for tacit knowledge to be randomly applied. If we accept the
general figure that seventy percent of all knowledge in an organization
is tacit, then only a small portion of the pie is available.
A well designed and executed process certainly needs access to
content and codified knowledge to be successful, obviously a
KM opportunity.
In a recent Sloan
Management Review article "Process Management and the Future
of Six Sigma," it is argued that SS initiatives must take
place within the larger endeavor of process management. If this
is accepted as a premise, then using KM practices and principles
for business process design and management should be viewed as
a necessary and important compliment to SS tools and techniques
being applied to segments of the larger business process.
Back
to top
 Part
It
Part III 
|
