One of the things that I gave short shrift to in my talk at All Things Open was the idea of metaphors and how they relate to culture. Well, there were a few things I had to cut shorter than I’d like, but I’ve had a few chats about metaphors and language since then and decided to get something written up.
Metaphors, as direct comparison and symbolic representation, have a strong effect on the way we perceive objects and actions. Metaphors may be the only way we come to shared understandings on non-tangible cultural precepts like emotions or morals. The choices of our metaphors show us what is valued in an organization’s culture. Now, I’m not talking about “her eyes shone like the diamonds” or “you’re cold as ice” style of metaphor. So what sorts of metaphors are we talking about here?
Here’s some examples:
- “James just isn’t a team player.”
- “I haven’t seen that yet, can you ping it to me?”
- “We need all hands on deck for this outage!”
- “Sarah’s team is really firing on all cylinders this sprint!”
The metaphors of business and IT affect the way we see our jobs and our corporate cultures. These metaphors come from a wide variety of sources and have differing impacts. Sports metaphors can drive more team focus into an organization, but one that highly values competition. The mechanical metaphors can drive efficiency around goals, but cause an organization to be goal-bound and less adaptable. Biological metaphors can drive flexibility and cooperation, but cause an organization to be goal-less and less directed.
If we repeatedly hear our selves and roles referred to as “cogs in the machine”, our work characterized in “speeds and feeds”, or that upgrade “ran like clockwork” we begin to think about ourselves in those mechanical terms. Most businesses use these sorts of mechanical metaphors in one way or another. If we are measuring developer velocity, we are valuing the speed and efficiency of the development machine. We have determined that the rate of change is a valuable goal and should be incented. Measuring uptime optimizes for mean time between failures and mean time to recovery.
Our metaphors can induce blind spots and hamper decision making. If velocity is the measure of success, then technical debt projects could be very hard to get started. MTBF and MTTR could stop us from looking to resilience through distributed components that ignore individual failures. A mechanistic view of the organization also can lead to issues with responsibilities; tasks might go undone waiting on a single person to complete, regardless of other skilled individuals who could take it on.
There are other more subtle effects of metaphor selection. Take, for example, the job titles we use: “engineer” and “architect”. Architectural engineers (structural, mechanical, electrical, etc) work with real materials with known and testable stress points to build buildings. Architects design the structure, determine impact, select materials, and co-ordinate these engineers to execute the design. In software, we’d like to say we do the same things and we use the same labels. But I think you’d be hard pressed to find a software engineer who could tell you about the breaking strain throughput of a Java process or have a reasonable way of finding / testing without resorting to brute force. I think we ought to go back to “scientist” as our labels, because the practices of science (all failures are successes, hypothesize and test, etc) are better models for how we develop software than typical civil engineering practices. That is possibly another post on it’s own.
How we talk about ourselves, our work, our lives has an impact on how we perceive and attach value. Repeated or even preferred metaphors can tell you a lot about an organization’s culture. If your manager told you to “go big or go home”, what would that mean to you?
Nota Bene: If you’d like to read more about the academic discussions around these topics, check out the Sapir-Whorf Hypothesis and the field of cognitive linguistics.