Showing posts with label recognition. Show all posts
Showing posts with label recognition. Show all posts
Tuesday, July 20, 2010
Unappreciated Experts Will Leave
We have lots of interfaces between government and citizens and expert groups. We are a large organization. We have lots of people with 20 – 30 years of experience and yet they are not treated as having expertise or wisdom. They are considered to be in “ordinary” jobs with low recognition and not so much training required. There will be huge loss of knowledge when these people leave. Their know how is not appreciated.
Sunday, March 21, 2010
Experts respected for organisational knowledge more than technical knowledge
This was my first experience as a "knowledge engineer" trying to build an "expert system" for a chemical processing plant in the mid 1980s. That experience still shapes a lot of my thinking. Firstly the context was the archetype expert system one, the expert operator (and long term foreman), 35 years + experience, retiring in 12 months ... his name was Maurie. He had the total respect of the rest of the operating crew (who I might add only averaged 20 years on the job).
After doing my knowledge engineering thing and extracting a few hundred "expert" rules, I began testing them with the "junior" operators. Anything special or insightful? No not really... the common answer was yeah you could do it that way. Would you change your action if this was recommended? Maybe ... not sure if it matters. Even Maurie was a bit ambivalent and supported them in saying yeah that could work too. This was pre- TQM days and shortly afterward the standard operating procedure (SOP) was born, so there was a lot more support for standardisation ... not so much from what might work or what might not, but a view that if we standardised actions we would at least have a measurement environment that operating performance drifts could be more easily identified.
When we implemented the system I would have to honestly say that the value the operators gained was not so much in the "insightful" recommendations the system made, but the "evidence" in terms of signals tracked and displayed to justify the recommendations that were most valued.
I continually experienced this in my Expert Systems days. A case based reasoning system for a consumer call centre was of most use to novices. More experienced staff would want to make their own decisions but appreciated the support information. Expert Systems in my experience worked best in the "complicated" domain (viz Cynefin)...where the effort of logically breaking down a decision process was both viable and valued.
As for Maurie ... why was he so respected as THE expert when the knowledge base we built from his so-called tacit knowledge was not seen as anything special? Well I learnt that respect and expertise can be different things. Perhaps Maurie's technical expertise was not necessarily superior any more to the 20 year "juniors". His people and organisational skills in working with the other operators was superior ... hence the respect that he was given. As one operator quipped ... Maurie knows where everything is .... you want a shovel or a broom....Maurie knows where it is!
I've recently interviewed some chief engineers that will retire soon. I found the same thing...its not their technical "tacit" knowledge that is valued as much as their "organisational" knowledge...especially the "how do you get stuff dome around here" tacit knowledge.
After doing my knowledge engineering thing and extracting a few hundred "expert" rules, I began testing them with the "junior" operators. Anything special or insightful? No not really... the common answer was yeah you could do it that way. Would you change your action if this was recommended? Maybe ... not sure if it matters. Even Maurie was a bit ambivalent and supported them in saying yeah that could work too. This was pre- TQM days and shortly afterward the standard operating procedure (SOP) was born, so there was a lot more support for standardisation ... not so much from what might work or what might not, but a view that if we standardised actions we would at least have a measurement environment that operating performance drifts could be more easily identified.
When we implemented the system I would have to honestly say that the value the operators gained was not so much in the "insightful" recommendations the system made, but the "evidence" in terms of signals tracked and displayed to justify the recommendations that were most valued.
I continually experienced this in my Expert Systems days. A case based reasoning system for a consumer call centre was of most use to novices. More experienced staff would want to make their own decisions but appreciated the support information. Expert Systems in my experience worked best in the "complicated" domain (viz Cynefin)...where the effort of logically breaking down a decision process was both viable and valued.
As for Maurie ... why was he so respected as THE expert when the knowledge base we built from his so-called tacit knowledge was not seen as anything special? Well I learnt that respect and expertise can be different things. Perhaps Maurie's technical expertise was not necessarily superior any more to the 20 year "juniors". His people and organisational skills in working with the other operators was superior ... hence the respect that he was given. As one operator quipped ... Maurie knows where everything is .... you want a shovel or a broom....Maurie knows where it is!
I've recently interviewed some chief engineers that will retire soon. I found the same thing...its not their technical "tacit" knowledge that is valued as much as their "organisational" knowledge...especially the "how do you get stuff dome around here" tacit knowledge.
Labels:
expert systems,
recognition,
respect,
Value of Expertise
Friday, January 15, 2010
The Man Who Knew Too Much
Here was an older engineer (let us call him Mr. Gupta) in a large manufacturing organisation. The emphasis in the organisation was on 'activity'. Those that showed enthusiasm were rewarded better than those who really knew the job. Mr.Gupta's philosophy was 'prevention better than cure'. But this was not glamorous. Younger engineers would jump in & be part of the excitement in firefighting. Mr. Gupta would refuse to be a part of this firefighting, which according him could have been prevented in the first place if only they had listened to him, which point he would not hesitate to recite to any one who came in contact with him. This obviously made him unpopular with the management and a laughing stock among his peers.
Mr.Gupta became a frustrated man and a mental wreck.
Mr.Gupta became a frustrated man and a mental wreck.
Saturday, February 21, 2009
Expertise Directory
When I joined the Asia Pacific region of a consulting firm, the consulting practices were then very new, expertise in the different lines of business or industry sectors wasn’t very well developed. But there was a lot of pressure to build up those practices – we needed to capitalize on expertise in order to build our market and revenue. The KM group identified particular kinds of expertise by business lines and industry sector, we documented it and put it online. If there was a market opportunity, you could refer to a list and draw on them for help in developing a proposal – they were often in Australia, so we would fly them out to meet the client in the bids. We got a lot of work this way. Some people nominated themselves for the expertise directory, or we found them through examples of client work, publications or recognition by peers. The biggest challenge was getting their time – taking people away from their normal job to contribute to somebody else’s practice, so we put in place a recognition scheme.
Last Woman Standing
Sometimes you have to be an expert even when you’re not really one. An organisation I was working for as a contract worker was subsumed into a larger organisation. Lots of people were got rid of, and I was the only one left who knew how the library worked even though I was only a contract worker. But I was asked to train people in library work. I asked if I could be recognized for the training work, but the boss said “No, it’s not really training”. I said I wouldn’t do it, but because of the contract I had to.
Thursday, January 8, 2009
Acknowledge!
I receive feedback from people that they don’t mind sharing, but there’s a lack of acknowledgement of contributions. After a while, they become reluctant to share.
Monday, January 5, 2009
Taking credit
We share our experience on organizing events. Individuals and divisions are interested in what we know. We have no issues, but our SOPs have been abused. We put a lot of time and expertise into our SOPs. Those divisions borrow our SOPs and change them and claim credit. We are not acknowledged. Sometimes, they leave for another agency, also heading events, with our SOPs. They need to let us know what their intentions are. Now, we are careful about what we share. If we don’t know what it’s used for, we just give general answers. We share freely but in other agencies, knowledge is competitive advantage or even IP. Where do we value-add? Do we give the lot, lock stock and barrel? Before we give, we have to find out what’s the value-add. There are lots of free riders here. You don’t need to work so hard, you just need to know someone to ask. There was an exodus of people who left us for other agencies. They asked for manuals, SOPs from us before they left.
Labels:
acknowledgement,
recognition,
stealing,
Value of Expertise
Inexperienced boss, experienced staff
New people and new bosses bring in new perspectives, but they still have to learn from older staff. We shouldn’t differentiate by rank. We are all in it together. It’s hard to answer who comes in. We are experienced and when the new manager comes in, we teach them everything they need to know. But we don’t get recognized.
Subscribe to:
Posts (Atom)