Going past capable to mastery
Started Mastery by Robert Greene this past week. My objective in reading this book was to develop a roadmap to continue my professional development. Despite being labeled the “Go to Guy for Knowledge and Research” by friend and colleague Sarah Moche (Microsoft Community Director) and Subject Matter Expert (SME) on numerous technology topics by others, I always feel I can learn and develop better skills in those areas or help others to do so.
What is Mastery?
I was happy to see Greene’s definition of mastery was similar to mine. When I was working on reengineering processes at IBM a decade ago this topic leant itself to a heated debate between several executives and I. The rating system for competencies had a fairly loose hierarchy of determining at what level one had achieved. The system at its core was not a problem with the exception of the fact that it contained no mechanism to judge application. The system had a scale of one to five with five at the highest level. However, demonstration of achievement at this level was not on the ability to apply the knowledge in a useful way or determine and resolve problems in the domain. It was all about demonstrating a good memory for facts, terms and professing expertise. Through such a mechanism one could delude oneself into believing competence as a brain surgeon because you read a book or as the commercial stated you stayed at a holiday inn.
To myself, mastery of some competency or skill goes beyond such a low bar. In order to demonstrate and thus prove mastery I believe that three components are needed; Knowledge, Skill, and Behavior:
- Knowledge, the ability to recall and use the appropriate information;
- Skill, the ability to perform using that knowledge (e.g., adding to numbers, hammering a nail, etc.);
- Behavior, the consistent application (usage) of that knowledge and skill to achieve an objective the competency is designed to assist in providing
Summary and Recommendation
Greene’s book covers these topics but not directly as stated above as well as strategies for pursing a path towards mastery of a domain. Executing on these strategies will not ensure mastery but will likely improve your probability of attaining such. Included in his book are topics similar to Gartner’s multiple intelligence theory and Kotter’s concepts on transformation and change on a personal level. Overall despite other critics on Amazon of the book being a rehash of his other books, I found it useful and informative. The text is rather long –300+ pages– and feel he could have covered the topics more concisely making it a better read. Even with those minor flaws I would give it a recommended read.
Why is Mastery Important
During reengineering activities of several of the business processes mentioned before, part of my usual approach is to perform an analysis of the existing processes. The equivalent to a product Failure Model Effect Criticality Analysis (FMECA). In that analysis I examine what the process is suppose to achieve, how it achieves results, what elements contribute or inhibit results, and how efficient and effective the entire “system” is. Often during examination I discover the processes are just fine, its the level of competency of the people using the processes and tools is at issue. In some cases this is an easy fix with some training [In today’s corporate ecosystem, this often becomes an issues as employers are less and willing to invest in training of employees, expect where compliance is involved]. And in others it requires determining whether to reorganize staff or restructure the processes and job aids to meet the current competency levels. In plain English; hire different people or reduce the skill and knowledge needed and reinforce compliance behaviors of people through creating more comprehensive computer driven processes.
This then becomes a strategy decision for Executive Management to make. Automating processes enables one to scale quicker, cheaper, ( typically at a cost of flexibility**) and retain knowledge assets easier as computer systems don’t walk out the door to your competitors. However, relying on automated systems has its liabilities also. The maxim “Computers make excellent slaves but poor masters” comes to mind. -In most cases in order to automate effectively you need to understand the domain you are automating. An executive placing his or her trust blindly into a computer system is placing both their career and potential freedom at risk today. SOX legislation does not give Executives an out for accountability because they used a computer system and EULA agreements are written such they hold harmless the software companies. Which falls back to why Executives, Board Members, and Investors should be looking to find and develop mastery in their employees (a cheap insurance policy when considered as insurance companies often due not cover negligence). Which based upon current ecosystem is exactly counter to what they are doing.
[ **The reason why people get so frustrated with telephone response systems. If the path to resolving your issues is not readily apparent…well you get the picture. Such conditions cause employees, management and work to enter into a death spiral: Employees work around the system in order to achieve their measurements and goals. This causes move issues elsewhere in the system. Which causes more management actions such as increasing collection metrics. This further reduces employee’s attention to the real process to enable gathering and “conditioning” reports to achieve measurements and goals. This continues until the impact of this death spiral shows up in the balance sheet. However, often it is hidden in a similar activity of “conditioning” project and financial reports for several quarters until the yearly close of the books require a full and complete accounting. ]