I was hired to manage a massive customer-service system in a large company (some years ago). The person who hired me gave me a heads up before I even signed the offer letter. “Your first big problem is going to be moving the system to another platform,” she warned. “The database has expanded a lot in recent years, but planning for capacity has been entirely overlooked. We’re seeing performance problems now, and it’s going to get worse quickly.”
Oh boy, I thought.
I began to see severity-one problems right away: “System very slow,” so slow that users couldn’t process customer requests.
During my first week on the job, my boss’s boss dropped by my desk, and it wasn’t just to welcome me to the ranks.
“The problem,” he said, “is that the users have been unwilling to put any budget toward upgrading the infrastructure. They want lots of enhancements. Meantime, important technical planning is ignored. We haven’t been able to explain to them the urgency and communicate it in a way that works. You have a technical problem, yes, but the real problem you have on your hands is communication.”
I came to appreciate quickly that our users were experts in system functionality. They knew every capability, quirk and nuance. But when it came to understanding the technology driving and operating their beloved system, there were two problems. One was that they knew little about how databases work or what can compromise them, and far less about the computing horsepower needed to enable adequate performance. That wasn’t surprising.
But the second problem was worse: the users distrusted the people who had the technical knowledge to make things work. They were sure that the technical staff was forever overstating the problem, and they had convinced themselves it couldn’t possibly cost that much or be such a big deal to upgrade. The users were sure we were trying to get them into a Mercedes when a Chevy would do.
Oddly, the relationship with the users had become somewhat lifeless. The two groups met from time to time and dealt with tactical matters in a humorless, matter-of-fact way, avoiding disagreeable topics. Lifeless, conflict-avoidant, humorless meetings are no way to make progress.
Improving the Dialogue
One advantage of being the new manager on the scene was that I had no such history with our users. I called a meeting to address the topic, knowing that we needed a way to talk about the problem that wasn’t too heavy-handed, that would neutralize the disagreement and lift the mood a bit. I described our database problem using a metaphor, saying the database had become an oversized canary languishing in a too-small cage. Once, it had been a small bird that had plenty of room in a suitable cage. But after years of normal growth-and perhaps too much rich food-it was now much too large for its digs, too large even to get out without help from the jaws of life.
The user VP was on board with the analogy right away. “We can’t stop feeding it,” she said. “We feed it new customers every day.”
I assured them we didn’t want to limit its intake but that instead we needed to plan, immediately, for a cage better suited to the beast we now had. We eventually also agreed to form a project focused exclusively on significant tune-up work to get the canary in better shape until a new cage could be spec’d out.
“A personal trainer!” someone said, and everyone laughed.
Luckily, comparing the database to a trapped, oversized bird struck the right note.
The next day, I ran into my boss’s boss in the elevator, and he said he’d heard we were going “to slim the canary down while we planned for a new cage.” He mumbled, “A fat canary”¦” then trailed off, smiling.
A Figure of Speech
A slow-performing database running on an underpowered platform is an oversized canary trapped in a too-small cage. That’s a metaphor. If the term “metaphor” is vaguely familiar, perhaps from a long-ago English class, here’s a reminder: a metaphor is a figure of speech comparing one thing to something else, but speaking about them as if they were literally the same, for effect. A database isn’t a canary. But the effect of talking about it that way suddenly makes the database seem vulnerable and in need of urgent attention.
Metaphors are proven, effective ways of expressing thoughts, ideas, concepts, discoveries, anything! Note that word-effective. Metaphors are effective. We want our communication to be effective! We want to make the point, to be remembered, to defuse tension, and stimulate discussion. That’s what effective means, and metaphors have a longstanding reputation for doing just that.
Writers have been using metaphors for thousands of years. A famous example: “All the world’s a stage.” We know immediately that the world isn’t really a stage. But expressing it that way suggests something more-that the world is merely a place to perform, to be trivial, impermanent, to go through phases, then depart. Great metaphors evoke layers and layers of meaning-far more layers than “the database is a canary” suggests!
You may also remember from English 101 that, among figures of speech, there are not only metaphors but also similes. There’s not much difference between a metaphor and a simile. Similes use the words “like” or “as” to set up the comparison. If Shakespeare had written “All the world is like a stage,” it would have been a simile. As it is, it’s a metaphor.
Coming up with Business Metaphors
To make business language more effective, metaphors can certainly help. But how would you come up with one? By thinking of various kinds of quests and challenges because that’s what business is usually doing, engaging in a quest of some kind-beating the clock, resolving an urgent problem, saving money, anticipating the market, etc. So metaphors about quests in various settings may help express urgency, gratitude, and scale in ways matter-of-fact language cannot. Some ideas:
A metaphor for a threat – Let’s figure this out before the giant whale breaches and dumps the little boat we’re in!
A simile to inspire new design goals – It needs to be as precise as a German train schedule and as undetectable as a dormant virus.
A metaphor for above-and-beyond work – You’ve been climbing Mt. Hood in blizzard conditions! And you made it!
(Note: Metaphors are more fun if they’re specific. If you’re in Portland, Oregon, say Mt. Hood. If you’re in the Berkshires, say Mt. Greylock. If you’re in Florida, you need something other than a mountain, something relevant to your geography, like a swamp.)
Beware of mixed metaphors. In other words, if you’re talking about climbing a mountain, stay with the mountain. Don’t switch out mid-metaphor, as in: You were climbing Mt. Hood in a blizzard, and you took the cake! What do cakes have to do with mountain climbing?
Here’s another mixed metaphor: If you get in the way of the train, you’ll find yourself in hot water. Better: If you get in the way of the train, you’ll be flattened. That’s what a train would do to you. It would not put you in hot water.
A Canary of Your Own
It’s tempting to stick to the same-old-same-old ways of describing and expressing things. We do so because it’s easy and because everyone else does it that way. Ho-hum, straightforward, uninspired business and technical communication is, sadly, a norm. But it doesn’t have to be.
Next time you can use a little help from the English language to get people on your team moving, encouraged, or aligned, try slipping a metaphor into your conversation and see if it doesn’t catch on.
Susan de la Vergne is a writer and communication instructor who worked in software development and Information Technology leadership for a very long time. Her Engineers On Stage: Presentation Skills for Technical Professionals is available from Amazon. Susan is also offering twice-weekly online “Mindfulness Minutes” to help busy professionals start their day with a balanced, positive mind.