Skip to main content

Higher Order Thinking: Bloom’s Taxonomy

I came across Bloom's taxonomy of higher order thinking while listening to another Knowledge Project podcast episode Dr. Gio Valiante (Part 2): Failure and Success.

I found the concept intriguing, with reference to learning organizations and learning in organizations.

I made a little drawing to help me remember the hierarchy, and then did a bit of research on the topic based off the first Google search results for "Bloom’s taxonomy of higher-order thinking".


First thing to note is that this is Bloom's taxonomy of the Cognitive domain. The wikipedia page lists two additional taxonomies in the Affective and Psychomotor domains.

Other online resources about higher order thinking rename or reposition the last three levels, as shown in the bottom part of the drawing above.

How can I use this newly discovered information?

I guess really my question is: how can I use this newly discovered information?

And right now I am thinking at two ways:

  1. how can I index the hiring process towards higher order thinking
  2. how can I promote, encourage, develop this higher order thinking with the people that we already have

In the podcast episode Dr. Gio Valiante follows up to the introduction of Bloom's taxonomy with the following (emphasis mine):

You see, number one, believe it or not, is humility. The best in the world readily acknowledge that they don’t know. Now I’m not saying… So they’re humble, but there’s also a little arrogance. There’s conviction. There’s belief that “What I’m doing is right. I believe in my path.” But underneath that is the humility and the recognition that they don’t know, which is why the second step [is] a never-ending series of problem solving and testing and risk taking.

In my experience, I have to say that people that are not humble are generally the people that will have an unchangeable opinion about everything and will actively engage in conversations with the intent of winning them. Often, interactions with such people tend to be of the win-lose type.
For this I believe I do have already a system of screening candidates in the hiring process, and for those who are already with us the cultural conflict that will inevitable arise will take care of them anyways.

Conviction is more tricky though, as that IMHO sounds like the agency mentioned in the another KP episode. And my conclusion is that some people have agency and some don't and there's something we can do to promote agency, but ultimately the seed needs to be already there.

So, when it comes to agency I suppose my approach is to make space for people to grow. This can happen intentionally or as a side-effect.

Intentionally: in conversations, they express the desire to grow, and we agree on clearing a path for that.

Side-effect: I move out of a team, or shift my focus and leave an area open for the taking. I would usually announce this in some way or form, to make sure that it does not look like neglect (even though it might be neglect, and in practice it is a risk I'm willing to take).

Update: I came back to add the paragraph below after I listened to the episode again

Before mentioning Bloom's taxonomy, Dr. Valiante mentions "knowing when to quit". Perhaps this is key to finding people with high agency and who also have the judgement to understand when it's time to "quit". Note that quitting can mean many things, and not just leaving a position or job. For example, knowing when to quit can mean stopping an effort when are we getting diminishing returns, going back to the drawing board when we're not getting the intended outcome, understanding when the time is right and when it is not for a certain action.
Do you know when to quit? could be an interesting question to ask in an interview.

Last, but not least is the experimentation part and this is what I find it's harder to apply a process to (*). I'll think about it and maybe write about it another time.


(*) someone might suggest the Toyota Kata process

Comments

Popular posts from this blog

Mirth: recover space when mirthdb grows out of control

I was recently asked to recover a mirth instance whose embedded database had grown to fill all available space so this is just a note-to-self kind of post. Btw: the recovery, depending on db size and disk speed, is going to take long. The problem A 1.8 Mirth Connect instance was started, then forgotten (well neglected, actually). The user also forgot to setup pruning so the messages filled the embedded Derby database until it grew to fill all the available space on the disk. The SO is linux. The solution First of all: free some disk space so that the database can be started in embedded mode from the cli. You can also copy the whole mirth install to another server if you cannot free space. Depending on db size you will need a corresponding amount of space: in my case a 5GB db required around 2GB to start, process logs and then store the temp files during shrinking. Then open a shell as the user that mirth runs as (you're not running it as root, are you?) and cd in

From 0 to ZFS replication in 5m with syncoid

The ZFS filesystem has many features that once you try them you can never go back. One of the lesser known is probably the support for replicating a zfs filesystem by sending the changes over the network with zfs send/receive. Technically the filesystem changes don't even need to be sent over a network: you could as well dump them on a removable disk, then receive  from the same removable disk.

How to automatically import a ZFS pool built on top of iSCSI devices with systemd

When using ZFS on top of iSCSI devices one needs to deal with the fact that iSCSI devices usually appear late in the boot process. ZFS on the other hand is loaded early and the iSCSI devices are not present at the time ZFS scans available devices for pools to import. This means that not all ZFS pools might be imported after the system has completed boot, even if the underlying devices are present and functional. A quick and dirty solution would be to run  zpool import <poolname> after boot, either manually or from cron. A better, more elegant solution is instead to hook into systemd events and trigger zpool import as soon as the devices are created.