Here’s a memo I sent out to the engineering team this week:

Time for some real talk people.  We have a problem that we’re either not aware of or we’re tolerating.   I had to stop a meeting last month to address it.

A variety of stakeholders were getting a status report from a team, and it went something like this* (* names & details changed to protect the innocent):  “The Montesquieu project is blocked but the Montserrat project is complete.”  And we moved on.

I stopped the meeting and did a quick little quiz to see if people knew what the Montesquieu and Montserrat projects were. Let’s say that there was about 50% correct internal assignment of project name to project understanding for the non-team stakeholders.

As George Bernard Shaw once said, “The single biggest problem in communication is the illusion that it has taken place.”

I’ve seen this before.  People mix up the two project names.  Or they have no idea and don’t ask. Or they are actually thinking of that other project: Montagne!

It’s super fun to name things super fun, but it impedes our mission to help people get jobs.

Collaboration is how we accomplish great things together.  Rapid and clear communication is essential to collaboration.

Here’s why you should name projects as plainly as possible:

• Recognition – when people hear the name, they need to quickly associate it with the project.
• Recall – people need to be able to recall the project name when thinking about the project.

You should apply the ‘unprimed association’ test when you name something XYZ.  The trick is to ask a few people what they think of when they hear of project/product XYZ.  Code names fail this pretty quick. It doesn’t have to be perfect, it just has to be helpful and close.

In the Incubator we established a rule to name projects as plain and clear as possible, because we needed our busy executives (SLT) to understand them and keep them clear in their heads.  That’s why we named them things like: Referrals, Hiring Events, Chat, Guaranteed Response, Text2Apply, Interview Now, etc.

Imagine if they had accidentally mixed them up when conversing about funding (“I think we should fund Montesquieu and not fund Montserrat”).  Yikes.

Here I’m going to quote from the Harvard Business Review: “Use words that will resonate with those whose support and influence you must earn. If they can’t follow your ideas, they won’t adopt them” (hbr.og)

I’m going to give some examples – not to pick on them, but because they merely representative – and suggest alternatives:

• Itasca =>  Resume Bank
• Iris =>  Native App Vision
• Captain Planet => Jobs-on-HP
• Hodor => MatchFilterService
• Beaker => AggFeedStore

The plain alternatives are longer, and in practise people might adopt acronyms or shortened versions.  That is ok. I will assert (without evidence) that acronyms are better at recognition and recall than code-names – when people use acronymed names (like Amazon SES), internally the acronym and the expanded-form (Simple Email Service) are connected in the brain.  But my brain simply doesn’t have any neurons connecting the name Itasca with the concept of a resume bank.

Harder to recall/disambiguate (all real project/product/tool names at Indeed): Wendy, Wenda, Waldo, Waldorf, Basestar, Deathstar, Stargate, Goldengate, Gate, Iris, Aurora, Orion, Janus, Philae, Curious George, Yellow Hat, Yamanote, Peregrine, Naboo, Nigma, Hodor, Horton, etc.

Easier to recall/disambiguate: Session Viewer, Query Manager, ITA Manager, Job Metadata Viewer, AdCentral, AggCentral, User Personalization Service, Notification Preferences Service, TitleNorm, Labeler, JobSearchService, TestStats, Salary Transparency, etc.

I feel like a grouchy old person as I write this.  I’m fun. Really, I am. But please stop having so much fun with your names.  This is not a mandate. This is just Brendan sharing his belief that we should use boring, simple, clear, recallable and recognizable names for our projects, services and tools.