Declarative Knowledge vs Procedural Knowledge

For a course in my final semester, I am (re-) reading Telling Ain't Training (2011). I was lucky enough to attend a seminar by the authors, Harold Stolovitch and Erica Keeps, for my company back in 2016, and it was every bit as engaging as one might expect.

One of the things I'm finding as I read the book more closely is that a lot of the concepts I've learned over the past year and a half have found their way into the material. That part isn't surprising, but what is surprising to me is how much of the book resonates with me this time around.

This week's reading was chapter 4, discussing declarative knowledge and procedural knowledge, and why being aware of the differences is important from a training or educational perspective.

Declarative Knowledge:

- Name things, ie, what is the capital of France?

- Explain or talk specifically about subjects, ie, explain the causes of World War II

Procedural Knowledge:

- Act or do things, ie, riding a bicycle

- Perform specific tasks, ie, navigate a database

The chapter talks about one of the challenges that companies run into with training, that of getting experts to teach novices how to do something. One of the problems with that is that experts become experts because of practice and experience, and often have trouble translating that information to novices in a way that makes sense. They are trying to use procedural knowledge to describe the declarative knowledge that new learners need in order to perform a task.

This quote sums up the issue with that fairly well:

Given my previous experience in technical support, I can see how that makes a lot of sense. With enough time, practice, and product experience in technical support, it's easy to be able to answer a majority of questions that come your way. I had a boss once who talked about four quadrants of competency: unconsciously incompetent, consciously incompetent, consciously competent, and unconsciously competent. [Edited later to add, this came from management trainer Martin Broadwell; website cited below.] The way he explained it was as follows:

Unconsciously incompetent: We are unconscious of just how much we don't know about what we're doing. This is typically the first stage of someone coming into a job in technical support.

Consciously incompetent: We are well aware of just how much we don't know. Tasks take a long time, because we have to research and double check and talk to colleagues to be sure we have the right answer.

Consciously competent: We've gained enough knowledge to be somewhat comfortable with what we're doing. It still takes some time, but we know where we need to look in order to get answers, and we can rely on ourselves rather than relying on others.

Unconsciously competent: We're so experienced in our job/task that we know nearly every facet of what we're doing. We can easily answer every question posted to us, and I can just do my job without having to think about it.

To take this back to Stolovitch and Keeps, having a subject matter expert, someone who is unconsciously competent and very adept at their procedural knowledge, try to train novices, those who are unconsciously incompetent or perhaps consciously incompetent and in need of declarative knowledge, can end up being very challenging. The experts make those logical leaps I've talked about in previous blog posts, zooming from A straight to M, leaping forward to Z, all because of those shortcuts that are completely second nature. This leaves the novices far behind, because they simply don't understand (yet) how to get from A to Z without going through the whole alphabet first (so to speak).

It's a great reminder for any subject matter expert who creates any kind of training. It can be very difficult to put oneself back in that position of being a complete novice, but in order to make the most effective training possible, it's worth a try. It would certainly help, too, to get the novices, or at least someone who is perhaps in that consciously incompetent phase, to help ensure that training is as effective for learners as possible.

References:

Broadwell, M.M. (1969, February 20). Teaching for learning (XVI). Retrieved from http://www.wordsfitlyspoken.org/gospel_guardian/v20/v20n41p1-3a.html

Stolovitch, H.D., Rosenberg, M.J, & Keeps, E.J. (2011). Telling ain't training. Alexandria, VA: ASTD Press

Image retrieved from https://examinedexistence.com/the-four-states-of-competence-explained/