A significant part of my job goes around answering the question, "How does one increase domain knowledge?"
There are no easy answers to this, but there is a short answer and that answer is experience. Now experience, does not mean standing the non-strikers end in a cricket match all day long- though that too is undoubtedly experience. Experience means, real, solid, experience of doing things. In short practice. There is no shortcut. Read that again. There is no shortcut except putting in real solid hours of practice.
Read this story of 2 pilots and how a simple error made things go catastrophically wrong. Reading through the entire thing will only make you realize that the pilots, a) disregarded some common protocol and b) substituted it with the wrong protocol and c) failed to identify checkpoints and take appropriate action. Why did that happen? Because, they were never exposed to a particular situation.
Now they are flying planes - that carry people - so their trainings are about the best in the world - all across. The last thing you want is planes dropping out of the sky. So, in general, they are trained to respond to particular situations in a particular way. They call it the checklist (do read Atul Gawandes, epic book, The Checklist Manifesto on the same topic).
How is all of this related to domain knowledge - which in my view is a much abused word in the IT, ITES, BPO and KPO industry today?
Every company head or business head or account manager wants the training team to deliver "domain knowledge".
Unfortunately, they cannot. But they wont admit in as many words and respond like governments do in disaster hit areas. They respond by airdropping trainings. Whoever grabs a package gets a bit of food. Unfortunately, that does not really solve their hunger problem. The airdropping helps you survive one more day - they need to be rescued out of the situation. In the same way, dropping trainings on people wont help them. They need to be "rescued" - and that means, offered means to get out - and that means practice. Wherever practice is encouraged, there you will see knowledge bloom.
You cannot have domain knowledge unless the employee has had sufficient practice. Which means, if you dont have simulators, sandboxes, jam sessions, "Olympics", that let people practice, watch themselves, talk about it, spar and learn, there is no way in hell they are going to know beyond the obvious routine mechanical things that are put on their plates.
Ask yourself this question. Are your employees getting 10,000 hours of practice doing real stuff that leads to domain knowledge?
There are no easy answers to this, but there is a short answer and that answer is experience. Now experience, does not mean standing the non-strikers end in a cricket match all day long- though that too is undoubtedly experience. Experience means, real, solid, experience of doing things. In short practice. There is no shortcut. Read that again. There is no shortcut except putting in real solid hours of practice.
Read this story of 2 pilots and how a simple error made things go catastrophically wrong. Reading through the entire thing will only make you realize that the pilots, a) disregarded some common protocol and b) substituted it with the wrong protocol and c) failed to identify checkpoints and take appropriate action. Why did that happen? Because, they were never exposed to a particular situation.
Now they are flying planes - that carry people - so their trainings are about the best in the world - all across. The last thing you want is planes dropping out of the sky. So, in general, they are trained to respond to particular situations in a particular way. They call it the checklist (do read Atul Gawandes, epic book, The Checklist Manifesto on the same topic).
How is all of this related to domain knowledge - which in my view is a much abused word in the IT, ITES, BPO and KPO industry today?
Every company head or business head or account manager wants the training team to deliver "domain knowledge".
Unfortunately, they cannot. But they wont admit in as many words and respond like governments do in disaster hit areas. They respond by airdropping trainings. Whoever grabs a package gets a bit of food. Unfortunately, that does not really solve their hunger problem. The airdropping helps you survive one more day - they need to be rescued out of the situation. In the same way, dropping trainings on people wont help them. They need to be "rescued" - and that means, offered means to get out - and that means practice. Wherever practice is encouraged, there you will see knowledge bloom.
You cannot have domain knowledge unless the employee has had sufficient practice. Which means, if you dont have simulators, sandboxes, jam sessions, "Olympics", that let people practice, watch themselves, talk about it, spar and learn, there is no way in hell they are going to know beyond the obvious routine mechanical things that are put on their plates.
Ask yourself this question. Are your employees getting 10,000 hours of practice doing real stuff that leads to domain knowledge?
Comments
Post a Comment
Be Civil. Make nice!