Individual expertise and team balance
Plus ça change, plus c’est la même chose.
In last week’s look at progression frameworks, I made the point that it’s easy to imagine that they are a new phenomenon. But skill acquisition and progression in software development has been a hot topic for many years.
For example, check out this article from over 20 years ago: The Seven Stages of Expertise in Software Engineering by Meilir Page-Jones.
The author was a successful consultant at the time, training teams in software development practices. They had noticed that there was a high rate of attrition. Teams were not maintaining the practices they taught.
They identified several factors in this, e.g.:
- unrealistic management expectations
- a lack of commitment to quality
- an obsession with coding (from management - AKA if they ain’t codin’ they ain’t workin’)
- pernicious deadlines
- misallocation of skills to tasks
- engineers’ resistance to change
- engineers’ reluctance to participate in team approaches
- unavailability of CASE* tools
Plus ça change…
But the most important factor, argues Page-Jones, was the distribution and progression of expertise in the team.
Page-Jones’ suggests seven stages of expertise, loosely based on the Dreyfus model of skill acquisition, but with a couple of extra stages pinned on either end:
- Innocent
- Exposed
- Apprentice
- Practitioner
- Journeyman
- Master
- Researcher
Check out the article for an explanation of these stages in terms of both bear hunting (!) and software development. Those descriptions read a lot like many of the expectations set down in today’s progression frameworks.
The point with any model like this is not really how accurate it is, but how useful it is. In reality, progression doesn’t proceed in stages. There is rarely a big leap from one to the next, followed by years of stasis and then another big jump. It’s a utilitarian model, not a reflection of the true nature of expertise.
While I have some reservations about it, I find this model at least more useful than your basic split between “junior developer”, “developer” and “senior developer”, which say nothing about the expectations of expertise or behaviour.
Some of the final recommendations in the article are interesting, and still very much relevant to today’s web-based software development in an agile context.
In particular, having an understanding of individuals’ stages of expertise allows decisions to be made about balance in your team or teams.
For example, there is a stark warning about populating a whole team solely with newly-minted apprentices (the ‘sheep dip approach’). This is something I see increasingly often as demand in software development skills is addressed through populating teams with code school graduates, without more experienced people to guide them.
The author (and I) recommends cultivating and jealously guarding developers at later stages and helping them to spend as much time teaching and mentoring as possible.
What’s the balance of expertise on your team? Is it healthy or lacking? What can you do about improving it?
All the best,
– Jim
* CASE = Computer-Aided Software Engineering. An old term which is really just a catch-all for any tool involved in the software development process. Project management tools, IDEs, automated testing, etc, etc.
