I’ve just been reading Alan Skorkin’s and Mark Needham’s posts on the Dreyfus Model.

It’s curious to me that Alan says, “it does nothing to help us build experts from the more junior people on the team!” and Mark says “There seems to be potentially some conflict here with Marcus Buckingham’s idea of focusing on your strengths if our strengths aren’t aligned with the most important skills for software development.”

I’ve not grown experts – yet – but I believe I’ve managed to set people firmly on that path, and used the Dreyfus model to do it. Certainly, I’ve changed teams from novice and beginner up through to knowledgeable and competent, using the models as a roadmap. If it’s useful, I’d like to share some of the ways in which I apply the model which may be different to Alan and Mark’s techniques.

Junior people aren’t novices, and senior people aren’t competent.

Certainly not in everything, anyway. A junior person who’s joined a team as a software developer has probably got a great deal of knowledge about some facet of software development. Their best skill may not be in a technical practice! They may be fantastic facilitators, speed readers, domain experts, etc.

Equally, a senior developer requires different skills to a junior developer – and most of those extra skills aren’t technical. They need patience, the ability to pass on their knowledge, communication skills to find out about the big picture, time management skills, skills in giving feedback constructively (and receiving it!), and even a few skills which sit under my “coaching” models. A senior developer who’s technically brilliant may still be lousy at bringing that brilliance to a team. Mark pointed out, “It’s ok to be a novice at some things”. I’d go further, and say that this is the norm. One of my big weaknesses is estimation – I hate doing it, and am usually an outlier with no real reason – but at least I know, and can defer to my more skilled team-mates.

If we find the practices in which people are already competent we can add them to the model, giving them at least one point which allows them to say, “In this, I am successful.”

I’ve never coached anyone who didn’t turn out to be successful in at least one practice, so I haven’t needed to do this yet. People who aren’t successful in some respect tend not to get hired for that role.

Model with examples.

Think of the ways in which novices learn. Driving a car is a good example (of examples) for this. I am a novice; I use the gear, use the brake, use the steering wheel. I am taught the steps of moving off, parallel parking, emergency braking. I need more practice before I can even be a beginner.

As a beginner, I’ll be able to park without hitting the kerb, slow down gently at junctions, steer intuitively, drive at (legal) speed, etc. – but I won’t be able to do all of these, and only some of them will be intuitive.

As a competent driver, experts will agree that I am safe to drive independently.

As a knowledgeable driver, I will be able to have a new car. I will be less likely to have accidents. I will slow down near schools – not because I know I should, but because I instinctively recognise it as a dangerous area to be driving fast in. I will spot the idiot undertaking me on the motorway, and let them go past before pulling in. I will be at one with my car.

As an expert I will perform stunts, drive into the skid, evaluate different cars, judge others on their driving (impartially and accurately!), and do crazy things that most people don’t get to do, even if they are competent (and most people think they’re above average, even when they’ve forgotten most of the practices that allowed the expert to judge them as being successful – this is largely true of all skills, not just driving).

I can’t drive – I really am a novice. I can only model the skill of driving because I know a lot of drivers. See the stuff about GROW further down for how I’d go about coaching someone to learn to drive.

Play on people’s strengths.

There’s a reason you can’t grow a novice into an expert using the Dreyfus model. By the time we hit our professional environment, we’ve usually become at least competent in the practices in which we have the greatest interest – even if that’s nothing more than “I really like solving problems” or “I get computers”. I’ve just finished Malcolm Gladwell’s “Outliers” and found out about the 10,000 hour rule. I’m pretty sure I had 10,000 hours of problem solving under my belt by the time I graduated. Most developers are expert problem solvers (as long as the problems remain logical). Most of us are also competent programmers for small programs.

If you can find the skills in which people are already successful, you can use those to identify, and grow, related skills.

Someone who has taken up a practice but shown no real interest in progressing to the point of being independently successful is probably never going to be an expert. However, they may well become independently successful. Aim realistically.

After that, play on people’s strengths. I give numbers to the Dreyfus models, and let people sit halfway between them, so for me the most interesting numbers are 2.5 and 3.5 – beginning to experiencing some level of success, or successful and wanting more. These are the quick wins; the places in which people can grow swiftly from beginner to competent to knowledgeable practitioner.

I can tell .5s because they’re doing some of the things I see at the next level, but not all of them; usually in one context but not another. So, for instance, I met a manager today who’s great at motivating his people to deliver, but has never thought of motivating them to learn and improve themselves. I have no doubt that now he’s aware it’s important in a Lean environment, he’ll go ahead and make the right space and noise for them to do it, and get better at it over the next few months.

The numbers I love most to see are 4s – the knowledgeable practitioner. These are the people I use to spread expertise in the team. I know they’re not experts, but by the time they’ve spent a few years indulging in conversations and answering the questions for themselves as well as other people, they might well be.

Avoid the word “competent”.

You and I know what that word means, because we’re familiar with the Dreyfus model, and probably the model of conscious competence too. However, to someone who’s not into learning models, the word “competent” together with any insinuation of “you’re not” correlates with the words “incompetent” and “fired”. Making people scared tends to stop them from admitting to weaknesses and mistakes, which tends to stop them learning, and the word “competent” is scary.

I’ve replaced the word “competent” with “practitioner” in my models, and I tend to talk about being “independently successful”. That is, even as a novice or a beginner, you can be successful on a team where someone is around to catch your occasional mistakes or give you guidance to avoid them.

This helps coachees get away from worrying about addressing their weaknesses – which will develop with practice anyway, and with help from the rest of the team – and towards acknowledging their strengths.

Equally, concentrate on the people in the team who are ready to grow. They’ll help the others.

GROW them.

GROW stands for Goal, Reality, Options, Way Forward. I get the coachee to pick a couple of skills in which they want to improve (they’re rarely novice skills, which is fine by me). The conversations usually go something like this:

“So, you’re a 2.5 and you’d like to be a 3 – independently successful. Can you see yourself doing the things written here? Which ones do you think you might have problems with? Is it a matter of not knowing, or not understanding? Would you simply like to be more confident? Would you like to know which books cover this subject? Can you think of anyone else who’s better at this than you, who you could talk to and find out how they do it? Do you think it just needs more practice?”

We establish a goal, which means that the coachee visualises what it would be like if they were at the next level in that practice – how they might behave differently, or how they’ve seen other people behave that they’d like to emulate (look at NLP’s “well-formed outcomes” for really great ways of knowing whether you’ve achieved this). We then look at different options and resources for getting from the level they’re at, to the level at which they want to be. Then we agree to try something out, and revisit it a week or two later to see how it went.

Interestingly, the act of visualising the next level sometimes causes people to take on the different behaviour, which helps coachees to learn what happens when they try the new practices. If maintained for long enough it becomes a conscious habit; otherwise you’ll see that person revert under pressure. The behaviour of a manager under pressure tells me a lot about more about their ability to motivate people and provide realistic targets than their behaviour when things are going well! I also discuss with the coachees whether they’d revert or not; so far they’ve been honest enough to admit it if it’s true, and then we can find more appropriate options.

Look for years, not months.

Expertise does not happen overnight. There is no quick way to grow a novice into an expert (and you probably want to concentrate on a different, non-novice practice anyway). The 10,000 hour rule still applies – but we’re talking about experts, not practitioners. It’s perfectly OK for someone to be a well-rounded individual! On my own measurements of a Dreyfus Developer, the only skill I’m an expert in is BDD (and therefore its subset of TDD) – and only because I’ve spent just about every lunchtime, weekend and hour in the bar talking about it, practicing and teaching others for the last five years.

And I’m still learning about the practices which play into BDD, and how much fun you can have with it, and how it’s done in Ruby, and how it’s still evolving. Even expert skills can be broadened.

Applying the Dreyfus model is a skill.

Here are the “Applying Learning Models” models from my “Coaching Competencies”. They’re probably not accurate above the practitioner level, because I don’t really have access to any experts in this. I’m not an expert myself – just successful (and re-reading this post back to myself tells me I’ve learnt more since writing them; maybe I’m more than just successful now).

If you know better, please help me become an expert!

• Novice:
  • Knows what a successful user of a skill looks like
  • Encourages individuals to become practitioners
• Experienced Beginner:
  • Can articulate the difference between someone following novice steps and a successful practitioner
  • Has an awareness of the kind of practices which might lie beyond practitioner level
  • Understands that it is not always necessary to address a weakness in a skill or practice
  • Encourages individuals to identify and play on their strengths
• Practitioner:
  • Can look at a practitioner in a skill and identify steps which are suitable for novices
  • Can draw out past difficulties from practitioners and identify for novices who are gaining skill
  • Can draw out current issues from practitioners and identify knowledgeable and expert practices which address those issues
  • Can help individuals to measure their progress accurately by providing observed examples of their practices or antipatterns
  • Targets the expertise of an audience appropriately
• Knowledgeable:
  • Can examine an individual’s skill level and help them identify paths forward to the next level of skill
  • Fluidly tailors presentations or workshops to the expertise of the audience
  • In an audience of mixed expertise, calls out the level of expertise being addressed at any time
  • Can articulate the dangers of targeting novice practices as indicators of performance
• Expert:
  • In an audience of mixed expertise, provides a route map that celebrates the ongoing journeys of novices and beginners whilst providing practitioners and above with a route forward
  • Can map different learning models to each other.

Grow expertise using experts.

I’ve never taken anyone from novice to expert, but I’ve certainly coached them from experienced beginners to knowledgeable practitioners, and from competent practitioners to expert. I’m particularly proud of Andy and Antony’s expertise in BDD, Szczepan’s creation of Mockito, and certain team-leaders and technical experts who’ve gained coaching skills.

The thing is, I didn’t do all the work – they did it themselves. All I did was make a couple of remarks, point them at some resources, and allow others to do the same. And they weren’t exactly novices to start with. So, if you want to grow expertise in a team – use other people too. Be a coach, not a trainer.

(Thanks to Andy and Antony for teaching me the power of collaboration, Szczepan for prompting me to rewrite JBehave, and the team-leaders and technical experts for passing on leadership and technical expertise…. amongst other things. I’ve come to realise that successful coaching is rarely a one-way transaction, and often just a straight swap.)