What is expertise? How do you know when to promote someone? What’s the difference between a Mid-level and a Senior? All of these seem like they have subjective and vague answers but this article intends to provide tools for making these decisions explicit and consistent.
What is Expertise?
Elliot himself had helped eradicate one of the most famous misconceptions – the brutish stupidity of the gorilla. In their first descriptions, Savage and Wyman had written, “This animal exhibits a degree of intelligence inferior to that of the chimpanzee; this might be expected from its wider departure from the organization of the human subject.” Later observers saw the gorilla as “savage, morose, and brutal.” But now there was abundant evidence from field and laboratory studies that the gorilla was in many ways brighter than the chimpanzee.
“Congo”, Michael Chrichton
One thing to bear in mind when assessing expertise is how humans naturally measure intelligence in others: vocabulary.
This is a double-edged sword. The “gift of the gab” can sell sand to the Sheikhs but can also hide true cognitive depth. (I want to be clear here and say I know some outrageously smart people – mostly in sales – who can talk and talk but also back it up with some seriously deep intelligence, gift of the gab and intelligence are demonstrably compatible abilities).
What is Expertise? The best answer to this was given to me by my wife, a teacher of Physics: Bloom’s Taxonomy.
Bloom’s Taxonomy is used by teachers to objectively assess learning and development. One part of the taxonomy describes 6 stages of “the progression of understanding” in a subject:
Remembering
Bloom’s Taxonomy calls this “Knowledge”, this is the most basic level of expertise and generally means that someone can remember and regurgitate facts and concepts, even if they don’t really know what they mean.
“Someone told me my dessert will come with a spoon”
In a discipline like software engineering, this person could be a graduate, fresh out of University with lots of theoretical knowledge but little practical experience.
Understanding
“Comprehension”. This means you can describe a concept, recognise it when you see it, choose it from a list of different things. You can describe it to someone who doesn’t know about the concept.
“A spoon has a different shape to a fork. I saw one on the table.”
In the software engineering example, the person can identify different types of code (class, interface, configuration file) and could copy a simple application they have seen.
Applying
Someone can use the concept or thing to correctly perform a task or solve a new problem.
“I could use a spoon to eat my dessert without getting any on my hands. Let me show you how.”
The software engineer has been set loose on a project of their own, combining all their prior experience into working application.
Analyze
Starting to gain more thorough understanding and the differentiation between variations of a concept.
“A spoon has a scoop on one end attached to a long handle. You use it by holding the handle and scooping with the other.”
The software engineer is now interested in the non-functional aspects of their code – readability, testability, performance, memory usage, scalability, thread-safety.
Evaluate
By this point the person has gained enough understanding of the concept and has real-world experience of different flavours of a concept to provide actionable comparisons between them.
“The scoop part makes it most useful when picking up loose or liquid items. Its shape means it is not good for french fries, but it’s good for custard.”
By now the software engineer can examine the trade-offs of different approaches (one big app or break it into modules? Expose a REST API or XML-RPC? JSON for simplicity and reach, or XML with a schema-definition for validation, governance and compliance?)
Create
The individual has gained so much understanding about a concept or topic that they can create one from scratch, even substituting typical materials or methods to produce something novel but with the same attributes as the original.
“I was lost on a desert island, I carved a spoon out of driftwood.”
By now the software engineer can confidently create projects from scratch, pioneering the design and implementation of a new solution.
Creating a Career Framework based on Expertise
Once you know how to objectively assess expertise and competence, you can create career pathways and frameworks for teams and departments.
Fred George talks about a career structure he successfully introduced for developers while working at the Daily Mail.
The team structure is based on expertise in one or more areas. The organisation valued (and paid) competence in several technologies the same as mastery in one.
Mastery in one plus competence in several would grant you the title of Master Developer (they didn’t actually have any of these, it was aspirational).
This approach encourages the development of T-shaped people – those with breadth of understanding in many areas, and deep expertise in some. Senior Developers are I shaped, with deep understanding of one or two key areas. Systems Developers are “crossbar” shaped – they are generalists, jack of all trades but masters of none.
Tim Brown, CEO of world-leading design firm IDEO, only hires T-shaped people. If you need to operate constantly at the leading edge of collaborative industrial design then you hire from the creme de la creme. For most of us though, you need a variety of capabilities and mindsets.
In my next article I’ll explain in more detail why variety is important.