loading...
Cover image for Understanding The Hierarchy of Competence

Understanding The Hierarchy of Competence

kathryngrayson profile image Kathryn Grayson Nanz ・5 min read

I was once told that I'm not good at being bad at things, and that is absolutely true. There's nothing that frustrates me more than a steep learning curve. Logically, I know that failure is a part of growth; emotionally, I'm a perfectionist and I hate to fail.

This, obviously, is not the best trait to have in the field of front-end development, which is in a constant state of flux. There's always a new framework, language, or concept to learn (anyone else currently tackling CSS Grid?) – the challenge is exciting, but it's a double-edged sword. Constantly feeling like a beginner wears on you, and it becomes easy to make excuses for ourselves. "There's no real reason for me to learn this. It's just gonna be replaced by something else in a few years, anyway." One of the things that has most helped me in approaching this feeling of constant incompetence was learning more about learning itself – in this case, the Hierarchy of Competence.

The Hierarchy of Competence is a model, developed by Noel Burch in the 1970s, that attempts to explain the stages we go through as we learn a new skill. All of us go through these same general stages as we're learning, but we'll spend different amounts of time in them depending on a variety of factors: what similar experiences we already have, what learning method we're using, what teachers we have (or don't have), our available resources, etc.


Image credit via Creative Commons

Understanding this process and being able to place ourselves within it as we work to master new skills can offer a very helpful perspective when it feels as if we're making no progress at all. It's also great for times when we're the teacher – it helps us place the learner in their journey, understand what they're feeling, and make sure we're meeting them where they are.

Unconscious Incompetence

During this first stage, we know nothing – not even how much we do not know.

It's like when you're 15, about to get your learner's permit and watching your parents drive, saying to yourself "How hard could that really be?"

Without even the knowledge of scope, we are likely to make wild assumptions and draw incorrect conclusions. It's a state of ignorance – not meant in a cruel way, but in a literal one. We don't know because we can't know. We are unaware even of what we're lacking. This is the natural beginning stage of tackling any new language, concept, or skill, but it's especially difficult to confront when you're the one in the teaching position. The learner in this stage needs patience and simple explanations in plain, straightforward language. In many cases, this is where we, the developer, are meeting our clients.

Conscious Incompetence

In this stage, we've learned just enough to realize how much we don't know.

This is like your first few times behind the wheel: you read the driver's ed book, but it turns out actually driving the car is much more difficult than you anticipated. You're having a hard time remembering where all the controls are, there's a lot of sharp braking, and you just had a very close encounter with a mailbox. You finish each drive feeling exhausted, frustrated, and overwhelmed.

This is the infamous "knowing just enough to be dangerous" stage – we've gotten our feet wet and we have a loose grasp of the basics, but we're just not good at it yet. We know enough about how it's supposed to work to know that we're not doing it right. This is that stage where we copy/paste a lot from Stack Overflow and just kind of hope it works...somehow. Code is messy and repetitive, and it takes us ages to accomplish seemingly simple tasks. If we're going to give up and quit, this is where it will most likely happen – but if we can push through, we can make it to

Conscious Competence

In this stage, we've gained enough knowledge to be able to create something that works...but it's a bit messy, and it takes some effort on our end to make it happen.

You've passed the exam and have your license! You feel mostly comfortable on the road, but driving still takes a fair amount of concentration and effort. You keep the music volume low because it's distracting, and you still struggle during inclement weather. But the freedom is fantastic.

In this stage, you've mastered the basics and are able to execute higher-level exercises...with time, effort, and occasionally a little help. Your code may not be ideal, but everything is working and you're able to explain how and why. You know what's possible, but sometimes you have to Google how to do it. When someone asks if you can do this, though, you're willing to say "yes" without hesitation.

Unconscious Competence

This is the final stage of learning – mastery of the skill.

By now, driving has become truly second-nature. You don't have to think about signaling before changing lanes, you just do it automatically. Changing the music or holding a conversation while you drive is no longer challenging. You feel like you make your daily commute on autopilot most of the time.

In this last stage, we no longer have to consciously think about what we're doing – we've learned it so thoroughly, it's become completely natural. We no longer have to Google elements or commands we can't remember, and we're the ones answering the questions on Stack Overflow now. The longer we practice this skill, the more automatic it becomes – but usually, at this point, we'll be ready to seek out something new to challenge ourselves and the process will begin again.


Next time you're trying to explain a concept to a client or a junior dev who just isn't getting it, dammit, step back, take a deep breath, and refer to the Hierarchy of Competence. What they're going through is most likely just a normal part of learning, and if you can take an educated guess at the stage they're in, you'll be able to approach them with empathy and offer them more accurately tailored support. In the case of talking with our clients, we come across as infinitely more professional and experienced when we can offer explanations that make sense to them at their current level of understanding – without making them feel foolish or stupid. And when we are the learners, understanding the hierarchy can help us be more forgiving to ourselves and embrace the role of failure as a natural, unavoidable part of the process. In a field where we'll all be learning for the rest of our careers, taking a look at learning itself will always be well worth our time.

Posted on by:

Discussion

markdown guide
 

This was a really helpful read for me, thanks!

 

I'm missing the part how understending this helps to deal with "There's no real reason for me to learn this. It's just gonna be replaced by something else in a few years, anyway."

I think that the quoted statement is still true, regardless if you're aware of this hierarchy or not. Sadly, the JavaScript world is where you feel it the most these days and sometimes it's not even matter of years, but months.

For this concern I think that answer is recent post from Chris Dodds "Hype isn’t a use case".

Nevertheless, it's an interesting reading. It's fun to realize that this is how it usually happens for us. Thanks Kathryn :)

 

I'm missing the part how understending this helps to deal with "There's no real reason for me to
learn this. It's just gonna be replaced by something else in a few years, anyway."
I think that the quoted statement is still true, regardless if you're aware of this hierarchy or not.

Well, there is a problem with that statement.

Just because we think that something is a hype doesn't make that a truth. And while not learning something might seem like the better take in the short run (saved time), it may very well show off as the wrong decision in the hindsight.

The hierarchy could show us something about our assessment if a topic is worth learning it: that it is most likely wrong. I mean: how could we know? If we are not even aware about our deficits regarding the new topic, how could we possibly tell if that new thing is a hype or not?

Second to that I could imagine that learning about learning-related topics can help us being more open to new topics, since being more competent with learning itself might help reducing resistance to the not so comforting feeling at the beginning of learning something.

 

To me you likely have to learn continuously but you don't have to learn everything.

The learning can be accidental, because you had to do it anyway or it can be deliberate (you take a training on the topic and choose the technology on purpose for the next project).

And to me, if you are not doing it regulary for some time, you can't hope to get to the concious competance level on all aspects of that technique/framework/topic.

Even 1 or 2 pet project at home, a few dozen hours each of actual work is unlikely to be enough for most people.

To grow, the best seems to be to choose the projects/team/company that do what you are interrested in, with ideal people more experienced than you being able to help and guide you.

And you'll likely never be able to grow to the conscious competance or inconscious competance level for more than a few technos/topic/framework.

As such, it appear critical to me to choose wisely.

As such, it appear critical to me to choose wisely.

Yeah, I agree to this.

But we should not choose on base of wrong information, e.g. our assessment of a topic we not even learned enough about to have an informed opinion.

Otherwise I think that growing involves leaving our comfort zone some times. From this point of view, I'm not convinced of just using predominating interests as a guidance. Apart from that it is often helpful to know something about topics, even if we have not reached higher levels of competence.

Yep, that the issue. An unrelated but key aspect of being in the workplace for me is to define your strategy.

For example when I was youger I was on a quite nice project and after 1.5 year i got the impression I learned most of what there was to learn there. So I asked my boss to give me another mission.

I got one 3 week later, but it was much less interresing. Then later on I finally got hired by another company, but I had to work about 3 years for them to get really interresting projects, to give the time for the managers to trust me.

The thing is, I think that I have learned significantly from the changing projects, using different technologies etc anyway. And it was necessary.

But on the other side, I can't help but say you have to always be on a great project in the company. They kind of project that are interresting to work on, that has visibility in the company, that could be nice on your CV and that is well managed (nice team, nice managers and so on).

So I'll avoid changing if I am currently on a great project in a great team because I'll always learn and have pleasuring experience every days. If I am thinking to change, I'll try to get max information on what to do next before commiting...

I have seen to many nice colleagues that were not happy, asked to changed, got a change and got worse team/manager etc that don't even want to let them go after 1-2 years.

In a sense, it is expected. The bad managers/teams have high turnover because everybody want to leave them. So that were you have the most "opportunities" in the company while people working on a nice project/team tend to stay and people just arround try to get a place there without the position being advertised.

This, obviously isn't the only strategy I guess. You may want to be recognized for being able to do the boring job that has to be done and so on. I know a guy that did the boring job for 2 years and now if offered a management role... But one has to clear on his strategy.

 

Very valid point – one that probably deserves it's OWN blog post, haha!

In my opinion, the higher-level concepts and general knowledge that I've learned in the process of picking up new frameworks, etc. have generally outlived the actual usefulness of the new thing itself. For example: I recently spent quite a bit of time mastering the charts.js library for one specific client project that required 70+ immensely detailed and customizable charts. Will I ever need to use all that charts.js-specific knowledge again? Maybe, maybe not (hopefully not, honestly – 70 charts was a pain in the ass). But I improved my JS skills overall by nature of having to learn, troubleshoot, and customize / tweak in that library for my client's specific needs. So, I try not to think of it as a waste of time if I learn a library or framework that I don't end up using again, but rather a chance to improve my job skills in a more general way.

I've read "Hype isn't a use case" and I agree with it, actually – but in this case, I think there's a difference between learning something (on a personal level) vs. choosing to implement that thing in a team environment for a project that will need to be maintained.

 

(...) but in this case, I think there's a difference between learning something (on a personal
level) vs. choosing to implement that thing in a team environment for a project that will need
to be maintained.

Yep.

I agree with that and I think the author of the article does, too. He even says that people shall "keep pushing forward and learning". Kinda makes sense to me: How is one supposed to pick the right tool if he never (at least) held the wrong tool in his hands?

 
 

You beat me to it. I was gonna post this video which touches on Dreyfus squared.

Patterns of Effective Teams - Dan North

 

Very cool – I wasn't familiar with this one! I'll have to do a little more reading on it. Thanks :)

 

This is interresting, in particular the part when discussing with other you can better adapt if you understand their level and find the right words for them.

This is actually useful in many situations, with client, but also with the boss, colleagues, the expert... Being aware of where you are and the other are is key.

Thanks for that!

 

Kathryn Grayson Nanz What drives you to write this? What is your intention? Be specific please. Is it the desire to help others on their way? Are you writing here to build a portfolio and did you read a self help book about encouraging optimism? Does it just feel nice to share with others? What do you ultimately get out of sharing your personal addition to the competence list with the rest of the world? why does this matter? Do you give a !@#$ if you get many likes on this? Do you seek additional insight from comments? Why did you write this? I am interested to learn this.

My experience is a completely different namespace and to a developer like myself the things you write are qualitatively 2 heart votes, a thinking vote and a nyan cat vote but utterly meaningless to me. However I also have this property that drives me to write posts completely different than this but in completely the same way as this for maybe completely the same reason.

 

In general, I blog for a combination of reasons, some of which you mentioned: to build a portfolio, to chronicle my learnings, to network. But mostly it's to share things I've found valuable in my own career, in the hopes that they're read by people who might not have heard them before and who will benefit from them. I'm self-taught, and there are many things that I only learned from some blogger on the internet – if I can pay it forward by being that blogger for someone else, that would be wonderful.

As for the likes and comments: I use them as a litmus test as to how much the topic resounded with others – a type of analytics. Some topics will naturally be more popular than others, and it's interesting to see which ones. But beyond that, no, I'm not personally invested and I don't derive any amount of self-worth from the number of likes.

Often I learn new things from the comments that are left (like one here that introduced me to another learning model, which was very interesting) – I enjoy being able to discuss the topics with the readers. If just one person leaves a comment that says something like "Thank you, I never knew about this and it's changed the way I think about it!" then the post is a wild success. It doesn't have to sway a crowd, but if it hits home for one person and makes a difference in their career, then it was worth writing.

Frankly, I don't much care that this is "utterly meaningless" to you – although it does make me wonder why you bothered leaving this comment. Do you make all the authors of the blogs you read defend why their posts "matter" or ask them why they "give a !@#$"? Or, was I just lucky? Be specific please.

 
 

Aristotle:I know I know nothing. Where does he lie? Informative write up.