Metaphors aren't decoration for architects - they're translation tools that let executives reason about technical trade-offs in their own domain. When your audience picks up your metaphor and runs with it, you've moved from explaining to co-thinking.
Here's what makes metaphors actually work in technical leadership: they translate your problems into the audience's domain so they can reason about the same constraints you face. When you tell a CFO that all unreleased code is inventory, they immediately understand it carries cost and rots over time. You don't need to explain code rot - they already get that milk on a grocery shelf becomes a liability. That's the power of a good metaphor: it shares the dynamics and constraints of your IT solution in a language your audience already speaks.
The real magic happens when executives take your metaphor further than you envisioned. Tell them architects sell options, and a savvy exec will immediately observe that volatility drives up option value - meaning architecture becomes more valuable in uncertain times. That's not just understanding, that's co-thinking. The article shows multiple examples of this: a Starbucks employee extending the two-phase commit metaphor to explain backpressure under load, or a reader realizing that in multiplication, one zero cancels everything out - if you're terrible at communication, all your other skills provide zero value.
The piece gets specific about where to find sticky metaphors: money works because executives manage it daily and there's solid theory behind it. The primary business domain works because it shows you care about the business side. Widely-used items like cars work because they're complex machines everyone understands. But the article warns against frivolous imagery that doesn't hold up to logic, broken metaphors where the behavior is inverted (like using a gas gauge for political capital when tanks fill fast and drain slow, but political capital fills slow and drains fast), and slanted metaphors that bias the discussion.
The practical advice is patient and realistic: it took the author a decade to build his collection. Keep a log so you don't lose good ones from casual conversations. Test and refine with friendly audiences. Make it your thing instead of feeling embarrassed. The goal isn't to make things simple - they aren't - but to help decision makers understand and actually accept the trade-offs, not just nod at an all-green wishlist that provides weak buy-in at best.
Check out the full stdlib collection for more frameworks, templates, and guides to accelerate your technical leadership journey.