The Four Stages of Learning

Those who can't teach, mentor...

I've found many parallels with the four stages of learning in software development, from how a developer's approach to design changes to how agile teams eventually become self-organising (eg, Scrum's "readiness levels"). By understanding where someone is on their path to becoming truly good at something you can be more effective in mentoring them to the next level - rather than assuming you can fast-track them right to the top.

There are other classifications of people's abilities and how they learn. The Dreyfus Model, for example, lists five levels (Novice, Advanced Beginner, Competent, Proficient, Expert). Understanding one of these models is a useful skill, especially if you can use it to adapt your teaching or mentoring style.

Unconscious incompetence

In the first stage of learning you don't know you're no good - ignorance is bliss! Sometimes this comes from simply having preconceptions about how easy a task is and sometimes it comes from not knowing there's a better way. Dysfunctional teams and developers are often unaware of what they're doing wrong, even if it becomes obvious when scrutinised.

It may be hard to mentor unconscious incompetents as they don't think they need to learn anything. A more formal, indoctrination-style, approach might be appropriate.

Conscious incompetence

The second stage of learning is the tricky one as it starts to dawn that you're not actually all that good! At this stage, teams and developers need a lot of support to prevent them wallowing in despair and to help them select and adopt new techniques.

Conscious competence

In the third stage of learning you're consciously applying the techniques you need in order to be "good". Here teams and developers know what they should be doing but need their momentum to be maintained, often by external encouragement and review.

Unconscious competence

At the fourth stage of learning you're naturally doing things right. The investment in mentoring and training is paying off here, but this can lead to risks, particularly a lack of thought and communication.

Architects are typically highly-skilled, often naturally adept in their domain - they're often at the unconscious competence stage of software design. This is not without its problems, though, as there is an element of truth in the saying, "those who can't, teach". Perhaps it's more diplomatic to say, "those who can, can't teach"? People who are naturally talented often struggle to explain how they do what they do. My wife, a teacher, often jokes that I couldn't teach her maths classes despite being more adept at the subject. She's right - I can't even tell her how I add two numbers in my head (I can, by the way).

In more subjective domains, such as the arts, an unconscious competent may never be able to teach someone who is not also naturally talented. Software design is not a totally rigorous discipline and perhaps the trend for "good taste in design" edges into the artistic skills? Should we expect to be able to teach these things? Should we expect someone to develop a style that we'd consider good taste?

If I think about the people I've learnt the most from, their skills have never seemed unattainable yet, on reflection, they were probably more adept than the self-proclaimed "gurus" who often rely on intellectual violence.

Somehow you need to analyse your own actions, essentially acting like a conscious competent. Rather than trying to force something into the mentee's subconscious, try to bring discussions to their level so they can understand it in their own way. By mentoring you are pairing with someone - you can supply the competence, they can supply the consciousness.

About the author

Kevin has been working with Java for 10 years, in defence research through dot com to investment banking. Currently he works at JPMorgan developing front-office trading solutions.

While getting on well with server-side Java, Kevin's also a keen Swing developer (and possibly masochist).

E-mail : kevin.seal at

Re: The Four Stages of Learning

Of course, a good mentor does not need to be compentent in the same skill as the mentee: John Whitmore's coaching philosphy argues that a mentor's primary goals are to raise awareness and responsibility in the mentee, not transfer any "domain" knowledge. I've read one of his examples of skiing coaches getting better tennis performance from tennis students than tennis coaches, due to their focus on coaching rather than demonstrating (although, if I had an architectural problem to solve, I'm not sure I'd want a skiing coach to help me out with it!).

The transformation from unconcious competence, to good mentoring, is hard -- time and time again I see excellent technologists being hopeless teachers.

In financial services this problem is especially acute as often there are areas of the business of which a new joiner has absolutely no knowledge whatsoever. This is unlike many other complex industries, e.g. aviation, where a new joiner at least has an idea of what a plane is and how airlines make their money. However, when trying to describe the simplest aspects of a trading system, for example, I rapidly find myself having to clarify jargon when I realise words like position and counterparty aren't understood. In the process of explaining those, I realise that words like bond and equity aren't understood. When bringing someone up to speed often large swathes of the business need to be covered before the technology gets a look-in, and it's often down to senior technologists to do the teaching.

The self-analysis you mention is vital. It's highly frustrating, when I'm the new joiner, when the person doing the explaining doesn't realise how much of his or her knowledge is industry- or even project-specific. In these instances it's important for me to really assert the consciousness, as you put it. People in the unconscious competence phase, after a while forget when they learnt their skills, and often need to be reminded exactly where the limits of us lesser mortals lie. When the mentor is a bad teacher, the student has to be that much better a student to get the information out of the mentor at the most constructive level.

Re: The Four Stages of Learning

Whitmore's approach is interesting although reading through "Coaching for Performance" I didn't get the impression his coaches would fare well against even the simplest of domain-specific questions. "How do I impart topspin?" isn't well answered by, "which way is the ball spinning as it comes towards you?"

What Whitmore's doing is helping people maintain disciplines that they already know - reminding them to keep their eye on the ball. This strikes a chord with scrum masters putting people together that can help resolve issues and maintaining the momentum of daily stand-ups etc. The scrum master doesn't need to be the best techie on the team (indeed, this is often considered counter-productive).

Add a comment Send a TrackBack