BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Better Best Practices

Posted by Dan North on Mar 11, 2008 |
Organisations often introduce Best Practices as part of a change program or quality initiative. These can take a number of forms, from "cook books" and cheat sheets to full-blown consultant-led methodologies, complete with the requisite auditing and accreditation.

This article introduces the Dreyfus learning model to challenge the strategy of naively applying Best Practices, and shows how they can not only fail to help, but even have a severe negative impact on your top performers.

The motivation for Best Practices

People implementing a business change program usually have good reasons for rolling out Best Practices across their organisation.

  • They ensure consistency. We are introducing [insert initiative] and we want to ensure that everyone goes about it the same way. We don't want to abandon people without offering them any direction and the alternative would be chaos.
  • They support learning. We are trying to get everyone up to speed on this new approach with the minimum of fuss, and having a standard set of well-structured material means people can see exactly what they have to do, and ideally how well they are adapting.
  • They help limit (potential) impact or damage. (Now we are starting to see their true colours.) In any organisation there's a bell curve of people's abilities, and we know that a small but significant number of people will be at the wrong end of it. Implementing this program badly could leave us exposed to significant financial or legal business risks, so we're going to need very clearly defined practices to protect ourselves. They are called Best Practices because they are tried and tested so I can be reasonably sure they are going to work.
  • They help to build a more mobile and flexible workforce. In these fast-moving times, projects can materialise or be cancelled almost overnight. People move between project teams, projects move between offices, countries or timezones. With all our people trained up to use the same Best Practices we - and they - have many more options in terms of career mobility. We call it "commoditising resources".
  • They allow us to enforce control. In a large, hierarchical organisation, this is the real crux of the matter. A division manager or vice president may well be responsible for thousands of people. The only way to provide accountability on that scale is to have a system of clearly-defined and strongly-enforced Best Practices.

In other words, best practices are used as a device to manage risk.

The nature of risk

Risk is an interesting phenomenon. In business terms, "risk" usually means the probability of things going wrong. We assign a likelihood (high, medium or low; percentage points; statistical quantiles) to various events we are concerned about.

But what is risk other than a formalisation of fear? We consider things we fear as risky, and similarly we are less concerned (i.e. associate less risk) with things we don't fear. In other words, with apologies to George Lucas:

  • Fear leads to Risk
  • Risk leads to Process
  • Process leads to Hate (and meetings, and Gantt charts)

Now fear comes in two flavours, namely rational and irrational. Rational fear is healthy and useful. Lions are bad. Fire is hot. Trucks hurt. This is fear based on good information, either wired in via evolution or learned through cultural or individual development.

Irrational fear is the source of prejudices, phobias and knee-jerk reactions. The earth is flat and you'll die if you go over the edge. Hanging up dead rats by their tails wards off the plague. Putting coconut shells on your ears makes the freight aeroplane appear.

The problem is that from the inside they both appear the same. The sense of fear of spiders is no less intense or real to an arachnophobe than the sense of fear of a lion.

At a basic level, most fear is irrational, especially in a business context. If a system is delivered late, in most cases no-one is actually going to die. You probably won't even risk injury or go hungry. At worst you might get a slightly critical review.

Pretty much all the software you are using in your everyday life - the office suite you use at work, the games console at home, the browser you are reading this article with - it's likely that all of these were delivered late. And not working properly. And there was a hotfix / service pack / automatic update that appeared a few days or weeks later to fix some glaring functional omission or security hole. Or it still hasn't appeared but your vendor is keeping you blissfully unaware of how exposed your phone/computer/console is right now.

Rational fear is good - it stops us getting killed. We should embrace it and cherish it as a guardian of our well-being. Irrational fear is just a drag, but fortunately we have a strategy for dealing with it:

Because irrational fear comes from ignorance, we can learn our way out of it!

Introducing the Dreyfus Model

In the late 1970s two brothers spent some time exploring the nature of learning. They were interested in the nascent discipline of Artificial Intelligence, and they wanted to program a computer to learn a non-trivial skill like playing chess. It turned out there was very little by way of established knowledge around learning, certainly nothing they could use as the basis for a computer program, so they set about researching the learning process themselves.

The result was the Dreyfus Model of Skills Acquisition, which describes how people go from being brand new at something to being able to do it quite literally without thinking.

There are many models of learning and acquiring skills, but there are a couple of things that makes the Dreyfus model stand out. Firstly, it is based on real evidence and experience, and has been proven to work. (It was used to great effect in the early 1980s when the US health service was facing a nursing crisis - http://tinyurl.com/32afwt) Secondly, it isn't just a passive observation of development. It also describes what people respond to at each stage and therefore how to help them grow.

When you start learning a new skill, you don't have any understanding of context yet so you require specific direction. In other words, you have no instinct and you have to be told what to do. As your contextual awareness increases, your need for direction diminishes. In fact you could consider the nurturing of this awareness as fundamental to skills acquisition.

The Dreyfus model divides the learning process into five distinct stages or levels:

A Novice needs detailed instructions - step-by-step recipes. Novices can't tell whether the instructions are working or not or which ones are important because they have no context to assess them against. Because of this the novice wants frequent quick wins and regular feedback. A good recipe book has plenty of pictures and lots of reassuring messages.

An Advanced Beginner is familiar with the basic steps - the individual tasks - and can put sequences of them together. The advanced beginner is still very much task-oriented rather than goal-oriented, but they are starting to get some perspective. This is the stage at which a learner is most dangerous - they know enough to think they know more, but not enough to keep themselves out of trouble! Toddlers are advanced beginners at lots of things. With experience, an advanced beginner becomes Competent. At the competent level they are goal-oriented - they can figure out a sequence of tasks to accomplish a goal. It might not be the best sequence, but it will usually work. Competent people like to be given a goal and then to be trusted to achieve it. Conversely you can upset a competent person by trying to give them detailed instructions - rather like back-seat driving.

Most people don't get beyond the competent level at most skills, even those they use in their everyday work. This is a basic human trait - we don't like to expend energy once we have achieved an outcome, and for most activities the outcome is simply getting the job done.

At the Proficient level solutions start to "just appear", usually fully-formed, in the person's mind. They have developed enough of an instinct to firstly pick out the salient details of a situation, and then to match them to their bank of prior experience. A proficient person wants to understand the wider context of their actions, and enjoys metaphor and maxims (and their counterpart in anti-patterns). They will still refer back to their rule-based training to verify their actions, but by this stage they are learning to trust their own judgement.

Where the progression from Novice to Competent is fairly linear, the transition to Proficient represents a step change. For a start, it has to be an active choice. You can become competent at something just by doing it enough times, but you have to want to become proficient.

As with the transition from competent to proficient, the transition to Expert is also non-linear. It may take many years of dedicated effort to become an expert in a particular discipline. These people work almost entirely from instinct, and are rarely wrong.

An expert lives in a world of ambiguity. She takes a pride in her ability and likes to calibrate and brush up on her skills by spending time with other experts. Interestingly, people at more junior levels tend to overstate their ability, and those at the higher levels are more modest.

When worlds collide

An unfortunate characteristic of an expert is that they are unable to explain their decision-making process. This makes sense when you consider they are operating on autopilot: the solution is being presented to them, fully-formed, by their unconscious. A professional tennis player just "knows" how to return a ball with a topspin. A professional musician sees their instrument as an extension of themselves rather than as a device they manipulate.

Remember that most people are advanced beginners or competent in most of the things they do, and this is also true in a professional context. This means an expert programmer - or tester or analyst - will have a boss who is at best competent and most likely an advanced beginner. (How many project managers do you know who were talented programmers until quite recently? The Dreyfus model applies to them too.)

These people are thinking in tasks, or at best in goals made up of an identifiable sequence of tasks. This frame of reference is not comfortable processing something like "I've been delivering applications for 15 years and I just know we shouldn't be using an ESB". (There's that word "just" again.) Of course the proficient or expert manager would be more than happy with that explanation, and in fact would actively seek out experts to provide them with the instinct-level solutions in the first place - and then vigorously defend their decisions.

Best Practices and the Dreyfus Model

Armed with our novice understanding of the Dreyfus model it's time to revisit the term Best Practices. What does the phrase even mean? Practices are things you do. They are specific behaviours and activities. They are prescriptive. "Best" is an absolute qualifier (as opposed to the conditional "better" or the more moderate "quite good"). It is context-independent and unambiguous. It is a declaration that there are no better practices than these ones.

So by this definition, Best Practices are a set of context-independent, unambiguous, prescriptive activities. They are the tasks that form the basis of task-based learning. So how do the different skill levels respond to a model like this?

Best practices help beginners

The novice needs best practices. They can't function without them. Practices show the way - the more detail the better.

The advanced beginner uses best practices. These help define the edges, the boundaries over which the advanced beginner will doubtless step in their error-prone journey towards competence.

The competent person defines best practices. Remember, they are goal oriented but still rely on sequences of steps to achieve those goals. They remember being an advanced beginner. They remember all the mistakes they made, and they want to protect the next generation of novices from themselves. More about this later.

Best practices constrain your top people

A proficient person refers back to best practices. They are learning to trust their instinct but their instinct isn't always enough. Best practices can be both a help and a hindrance at this stage. If your instinct is to do something off limits, you stop yourself out of a misplaced loyalty to the written rules.

Finally, the expert simply doesn't use best practices, because they don't use any practices at all! In fact the expert subverts best practices in order to get work done (or rather, subverts the policing processes that inevitably accompany best practices). Best practices are a necessary evil that must be lived with but should not be allowed to hold them back.

These last two levels, and especially the expert, can quickly come to resent practice-based initiatives, in exactly the same way that the competent person resents being given task-level detail. ("Put the red eight there, under the black nine, then you can free up that ace."). You aren't just back seat driving when you constrain an expert to rules, you are invalidating their hard-won instinct and intuition.

Best practices are driven from the centre

Most practice-based process initiatives come from competent-level people. I don't have any statistical evidence for this but I am convinced it is true. At the competent level, you believe that the mistakes you made at the lower levels must have been down to a lack of rigour or completeness in the description of the tasks you were taught. If we can only get the practices right, we can get people from novice to competent without all that wasteful stumbling through the advanced beginner stage. The competent person hasn't yet tasted proficiency at this skill (and remember, you start as a novice at everything, including learning about learning, and learning about teaching) so they have no reason - or evidence - to trust instinct or intuition. Whatever the experts are doing, it must be possible to decompose it to a set of repeatable practices - to "de-skill" it - so that our less skilled - and let's face it, less expensive - people can perform the same tasks.

We could have a small group of experts defining best practices from a Centre of Excellence or Best Practice Group, and we could roll these out across the enterprise.

In this context, "expert" doesn't mean expert in the Dreyfus sense, but someone who is very competent. There is an important distinction here. A computer such as IBM's Deep Blue that can beat a world grandmaster is not an expert. It is simply able to cover a vast amount of possible search space very quickly (The Deep Blue example is considered canonical because chess was the original problem the Dreyfus brothers chose to explore with artificial intelligence, and Deep Blue beating Garry Kasparov in 1997 was obviously a landmark event in computerised chess). In this sense it is very, very competent! Recent neurological studies showed that experts in a particular field don't process things faster than non-experts. Instead they process fewer things. There is less brain activity in an expert looking at the same problem as a non-expert. In other words they instinctively pare down the solution space and have a well-developed sense of which parts of it are most likely to yield results. (The chess computer example comes up a lot because that was the original problem the Dreyfus brothers chose to explore with artificial intelligence, and Deeper Blue beating Garry Kasparov ).

Better Best Practices

In the context of the Dreyfus model, we can start to establish a more suitable model for propagating knowledge without disempowering our experts - the very people who are the inspiration for the next generation of knowledge workers in your organisation.

Firstly you should provide context, both for the practice and the practitioner. You can describe the same principle from several angles and at different levels of abstraction depending on the Dreyfus level of your intended audience. One thing is for certain, you won't be able to speak to them all with a single definition of a practice.

Secondly, the practice should be descriptive rather than prescriptive. In other words describe the desired outcome and maybe illustrate several alternative ways to achieve it. For the novices it is helpful to identify a preferred one. Feeding the steering wheel hand-to-hand is a very safe way to steer a car. As a competent driver it might not be the most effective way to turn quickly while reverse parking, but they'll get to that later. What you don't want is to have your expert having to trade their instinct against possible repercussions right in the heat of a crisis when they most need their wits about them.

It should describe the pros and cons of the practice. I can't think of any practices that are all upside. There is a trade-off for most things. Again, your novices won't benefit much from this, but you are building in the wiggle room for your proficient and expert-level people to be able to perform whilst remaining inside "the rules".

Patterns as Best Practices

In fact, it seems the more you adapt a best practice to be applicable across the Dreyfus range, the more it starts to look like a pattern!

An Alexandrian pattern - named after the architect Christopher Alexander - describes a context, the various "forces" (external factors) it resolves and introduces, and typically several examples. In Alexandrian terms, patterns only work in conjunction with one another, creating a system of interacting forces that need to be balanced to create harmony.

Applying this philosophy to Best Practices would allow you develop a whole variety of interdependent, co-operating practices that the novice can use in a cookbook fashion, the intermediate levels can experiment with and the experts can argue over. In fact, the process of providing a context in the first place can be a very useful exercise in terms of identifying the value of a particular practice or set of practices.

Conclusion

People are risk averse. In layman's language that just means people have fear, and that's ok. For the things we should (rationally) fear, it is perfectly appropriate to want to assess the likelihood of encountering them, and to spend effort averting them.

Best practices are about providing guidelines for novices. People will make mistakes as they learn because making mistakes is learning! However tempting it seems, you can't sidestep the advanced beginner stage and go from novice to competent without ever stepping outside the lines. The human learning process simply doesn't work like that. Software development is a skill, whichever part of it you are involved in - as a programmer or tester, as an analyst or project manager - so the highest performers will work predominantly from instinct. It's a pretty good indication of their expertise if they are unable to explain their decisions. (Of course you shouldn't confuse this for a lack of basic communication skills!)

To create consistency across a multi-skilled organisation, Alexandrian patterns provide a much more workable strategy than the clear-cut absolutes of Best Practices.

In fact, the best Best Practices are neither Best nor Practices.

Acknowledgements

Former ThoughtWorks colleague Robin Gibson was the first person to introduce me to the Dreyfus model. PragDave Thomas gave an excellent talk at QCon 2007 about it which led me to Patricia Benner's book "From Novice to Expert", which is an informative and uplifting book full of anecdotes from the nursing profession. Michael Tiberg, the organiser of Øredev, kindly allowed me to do a talk at his conference and gave me Best Practices as a topic, which was the origin of this article. While I was there I got to spend time with Andy Hunt, whose wife seems to be responsible for introducing the software community to the Dreyfus model in the first place! Andy is currently working on a book that will feature the Dreyfus model heavily as well as lots of other goodness about how people think. And of course thanks to Niclas Nilsson for suggesting I should write this up and offering to publish it.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Great article by Pranab Ghosh

"Most people don't get beyond the competent level at most skills, even those they use in their everyday work. This is a basic human trait - we don't like to expend energy once we have achieved an outcome, and for most activities the outcome is simply getting the job done." -- How true and how sad.

I agree that transition to proficient and expert level is non linear in nature. Your thinking is guided more by intuition and whole solutions seem to appear out of nowhere, instead of being synthesized piece by piece.

Interesting perspective by Julian Browne

I think the article begins by highlighting one of the main culprits of best practice confusion: change programs and quality initiatives. I wouldn't agree that "most" fear in a business context is irrational - being fearful that you might lose market share, competitive edge, revenue, etc is pretty rational if you have competition (i.e. competition is a lion and not a spider), but the point that you can't stick a few consultants in a room to create a best-practice amulet that will save you is well made.

It's not just that mastering the techniques that keep you competitive have different facets depending on the level of expertise you have amassed (though that is undoubtedly true and well explained by the Dreyfus model) it's also that the good (not best) practises you might be missing will often require tailoring and adapting to any one organisation's own peculiar set-up. There's no objective best practice because nothing stands still long enough to claim the title. I don't include basic practices like decent source control or securing sensitive data in this - clearly that's something else - but organisation structuring, delivery methods, architecture and the like, always (IMO) benefit from more of an idiomatic and less of a boiler-plate approach.

Interesting by Richard Henderson

Nothing wrong with Dreyfus, except that it misses an important level, that of "guru" or teacher. That is someone who is not only an expert, but can communicate those skills to others.

An idiot-savant expert is useless outside a limited context.

Re: Interesting by Claude Vedovini

To me it looks like the most competent people are the "teachers".
I find it well explained in the post: to teach people (that are thus novices) you need to give them mostly best practices.
Context will come later when they start to be advanced beginners.

BTW not being able to explain your reasoning is not being an idiot-savant.
Experts do not "reason" so there's nothing to explain. They just see the solution.

And yes, being an expert is useless when it comes to explaining advanced beginners or competent people that their irrational fears have no point :)

A possible information overload? by Alberto Brandolini

Hi, interesting approach that gave me a twofold feeling: I instinctively tend to agree with what you said, and your article sounds like a good explanation about what I normally try to do as a trainer/mentor (by assessing that I don't know why I am obviously trying to pretend that I am an expert on the topic).
On the other hand, sometimes providing the whole lot of information from different angles is simply too much. Too much information might result in noise, at least for novices, or in a longer best practices document (thus more expensive, and statistically ... less read). Probably the optimal choice is to distill the knowledge, providing the smallest reasonable amount of information to novices, and more detailed guidance to advanced beginners and competent. Unfortunately, not all bosses are eager to pay for this multi-level fine-grained knowledge sharing. As it often happens, a trade-off will be necessary.

The alexandrian form is a nice way to propose this contextually-rich information. But many developers, when asked about the patterns can sketch the pattern, but not all of them remember the forces and the context that originates them.

best regards

Alberto

No Universal Best practices by Paul Oldfield

Where I work I have outlawed the term "Best Practice". I tell my teams that there are only Good Practices that may be best in specific contexts. This helps people on the road to expertise, because only at the earliest novice level do they follow any practice without thinking what they are doing, what the practice is intended to achieve, and whether it is the best way to achieve this aim. When anyone uses the term "Best Practice", they are in effect saying "Just do it, don't think about it". I ask, under what circumstances might this be a good approach? The answer I come up with is that it is good only where people can't, won't or shouldn't think about how they are doing their work. I don't want people who choose not to think. I give people the ability to think as soon as I can, so those that can't think soon become those who can think. I don't admit of any circumstance where the people shouldn't think - at least not in software development.

Patterns & Languages by Michael Hunger

Patterns capture the essence of a problem solution and its application in a certain context. So the tacit knowledge an expert owns is made visible, understandable and digestable.

It is all about the distribution and transfer of knowledge.

Alexander also pointed out, that a single pattern is useful in itself. But its place within a pattern language makes it much more powerful and valueable. So its not a single "Best Practice" that yields value but a language of patterns that support each other and work together to create paths through the decision spaces (i.e. design spaces in software development).

Back then he also made the important observation that someone who has truly understood the patterns and the language and incorporated them in his mental model, no longer needs the language, as he is already working outside the constraints such a language would impose. So thats what the expert is.

The power of (different) languages for capturing and communicating knowledge and solving problems was fortunately rediscovered by the mainstream software development. So we're nowadays able to choose from a plenthora of languages or even create and evolve our own - whichever is best fittet to our problem or solution domain.

Of course it is not as easy as prescribing single "Best Practices" to a patient. This gets much easier if teams (including other stakeholders like customers, operations, etc.) work together to discover the knowledge that exists about the problem they're facing.

And in finding the patterns and creating the language and communicating them they already created value for themselves and others.

Re: Interesting by Dan North

Hi Richard.

I agree that teaching is an important aspect, but I don't see it as an additional skill level. To me the various kinds of teaching - whether in a classroom, as a mentor, or as a coach embedded in a team - are skills in themselves that people can be more or less good at. And in fact the ability to learn is another skill which is often overlooked.

Re: A possible information overload? by Dan North

Probably the optimal choice is to distill the knowledge, providing the smallest reasonable amount of information to novices, and more detailed guidance to advanced beginners and competent.


I completely agree. The thing I find hardest with coaching is pitching the information at the right level. In particular there is the challenge of holding back on the "whole truth" to avoid overwhelming the poor advanced beginner. You know that what you're saying isn't correct, but it's good enough for now and it's exactly what the person will find most useful.

Even though I know the advanced beginner has to make mistakes in order to learn and progress, I still find myself wanting to protect them!

Re: Interesting by Richard Henderson

I kind of agree. Nevertheless, a "guru" is a rare beast, and therefore more valuable than an expert.

Dreyfus is talking about an individual activity. My (cynical ;)) take on "experts" is because programming is largely a social activity with extended impact. If someone can't explain why something is a good idea, then I will (and I do) reject their approach. Instinct is a highly contextual/historical process which is potentially disastrous in a risk averse environment.

That is not to take away from your thesis, which I think is correct. "Best" is a bad word. Nothing wrong with "standard" practice though, as a baseline for improvement. Also nothing wrong with breaking the rules if the benefit can be explicitly demonstrated.

Richard: Teaching is also a domain by Elizabeth Keogh

and I believe you can apply the Dreyfuss model to skill levels, too. Having worked with a number of other trainers and mentors now, I don't believe there's a "best practice" for teaching, either - it depends on what you're teaching, and who.

I'd define a guru as someone who really understands their domain and can pass that wisdom on - I would guess to people at all levels of experience. A teacher is often only one step ahead of the class, and doesn't have to be an expert. In my humble experience, some of the best teachers of beginners are those who've just learnt the skills themselves.

Re: No Universal Best practices by Dan North

There's a fantastic article by James Bach about exactly this. In particular his responses to some of the comments are lovely.

Re: Interesting by Chris Matts

I prefer the term "Someone who helps people learn... A learning option." Not sure if there is a word out there for it.

Guru is a title that is wrapped up in status of knowledge who lets out cryptic clues to those who follow. As such it goes against the humbleness aspect. A teacher controls the pace and direction of learning.

As someone who helps people learn I point out the start that I am there to learn how to help people learn. I am not there for the learner but myself. I am looking for new ways to help people learn. Therefore from my perspective, the most valuable people are those that do not understand and force me to understand the thing from another perspective. For me, the idiot savant is a great source of learning about learning.

Re: Interesting by Chris Matts

I disagree. Learners, and those who help people learn are not necessarily the same thing.

Learning organisation first? by Chris Matts

I would like to know whether you can implement this pattern movement from the bottom up or whether you need a learning organisation as a pre-requisite.

A couple of years ago I was lucky enough to work with someone who studied learning organisations as part of his MBA. He told me that the most important factor in determining the success of a learning organisation is the attitude and behaviour of management to failure.

Creating a pattern model for best practice will probably result in a few failures as the organisation learns. Is it a pre-requisite or could an org use patterns in a failure hostile organisation?

As a thought, is there a drefuss model for organisations?

Re: Richard: Teaching is also a domain by Naisheng Li

Fully agreed. When I do the training to others, I need to learn it in advance, sometimes, even during the training.

Broken URL by James Domingo

The URL (tinyurl.com/32afwt) in the third paragraph of the Introducing the Dreyfus Model section is broken. The page that it refers to at the Massachusetts General Hospital's web site is no longer available. A snapshot in October 2008 of that page is available at the Internet archive.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

17 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT