This post was first published on Medium, 18/02/2020
Since publishing the introductory Maturity Mapping post, the idea of maturity, how we articulate it on the x axis and the fact that we call it that has been something we’ve wrestled with. In this post we’ll outline our current thoughts on why we’ve called the practice Maturity Mapping and we’ll cover the x axis in a later post.
The Mapping Part
So hopefully the mapping part is obvious. Maturity Mapping uses Wardley Maps. As Simon describes maps have 5 key properties:
- They are, obviously, visual.
- They present to the reader of the map the position of components. In the case of maturity mapping these components are social practices.
- They are anchored by a recognisable need.
- They present options for movement
- They represent a specific context. In the case of Maturity Mapping this could be the practices used by a team to develop a software product for a customer, eg server side build, testing, user research etc
Where we think Maturity Mapping and Wardley Mapping (currently) differ, when considering them both as social practices, is in their meaning. Wardley Mapping is used to develop strategy and has, as Marc wrote a bias toward material things. Maturity Mapping on the other hand has a bias towards competence and (among other things) helps you develop an awareness of how deliverable your strategy is. So hopefully that helps with the Mapping part.
The Maturity Part
We chose to use Maturity in the name after much discussion. We considered ideas like Fluency Mapping, Improvement Mapping and others. Practice Mapping, which has also been considered (and not yet fully discounted), is the one we feel most closely aligned to. However it doesn’t reflect one important purpose we are hoping to achieve. This exploration reflects our initial discomfort with using the word maturity. We feel this discomfort is reflected in our community, as some folks seem dissatisfied with the term and are searching for alternatives. John Cutler recently asked:
“Looking for alternatives to the words “mature” and “maturity” for teams/orgs, as it seems that better ones are out there:
Steve Smith has also shared his thoughts on the term as well:
“One of the reasons I dislike maturity models is the word “maturity” carries so many connotations about an individuals personal growth. Talk about team effectiveness, proficiency, etc. Don’t talk about maturity. And don’t use maturity models, they suck.”
And when Chris tweeted about his intention to write this post Michael Bolton replied
“I wince when I hear references to ‘maturity’ in this context.”
Working on another new @MaturityMapping post, working title:
What’s in a name? Why we call it Maturity Mapping
So what is it about this word that folks find dissatisfying or inappropriate for this context? Well we think the fact that maturity is often associated with a stage in development, and that when something or someone is considered mature they have reached the end, pinnacle or final stage of the development. When I think about it, I’m reminded of being a teenager, thinking I’m mature and capable but being told I’m not, or not quite yet. That’s not a pleasant feeling.
If we look for definitions and examples we find things like (many thanks Wikipedia)
- Brought to a state of complete readiness (a mature plan)
- Fully developed; grown up in terms of physical appearance, behaviour or thinking; ripe. (They. is quite mature for there age)
- In the context of film and television, Suitable for adults only, due to sexual themes, violence, etc. (mature content)
- To become mature or full-grown; to gain experience or wisdom with age.
In Biology, maturity means also that the organism has reached the developmental stage in which it can replicate. We think that is an interesting notion in regard to the maturity of practices.
What, in essence, we believe this is, is a judgement and most often this isn’t a judgement you make of yourself but an the opinion of others. Unless we seek it, I tend to think we find that unpalatable.
There is also the association with linear maturity models, where the models describe the stages of maturity. You can read more about our thoughts on maturity models here. TL:DR, they suck!. I wonder then if people’s displeasure with the use of maturity is subconsciously linked to their displeasure with maturity models or associated shaming experiences (e.g. “don’t behave so immaturely”). I know this is something I wrestled with. With regards to the previous point, the models themselves are placing a value judgment on your practices.
However not everyone seems so perturbed by the idea of maturity.
Lisa Angela replied to John’s tweet, quoted above with:
“In life, maturity implies learned proficiency and alignment on priorities to effectively contribute to society, but it doesn’t negate the becoming more mature, more refined, wiser. Same true here. A level where teams can consistently achieve desired outcomes but it’s not the end.”
There are a number of other replies to Johns’ question that suggest maturity is a continuum, that it expresses something holistic and complex. We can also conjure pictures in our mind of the wise
We’re comfortable with both sides of this argument, we can see and have experienced both the pros and cons. So back to the original question, why use it in the name?
Maturity Mapping doesn’t come with an associated definition of what it is to be mature at a specific practice. It doesn’t say what it means to be mature in the practice of driving or cooking or developing software. We use a set of guides, heuristics, to enable – and this is the crucial bit – the users of Maturity Mapping to determine for themselves how mature they believe they are at a particular practice within their particular context. With a map and movement options, contextualised by using Cynefin, users can then look to plot a direction that is appropriate for them in their context.
In case you hadn’t noticed, we have a deep dislike for maturity models, they are a complicated solution to a complex problem. But we believe, in order to try and make a dent, Maturity Mapping has to occupy the same semantic space (as Jabe or Greg put it) as maturity models. We need people and organisations to see our approach as a competitor to the traditional model approach. With that our working hypothesis is: by having a name that positions our work beside theirs, Maturity Mapping will be seen as an alternative way of meeting the needs of those who would have reached for a Maturity Model.
People’s models are anchored in specific terms. If we want to compete with context-free maturity models, then we have to use that term. The meaning of terms (and consequently how we model associated experiences) can change, especially through practice.
There is an anecdote about Peter Drucker that matters in this context. He observed that employees were often perceived by managers as a liability, almost as a necessary evil, and stand-out performers were seen as the exception to the rule. We had to accept having low-performers as a consequence of seeking and finding high-performers. He also noticed how employees only appeared in financial documents as a cost. Contrasting that, he noticed that some “inventory” was seen as assets (shown as having value on a balance sheet) and worth of investment and wanted managers to apply that thinking to people too. He then introduced the language of calling people resources in the hope it would shift the view of managers towards seeing people as assets to the business. We all know too well how this worked out. If the underlying thinking doesn’t change, changing the words/terms has no consequence, because the people who see employees as a liability will happily call them resources and still continue having dismissive models in mind. And if managers do not see the value of working with people, making them use a different term mainly spurs resentment. But if we can get people engaged in a contextualising practice, facilitating the engagement by using the terms they expect and use, we can (maybe) reshape their associated models.
We appreciate this won’t satisfy those with a deep disdain for, or discomfort with, the term maturity in this context or maturity models themselves but we least hope you’ll see that we’re on the same side here, even if our approach to tackling the problem is different.
This blog was co-written by Chris McDermott & Marc Burgauer