After yet another complaint on the internet about a ticket management system, something obvious occurred to me. Something obvious that I’ve been implementing ever since. You shouldn’t name your tools. I’ve been applying this obvious principle for a long time to all sorts of things, but using it for tools had escaped me.

TOTEM

Giving them a name means giving importance to what isn’t important. The name isn’t important. What we do with it is. I have to name some here to support my point: jira, confluence, trello, draft.io, etc. All these names make things very conceptual, not at all concrete. Everyone uses them differently, everyone understands their utility differently. It becomes a totem behind which everyone takes shelter.

In work around metaphors, we seek to make things concrete so we can have genuine communication. We can rely on a useful acronym VAKOG (which recalls the five senses: visual, auditory, kinesthetic – tactile –, smell, taste) to anchor our metaphor in something tangible. Jira, teams, slack are naming protocols that can make us forget the meaning of things, generate misunderstandings, mix-ups, and above all not help us solve things, learn, move forward.

Instead of saying jira you could say: the ticket list or the product feature list. And already it’s not the same thing at all. Ticket list or product feature list? Or the place for all lists (which expresses yet another thing). So instead of having a conceptual name you’re saying what they’re for, you’ll make yourself much better understood, and understand what’s happening with this tool.

Naturally you can extend this practice to all your tools and methods (that’s what I’ve been doing for a long time): no quarterly planning or PI planning, but the synchronization point between all teams, or the day for presenting objectives for the next three months. Naming well is understanding well as always. By expressing a use: synchronization? Presenting objectives? Both? You prioritize, you put a focus.

It’s the end of jargon and that’s a good thing. As soon as we stop talking about tools, methods, the how, we start talking about interesting things. As soon as we stop talking about tools, methods, the how, we start asking the right questions.

RESPECT

Personally I’m always very careful to speak in a way that no one can escape through jargon, or abuse of language, or umbrella words. And this also serves to respect the other person who doesn’t take jargon as a signal telling them they’re has been. If I speak in order not to be understood, what does that say about me?

“What tool do you use for a roadmap? Do you have a roadmap?” No. Rather: do you have a clear vision of how you want to develop your product, for what purpose, and how is this expressed? A calendar with expected features? A timeline with key milestones? “I’m hesitating between doing scrum and agile at scale,” no. Rather: I need to have an organization that facilitates large-scale delivery, or an organization that allows delivering things more regularly.

Abstract concept words are traps. Worse, some are marketing concepts that often lie about their intention. Confluence is often the place where everyone deposits their content in their corner without ever crossing paths with another’s, without convergence, SaFE is the guarantee that you won’t be adapted to the changing and interconnected world we live in.

Let’s try not to name our tools to see real conversations reappear.