Recently I read an article that referenced The Four Stages of Competence, a learning model developed in the 1970’s by Noel Burch of Gordon Training International. The model is helpful for understanding the progression of learning as it applies to any skill–music, math, language, woodworking, skydiving, and yes, software.
The Four Stages of Competence are:
- Unconscious Incompetence – You don’t know what you don’t know.
- Conscious Incompetence – You have an awareness of concepts that exist and skills you need to learn, but you don’t know how the concepts work or how to perform the actions.
- Conscious Competence – You understand the concept or can perform the skill, but it takes a lot of effort.
- Unconscious Competence – You have fully internalized the concept or mastered the skills. You can call on them without thinking about it—it’s easy and natural.
This model of learning can be helpfully applied in many areas of software consulting. For example, it can be a great framework for mapping one’s progress in professional development or a software generalist’s depth of skill across different categories of expertise. By mapping your skill level using the four stages model, it’s possible to identify areas to focus professional development efforts: you might choose an area of conscious incompetence to master, or you may identify an area where you’re unconsciously incompetent and take your first steps towards competence.
This model is also a powerful tool for informing our interactions with others in our work, and that’s what I want to delve into more deeply with this post.
Reaching Unconscious Competence
As software consultants, every year we spend roughly 2,080 hours at work practicing our craft (and likely more after hours, too). Our field is highly specialized, with many complicated concepts, terms, and practices.
At the beginning of our careers, or when we start at a new company, there is often a period of “drinking from the firehose” as we learn about things like personas, story points, sprints, velocity, prototyping, TDD, pair programming, algorithms, data bindings, and more.
We start out with varying levels of incompetence, and quickly move from there to being consciously competent in some areas and unconsciously competent in others. Before long, concepts and phrases which were completely foreign to us are now a part of daily vocabulary and practice–they’ve become second nature. At this point, you are a highly competent maker.
The Danger Zone: Competence & Communication
Unconscious competence is a danger zone for consultants because when we forget how much we know, we neglect to explain things fully and clearly.
The overwhelming majority of our clients come to us from a place of unconscious incompetence when it comes to software development–that’s generally why they hire us. Some may have been a part of a software project before in their career, but most haven’t. They will have a lot to learn at the beginning of the project, much like you did when you started out learning your craft. While they (usually) aren’t looking to learn design or programming, there are some basic concepts they will need to understand along the way in order to participate in the project and make decisions about the product you are building together.
Therefore effective consultants must remember to watch out for clients’ areas of unconscious incompetence (they don’t know that they don’t know, after all) and provide information they need to understand the concepts at hand, before communication gaps occur. This is difficult, because it requires a certain level of self-awareness in you, the consultant. As it so happens, many areas where we are unconsciously competent—we do things without thinking, because we’ve done them so many times before, and it’s second nature—are exactly the areas where our clients are unconsciously incompetent. As the consultant, it’s on us to watch out for these danger zones.
I can share an example from experience. As a project lead starting a new project, during the kickoff and first couple of sprint review meetings, I described the agile process (scope measured in points-based estimates of relative difficulty) each time I shared our burn chart to track progress. But soon, I fell out of the habit of describing what we were looking at–I jumped right to the progress report, without a reminder of how we were tracking the progress. This led to my client asking, “What are points again? What do they mean”?
This is just one area–points-based estimates–that is a part of my daily life as a software consultant, but it’s a foreign concept to my client. The meaning of points-based estimates is easy to forget, when you only encounter the concept every two weeks during a sprint review meeting. Now I preface each progress report with a quick review of points-based estimates, until I know for sure that my client has understood and internalized the concept. I also make sure to include a quick review if somebody new is present for a meeting.
This is just one example of how concepts and terminology that we deal with every day in software (unconsciously competent) can be completely foreign to our clients and their users. There are countless other areas of design and development where this is also the case.
Communication within Teams
Another area where the unconscious-incompetent / unconscious-competent divide can pose challenges is in communication with colleagues. Experienced designers and developers can take for granted concepts and practices that inexperienced colleagues have never heard of or used. Designers may assume that a developer’s knowledge of user experience concepts goes deeper than it actually does, or a developer may assume a designer knows more about programming concepts than they actually do. This can lead to miscommunications about intended functionality, implementation strategy, or level of complexity, creating conflicts later on.
The key idea here, especially when discussing critical functionality or making key decisions, whether you’re working with clients or colleagues (or both in the same room), is to start from the basic concepts. Don’t make assumptions about the other person’s knowledge. Watch for areas where you are taking your own knowledge for granted. Spend time establishing a foundation of shared meaning, before diving deep into the issues at hand.
If you’re interested in reading more about the crossover of the Four Stages and software, Jared Spool of User Interface Engineering wrote The Flexibility of the Four Stages of Competence. In this article, he applies the model to design work and user goals.