Beware: broken metaphors ahead

— 4 minute read

If people need to build a mental model, one of the bricks they'll build them out of is metaphors. They help us bridge new concepts to pre-understood ones, and even physicalize abstract ideas. For a lot of people, they're so useful that they equivocate the terms mental model and metaphor as being the same thing, because they've built all the models they have from them.

Metaphors are popular because they can turbo-charge the speed at which we can come to understanding. Anyone who reads this can probably think of at least one 'ah-ha!' moment where a metaphor has helped them crack some new understanding into an otherwise impenetrable concept. If you can't, don't worry – I'm going to try to use one in this post.

Bad metaphors speed up misunderstanding

That acceleration can happen in either direction, both towards understanding and away from it. The difference is the quality of the metaphor, and how close the concepts contained within it map to whatever it's describing. But beyond misunderstanding the concept, a poor metaphor can also begin to infect related concepts. We have become predisposed to extrapolate the metaphor beyond its original use, leading us to view entire projects, organizations or even sectors through a fundamentally flawed lens.

In particular, I see this happening in software engineering. Some metaphors are so deeply baked into our understanding of a sector that we use them in our job titles. We have software developers and software architects, accepting and propagating the metaphor of construction, despite the reality that building buildings and software are fundamentally incompatible processes. As a result, companies still "architect" software in siloed environments, passing it off to a "developer" when the design is ready, and delivered to an "owner" – a model that results in glacially slow change in practice.

Alongside that is the metaphor of the factory floor, which we apply to concepts of developer efficiency and experience. This has real negative impacts on the flow of change, encouraging organizations to think of software as something that moves along an assembly line, with each team performing a specific task before passing it on to the next, and to see developers as fungible, interchangeable units within these teams. The contrast between that extrapolated metaphor, and a reality encouraging gelled, diverse, cross-functional teams working in streams couldn't be starker.

Finally, let's look at an example beyond software engineering. While working in outdoor education, it was difficult for me not to notice that the entire sector adopted the academic teaching metaphor. That led to unfortunate practices in the industry, like considering deviations from their lesson plan to be "negative", considering a limited space around them to be their "classroom", and treating outdoor journeys as structured learning experiences.

A metaphor for questioning metaphor

What can we do about it? Well, first, it's worth highlighting that you are both most at risk from, and most likely to accept failed metaphors when you are first building a mental model of something. That has two implications for us:

  1. When we are building mental models for ourselves, we should apply special scrutiny to the metaphors that we encounter
  2. When we are mentoring others toward understanding, we pay attention to the metaphors we use ourselves to avoid infecting others with inadequate ones

We should be cautious when the thing we are comparing a thing to has some level of prestige. This isn't always the case, but you'll notice that the examples I gave above are all examples of models that emerged in the infancy of a new sector that happens to compare themselves to an existing, respected profession. We tend to gravitate towards comparisons that we want, which can be distinct from what is.

That all sounds good, but how do we put this into practice? I figure this is as good a time as any to use my own metaphor:

Treat this like a road sign telling you to be aware of railroad crossings. Now you are aware of a risk, you can proceed as normal, but be vigilant when passing a metaphor, looking for issues or errors. You now know that a mistake around the hazard could derail you for some time.

And yes, you should also question that one.