Naming a thing is powerful
How many of us have wrestled with a problem in our minds only to stumble upon a term that immediately has us thinking, "Yes, that's it! That’s the thing I’ve been trying to define!" 🙌
Usually, it's something you can't quite put your finger on but you can feel it — and yet, it's just slightly beyond your grasp. And then you find a name for it, and all of a sudden that messy feeling is gone and now you have something real.
While that connection sometimes happens serendipitously, as a consultant sometimes you need to explicitly find a way to name the things you’re trying to solve. Naming a thing can be a powerful way to anchor people to a concept or get a team to coalesce around the problem space. Naming something makes it real.
I'll try to bring this to life with a couple examples.
* * *
First, a common one — picture someone trying to explain a budget ask to a CIO:
"Well, we made some architectural decisions years ago that would let us launch the product faster at the time, but we knew they weren't scalable. Now, it's slowing us down too much to have the team work around those constraints. We need to address that architecture and blah blah blah." You get the idea.
What's the name?
"Technical Debt". 🖥️
Almost anyone working in the technology sphere knows exactly what this term means.
This term is relatively recent. A software engineer named Ward Cunningham came up with it in the early 1990s. It so neatly encapsulated a common struggle that its usage spread and became well known.
Thanks to Ward you can just say "We have tech debt that's slowing us down and we need to remediate it". Sure, you probably still need to provide some details to get the funding, but just by using the name "tech debt" the CIO already has a frame for the ask. (And because of its popularity I've seen adjacent concepts leverage similar terminology, such as "organizational debt".)
* * *
Now, "tech debt" is something people generally know already. You won't always be able to use an existing reference. Sometimes you have to make up your own.
Several years ago I was part of a team assessing how to make a business unit more efficient. It was fairly broad in scope and had process, technology, and people implications (no redundancies came out of it, thank you very much 🙂). The challenges the client needed to address to drive greater efficiency were myriad and hard to cleanly categorize.
It's generally a bad idea to give a client a list of disparate items; the key messages for the client, the narrative, will be lost. You need a story, something people can carry forward when you're gone, and every story needs named characters.
So while the issues weren't easily categorized, we felt we could split them into two groups based of their scale — some were smaller challenges more specific to the business unit, while others were bigger, more complex challenges that were impacting the business unit but required change at a company level.
We ended up using the terms "Micro Challenges" and "Macro Challenges" to name those two groups. The former included those smaller things specific to the BU — perhaps a process change, or team realignment. All were things the project sponsors had control over. The latter covered things that were going to require broader organization change, which would take significant political will and time to address: compensation updates, culture changes, and other gnarly problems.
Now, maybe "Micro and Macro Challenges" weren't the best names (looking back, they don't sound that great 🤔…). But they were good enough to give the client a frame for how to think about the findings.
The name also tells a little bit of the story to others before they even hear the details: Micro — “okay, these are probably smaller things”; Macro — “okay, these are probably bigger items”.
And it gave the sponsors a way to tell the story to other senior stakeholders: "We can achieve some efficiency gains by solving the Micro Challenges, but unless we're willing to tackle the Macro Challenges our progress will be limited."
Now, to anyone outside of this project those terms won't have any meeting. That's okay. Not every term needs to saturate an entire industry like "technical debt" has. It just needs to have meaning to the people you’re working with.
* * *
I'll end with a final tip: naming a thing can be unhelpful if it's too vague. One example that has unfortunately gained prominence in the consulting industry in the last decade is "Digital Transformation". This term covers everything and nothing at the same time. Ask 10 consultants and I bet you'll get 10 different answers! So when do you create a name for something, make sure it has specific relevance to your audience.