I’m taking a Mac programming course this semester, and as I wade into the strange world of Objective-C and the Cocoa frameworks, I’ve been forcibly reminded of the Dreyfus Model of Skill Acquisition.
First proposed by Stuart and Hubert Dreyfus in 1980, the model suggests that people go through roughly five stages as they acquire new skills.
For anyone deliverings training, or peddling processes or methodologies or sets of best practices, the Dreyfus model has a number of important implications.
When learning something new, everyone starts out as a novice, no matter how much they know in other fields.
The goal of education should be to gradually move people up the scale, towards expertise. There is no way to do this overnight: it takes time.
The most training can do is provide the rules that will help people achieve novice status. Experience is required in order for people to move up the scale in the direction of expertise.
Note that, at lower levels on this scale, people only feel accountable for following the rules they’ve been given — not for the actual results achieved! While this is reasonable, this is one excellent reason why you want to move people up the scale as quickly as possible, especially in complex fields such as software development where simple rules are rarely sufficient to achieve success.
If you cannot create teams composed entirely of experts, then it is wise to have at least one expert on each team, and have them act as a lead who can mentor and oversee the work of others. And, of course, if such a lead is given sufficient authority and support, then they will feel a sense of accountability for the success of the team.
It is entirely possible for a novice to follow the rules they’ve been given and — when facing a complex problem, without help from an expert — to fail miserably. Note that, according to the model, such a person will feel no great discomfort, since they only felt accountable for following the rules, and not for the results. In fact, if their organizational environment allows this to happen, such a novice can have this experience repeatedly! However, it is not likely that a succession of such failures will help someone advance up the scale towards expertise very quickly, if at all.
At lower levels of this model, people want and need specific rules to follow. At higher levels, though, experts will have internalized such rules, will no longer need to refer to them in explicit written form, and will often bend or break those rules in response to the specifics of their situation. This is why it is often only the new guy who actually follows the letter of the law in terms of departmental procedures.
When the rules change, the experts will often give you the most trouble, because they will tend to assume that their tacit knowledge still applies, and will want to continue to operate at the level of expertise they have grown used to.
It is essential to provide written rules, since those at the lower level of this scale will be lost without them.
Beginners will often demand more and better rules since — from their perspective — that is all they have and, if they experience failure, they will tend to think that more and better rules are the answer. Beyond a certain point, though, additional and more complex rule sets provide rapidly diminishing returns and, in fact, may simply make it more difficult for novices to advance up the scale towards expertise, since all their efforts will go towards retaining some knowledge of the latest rules.
Your best, most valuable performers will be frustrated, and have their performance inhibited, by an organizational approach that is overly insistent on strict adherence to very detailed, prescriptive sets of rules.
The best rule makers tend to come from the middle of this scale, at the competent level. Those operating at the higher levels tend not to have enough awareness of the rules to be able to document them.
By the way, thanks to Dan North, who first made me aware of the Dreyfus model and some of its implications in the field of software development.
December 1, 2009
Next: Process QA