Experts and pseudo experts

Most of us take pride in our knowledge. We are knowledge workers after all. But let us face it, we can't know all there is to be known about all the topics that come up in our daily lives. This means that even when we are experts in our areas of choice, there are a vast number of allied and other topics where we know a lot less / next-to-nothing.

Yet, in our attempt to impress ourselves and those in front of us, we express opinions confidently; argue points with such assurance that belies the underlying assumptions, lack of research and our own uncertainty. I am not surprised that the more successful people practice this more often than others! So much so that it has become a deeply ingrained habit / sub conscious process; that the intent to mislead is subtly and deeply buried under our other personality traits.


It is logical then that we are not just one or the other. Rather, a combination of both aspects. In a small number of cases, we are indeed experts. In all others, we are pseudo experts because we convey the impression of expertise - often to the detriment of our clients.

Will it hurt us too badly if we place our assumptions and uncertainties on the table in a balanced way (yes, I believe balance is the key, despite its subjectivity) so that we don't engage in this professional deception? It does require conscious effort though.

It definitely won't hurt too if our clients are less bedazzled by our apparent technical brilliance; are able to distinguish between facts, analyses, opinions and well-spun fiction.

Of collaboration, communities and KM

I've been talking about collaboration culture quite often these days. I have also been vehemently opposing efforts to "overly structured" processes, "unnecessary" standards, as well as "rigid and detailed" work practices. Yet, as a probable sign of the whole universe plotting against me, every day I come across - an updated policy, one more framework, yet another standard, detailed process diagrams (of how a help desk employee must clean the handset, clear the throat and say hello in XML ...) and other provocations.

To be fair, all these reflect a strong desire to impose order. We have all been raised to "conform"; often brainwashed into thinking that the only alternative to order is chaos / anarchy. Too often we've been told that we must plan, plan well and execute those plans well. Deviations from the plans are undesirable and must be ruthlessly ironed out, we are told. If you are a software Project Manager from any top CMMI Level 5 company, you probably think "rework" is a bad word and that "customers must be punished for changing scope".  'nuff said. 

Let us all reconcile ourselves to this -- that the world does not fall apart in the absence of iron-clad process diagrams backed by your favorite BPEL-enabled workflow software. So let us resist that itch.

There is a time-and-place for clear definitions, policies and such. These are of good use in routine operational areas that have matured over the years. e.g, book-keeping, maintaining a cleaning-schedule for the toilets (alas, a much neglected area), etc. 

In contrast, take any area where "things haven't settled down" or there has been a recent development of new theory. new techniques etc.; and try to impose order. Such as emerging areas of eGovernance.

Why is this a problem? Let us see... "Order" presumes a coherent, predictable system. It presupposes planning and that available knowledge, when applied correctly will result in implementable plans with minimal surprises. Without going too deep into the Cynefin Framework or Clay Shirky's talk on Institutions vs Collaboration, or why Reference Class Problem is important, let me see if I can make some localized (to the context of Indian eGov) generalizations. Here is where I jump from an abortive start on a theoretical treatise to a prescription with nary a justification... but hey I never promised to write a whole book in a blog post. So there!

1. Don't try to bring order before even a minority have begun adoption. (e.g., cloud solutions, mobile services delivery gateways, use of social networks in government).

It seems that we are in a great hurry to prove to ourselves(!) that we are progressive and are on the leading edge of adoption of global best practices. Perhaps I too am guilty of this sometimes (OpenData, anyone?). 

2. Do try to help early adopters to succeed. One successful implementation is worth 100s of framework documents. One successful early adopter who is willing to teach two more is worth his/her weight in eGold.

3. If you think the stakeholders need guidance, give them that guidance. But do not mistake sending out a mandate (even if it is disguised as a guideline) document to giving guidance. Go out there, work with them (collaborate!) and help them build that success.

4. When you are reasonably sure that you've seen all scenarios, cut-down on all possible surprises and converted most variables into constants, then go ahead and issue policies, rules, guidelines, whatever.o

5. Codify knowledge. Build those KM Tools. However, do not think that codified knowledge alone will solve your knowledge sharing needs. Not by a far shot. In fact, assume that they will only work when tacit knowledge is being harnessed as a primary resource (in eGov) - and all your case studies / lessons-learned documents are being used in a supportive role.  

6. In order to succeed, build communities (not just portals, LOL; I mean people, esp., those that have similar interests a.k.a., SIGs, tribes?). Communities where people overcome their reticence to talk, where open dissension / debates are a way of life, where people exchange experiences and ideas freely. This unlocks tacit knowledge, gives "experts" a way to apply their experiences; to answer vexing reference class problems that no search engines of a KM repository can.

tacit knowledge hint: talk to me! :)