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 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!
- 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
- 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
- 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
- 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.)
It was really interesting reading about the model from someone who’s actually properly used it to teach people. I only think about it more randomly when assessing my level of skill so my experience is much narrower than yours.
One thing I’ve been trying to work out which maybe you know is how narrow a skillset would you find it useful to apply the model to?
For example a colleague and I were discussing how web servers work and in particular IIS and I realised that I know very little about the whole process.
I pretty much just follow a set of steps and if something goes wrong then I was completely stuck and didn’t know how to proceed.
From my understanding that’s how a Novice would act.
My colleague understood a bit more what was going on and asked me if I understand how it would work if we were working in Java land.
I knew that a bit better and we realised that there was quite a lot of overlap between the two which then made it much easier for me.
It doesn’t feel like what I’ve described is broad enough to be called a skill but it seems like there are differing levels of ability when working with web servers (for example) such that someone who was an expert would pretty much be able to solve any problem that might happen around that area whereas someone novice wouldn’t know what to do.
I like the idea of the .5’s that you described – that seems really useful for a continuous progression between the levels instead of it being purely discrete.
I still find it quite hard to assess my own skill level – I think this probably links to the fact that I’m not yet competent at using the Dreyfus model – although I find it easier to look at people who are better than me at a skill and through talking to them work out what areas I could get better at.
I really like this model – it seems to provide a way for you to internally measure your progress which I think is great.
Thanks for posting your thoughts.
Thanks for your comment on my blog, I thought I’d share my reply here as well.
Thanks for that great post, I found it extremely interesting and it has given me a lot to think about. Here are some of my immediate thoughts.
One of the consistent themes I am getting from your post is the fact that you’ve had the opportunity to work with and help grow the skills of some great individuals, they were driven and sufficiently self-starting to grow their skills in the first place. So, it all really starts and ends with the quality of the people you’re working with. You can help, guide and point but you can’t make people grow their skills. So, the types of people you work with really counts.
I really like how you basically propose that it is not just knowledge flowing downhill, you can get your beginners to push and prod the more experienced practitioners to become more expert, I think that is great. Although once again, the quality of the people is paramount in my opinion.
Here is another thought, coaching someone takes time and the ability to frequently re-examine and adjust your course. It would be tough if all you did was set some vague goals every 6 months and that’s all. It is almost like personal agility, you need to be able to retrospect and correct your course etc. It sounds to me like you’ve been able to do that with some people which is great. I do have to say that most teams find it really difficult to do this as it is a massive time commitment and would grow exponentially with the size of the team.
Those are some of my immediate thoughts, but you have given me much to mull over and I’ll let it bounce around my head for a while :). And on top of all that you’ve reminded me that I’ve been meaning to write up my thoughts on the stages of competence model as well (should probably do that before I forget again). Thanks for sharing.
All people are great individuals. More than anything, it’s about finding the right skills to be growing.
The weird thing is, everyone loves learning and improving themselves. Applying learned abstractions to different problems makes the brain produce all kinds of lovely chemicals. I usually find that anyone who’s got themselves into a rut has just forgotten how much fun it was, and it’s not so hard to lift them out.
There are occasional people who like their rut more than others. I let them be, and concentrate on the ones who are willing and have fun. Eventually the atmosphere of learning, the expectation of self-improvement and the buzz and transparency around it mean they either join in or leave.
So, grow the strongest skills and the strongest people, and the rest will take care of itself.
With regard to coaching and goals – I may ask for help occasionally from people that I think are really strong in a skill, but that’s a bit different to setting goals. You can’t set people’s goals for them. You can ask them what goals they have, and the models help them find areas they’d like to improve in, but it’s a pull rather than a push process. And, yes, both coach and coachee need to try things out and get feedback on whether it worked.
If you need to do this with exponential scaling, find people with coaching skills and grow those! I do this full-time now, and consider myself very lucky!
I wonder if someone more skilled with Web Servers than you are would find it even easier to pick up IIS? Some of my models talk about the ability to adapt a practice to a different context – usually in the knowledgeable space. If you’re finding that you can leverage some of your Java knowledge then probably you’re approaching that level.
I’ve recently started spotting the different levels of granularity within practices and am exploring this myself; your comments and posts also give me food for thought!
Pingback: A Dreyfus model for Agile adoption | Liz Keogh, lunivore
Pingback: Dreyfus Modelling | Liz Keogh, lunivore