Head, Hand and Heart for Change

I am not a philosophy major, but I understand the differences between reason, will and desire. In a corporate setting, most published “content type” from top is just plain reasons viz. whys to do something, to approve a budget, to take up a new initiative, an ROI and more such. But the will and desire are left out mostly. When you hear “to lead by example or walk the talk”, it is an indication of will, and when you hear “did not feel like doing it” “ Yes, but…” it is an indication of desire (or the lack of). At this point, we depart from the simple system definition to one in the complex domain as the agents and actions are intertwined. Will and desire (or the lack of) spreads faster and influence actions more than the published reasons. To work only with reason and undermine will and desire is a forceful push from the complex domain to simple domain.

A simple framework for action/change thus in any reasonable sized system should handle all 3 (reason, will and desire). One may be more magnified than the other, and in fact, they should be. When this happens, a series of actions unfolds with no clear attribution possible. These are system responses and agents are playing part. Here is where stories that people tell each other and social objects come in, bringing players from all over the system for action willingly.

A simple metaphor for this framework is the simple head-hand-heart to reason-will-desire respectively. In action/change scenarios, all 3 operate simultaneously, but you can never determine outcomes. If boundary conditions are favorable, outcomes are impactful and always contextual.

Now to orient a bunch of leaders on this head-hand-heart framework is easy, make a list of past failed initiatives like below

  Head/Reason Hand/Will Heart/Desire
Initiative 1 <<Enter biz case/ROI/5W etc>>    
Initiative 2   <<Enter policy change, mobilized support, experiments done etc>>  
Initiative 3     <<Enter social objects, desires tapped, etc>>
Initiative n      

When you fill this up, you will notice that the last column will be the most sparsely filled or even empty.

Coming from an industry that runs on perennial initiative fatigue, I was not surprised when I filled one for myself.

Try it …


Collaboration delineated

‘Why’ is usually more important than the how. As knowledge managers do not usually have any say in ‘why collaborate’, they are stuck with the how. And then there is the constant tradeoff between why a business does something versus why for an altruistic purpose. Again, knowledge managers are comfortable with the altruistic purpose of a community, of innovation, of knowledge sharing, of wisdom in crowds or similar such purposes. That leads me to think the why part of the equation is a red sea muddled with points and counter points, but the how part of collaboration is open for intervention.

Collaborate with its original meaning, “to work with” has to be delineated further. “Work” today is non-linear than what it used to be (even 5 years back) and “with” is very disjointed as well.

Continuity typically is on a work item (e.g. system requirement or issue). To achieve continuity within groups there has to be an overlap of function (e.g. development), identity, effort (e.g. of coding), space (a physical space, a code base). Work in Progress items are more suited for continuity, e.g. developers working together on a release (10.3.4 or R14) or version, talk abstracted or abbreviated language among them that lends continuity. End-products are not given much prominence for example the specification itself or any of the process documentation created during the process.

Coordination is for actions done by individuals in a specific time and space (e.g. check *.ini before service start up, capture log immediately after error, build after check in from all developers is complete). Within groups most understand the rules or rituals and follow them, usually there is not much to intervene here. If the number of people that need to be coordinating increases then a linear sequence with fall backs and alternate paths are developed usually by managers. That flowchart is presented in review meetings with no relevance to actual developers. I find Paul Graham’s maker manager distinction very relevant here.

Communication is often a channel decision, and people choose channels that they are most comfortable.

As in managers email, developers list, clients chat or instant message, friends SMS, and family calls

Channel is a tough choice to make specifically because

· enterprise software are aged and fragmented,

· email inbox more and more looks like somebody else’s to do list,

· managers cannot control requirement change over chat messages,

· and documents never are updated

Rule of thumb that has worked for me is take work to a channel where all the parties are already present. If there is no channel, create one and allow free access.

Metrics around velocity or work, closeness of drop dead date, progress on work items, my items (both in and out), are all derivable from most systems. This I feel one of the basic reasons why basecamp succeeds.


· is meaning derived from the work,

· is making sense of where we are, and knowing where the effort is going,

· is relating to the bigger picture

This never comes from status meetings with a formatted ppt, most developers consider that meeting as a break and try to speak as less as possible and take back no action forget about coordinated actions. A concept map on the other hand provides a better way to look at things zoomed out or zoomed in, more clearly with relationships and dependencies.

Knowledge manager’s job gets interesting if more than one of these dimensions is handled. Just saying


Scenario based Expertise Transfer

Anecdotally had great ideas this month and a nice facilitation method for scenario based expertise transfer from the recent workshop with Klein and Lambe. I dig a little deeper to find the thesis of Neil Hintze who devised this technique and the basis and soundness did not surprise me. Then I created the attached template that can be used in the facilitation printed in booklet form. I feel the timeline/chronology representation of scenarios will suit in most cases. Thanks Shawn.

Scenario Based Training Klein Hintze.dotx


Experts, Novices and Assimilation | Onboarding using CDM

On-boarding, assimilation, norming are all just different names to the same problem that Cognitive Task Analysis terms as the Expert Novice Gap. In my industry this process of apprenticeship is seen as

1. A billing leakage, that is if I do not start billing the new support personnel as soon as possible I am losing billable hours

2. An additional problem, if elder/more experienced people are left to support results in reduced profitability (experience costs money)

3. A pain, as there is 25% attrition/retirement in the industry on average and makes the problem more substantive

This is a KM problem and needs attention as it affects business directly. If you are a KM Manager, really only skill that is needed is what Klein calls as "helping practitioners "tell stories"", not just any story but stories that uncover what makes an expert expert.

Stories are inherently emotional and deep domain. For KM Managers it is easy trap as it has most elements of distraction like conflicts, pressure, politics, a new language of the domain itself that we cannot fathom, among others. So when interviews or structured elicitation is done here is the recommendation on what to gather without getting distracted

1. Cues and patterns that experts see but novices don’t, I used to illustrate with the military story of counting tanks from Klein but over a period, these were replaced with real internal stories. For the practitioner to trust you, a minimum level of understanding the expert’s job is mandatory.

2. Heuristic is one of the major dimensions in the ASHEN framework where experts generally have a short (not necessarily safe) way to tackle a situation. If you cannot make the expert articulate the heuristic, even after conversion the captured knowledge will be vacant. But if you just have the experts rattle out heuristics, it is of no use either. The conditions/situation are more important than the captured heuristic.

3. Decisions made, in the typical heroes journey there is this increasing level of conflict making decisions harder. In experts’ life, this increasing level of conflict is prevalent and generally, they are very much aware of what the situation was and what forced them one way or other.

4. Anomalies in situations are the anti-climax type incidents, examples here may be limited in number but are very close to the heart for the expert, and they remember mostly why it is an anomaly. Even if this does not come out in a single interview, over a period this comes to surface.

Typical Critical Decision Method (CDM) involves 4 sweeps as below

1. Incident Identification

2. Timeline verification

3. Deepening

4. What if queries

Working Minds: A Practitioner’s Guide to Cognitive Task Analysis has excellent practice guidelines on how to do CDM and creating a record of the lived experience. What you get as output is not a Standard Operating Procedure, but actually a story of when a SOP will fail and what to do if an expert is not around.


100000 Man years of Experience Lost | Retiral Effect on SBI

Most PSUs (public sector units) in India report to market how much they provision for gratuity every year.

And gratuity is a simple calculation, viz. Gratuity = 15 / 26 X Number of years of experience X Base salary

With this we can calculate

Number of Man years (experience) lost for the year = ( Gratuity provision X 26 / 15 ) / average base salary

I did this for one of the largest PSUs of India namely State bank of India and here is what I got

Number of employees = 222933

Total Staff Cost = 14480 Cr

Provision for Gratuity = 1565 Cr

Provision for Pension = 2473 Cr

Average Salary = 0.0468 Cr (4.68 lakhs) (this number includes both base salary and other perquisites/bonuses)

Number of Man years (experience) lost for the year (min estimate) = ( 1565 X 26 / 15 ) /0.0468) = 57962 man years

Even if you consider double this average salary as Base salary this accounts for 26000 man years (experience) loss per year.

That is a significant level of experience to lose every year and seeing that provisions have increased by almost 40 times this issue will only get much worse going forward

That is one of the grandest problems of KM I have ever encountered

UPDATED: doubled average salary at retirement as it was more realistic



How to deal with Avoid Task and Seek Attention behaviours?

Below 2 behaviors are common in the workplace that is necessary for every change agent to understand. They are critical to every change and system roll out.

Task Avoidance Behavior

Task avoidance behavior manifests as excuses even when there is agreement that the system or change is a worthwhile thing to try. There are many games like the Yes, but… that makes it difficult to spark action. To work around this issue, what I do typically is keep collecting excuses, and for each of the excuses find what “the precious” is, it could be time, effort, attention, presence among many others and gift them free.

Attention Seeking Behavior

Attention seeking is not really a problem, but it requires significant effort usually in the form of habits to sustain action. Social media actions like "like", +1 or transactional superlatives like "awesome" or even a simple "pat on the back", “Bravo” are undervalued. So to sustain attention it is necessary to come up with ideas that are high pedestal and keep coming up with ideas for different actions. If the prize or attention is easily gamed then it diminishes in value and no longer encourages action. So here the change agents’ job is to come up with large number of ideas using simple techniques like Forced Association, on what is available and direct attention to the action and not the pedestal.


KM for Karnataka Power

I had the opportunity to face a bunch of engineers from Karnataka Power Corporation, which generates most of Karnataka’s power from thermal and hydro sources.

Engineers ranged from Executive category, senior, junior to assistants who are newly commissioned.

The challenges for my session were 2

1. Time given to me was 3 hours post lunch

2. My session was immediately after the regular SECI model dump by non-km practitioners

I used the following model to introduce methods that I have been using over the past 4 years.

Once the framework was clear, we took the most common problem that old systems that still operate always face.

“To repair or replace” and each group’s take on “how to reduce maintenance cost”.

Last part of my session was a regular Social Network Stimulation

Where KM ideas were solicited from the 3 teams, for convenience sake we formed groups on

1. idea collection (how will we know what ideas our fellow employees have on reducing maintenance cost),

2. group action (once we know the ideas, what do we do with them and how),

3. and management support (how can as management we sustain the first 2)

Group formation itself was across hierarchy, plants, departments and roles, so enough variety here.

This was followed by a few rounds of Ritual Dissent which everyone loved.

In the end 2 executive engineers took ownership of the ideas to take forward within their plants.

All in all a decent outcome for a slow afternoon…