I feel like I’m getting dementia.  My colleagues communicate with me, in meetings, in emailed reports, in presentations, and I don’t know what they’re talking about – again.

[Source: morethandodgeball.com]

Part of the problem is that I’m in London, and they’re in Austin (or New York or San Francisco).  It’s morning for them, and evening for me.  And the other part of the problem is that I have to decode sentences like these:

“We’re adding a new API to DimSum (using Ostrich) to support Concierge”

“We updated the Beavers to use non-HTTPS healthchecks (Badger doesn’t support HTTPS), and fixed a bug that prevented Snitches from being deleted”

“Bouncer was down for a couple of hours, and BHive had a data loss – we’re restoring it from two days ago”

* These were modified to protect the innocent, but accurately reflect the nature of the messages.

Now was Beaver our service monitoring tool, or was that Bouncer or Badger?  And Concierge? – Was that our new data API or our product matching tool?

At Bazaarvoice, we’ve taken to giving a humorous, or quirky name to each of our services, tools or projects. [I must confess to being an early offender by naming our analytics infrastructure Magpie.]  It began innocently enough, and wasn’t a discernable problem when we were thirty engineers and only a few separate services.  But our rapid employee growth and the shattering of our monolithic codebase into independent services has resulted in a mishmash of project names, some of which include:

ABBA, Agrippa, Badger, Banyan, Bellhop, Bouncer, Bhive, Caber Toss, Chameleon, Concierge, Decon, DimSum, Doula, Firebird, Golden Hammer, Haruspex, Hitch, Magpie, Maestro, Nydus, Omnia, Ostrich, Polloi, Rotary, Sodexo, Stratos, Switchboard, Yente

Language is important.  Especially in technical fields.  We have to know what we’re talking about.  And so using the right name to convey meaning is important.  People bemoan the use of acronyms, but at least they’re an abbreviation of something meaningful and descriptive (e.g. MVP = Minimally Viable Product, API = Application Programming Interface, UI = User Interface, etc).  The project and service names above have a tenuous (at best) relationship with the nature-of-the-thing-named.

And so we find ourselves polluting the clean air of communication.  Every new tool gets a new code-name, and I’ve got another thing to stop and decode.   It’s giving me cognitive asthma.  And I can’t be the only one.

[Source omiusajpic.org]

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

Proposed Solution

Here are the helpful and descriptive counterparts that I had compiled to help me decode the names above.  See if you can match them up!

the Monitoring and Metrics Service, the Configuration Database, the Logging Service, the AWS Cost-Reporting Tool, the Universal Product Catalog, the Product-Matching Tool, the Automated-Moderation Tool, etc.

If we were using helpful and descriptive names in the office, our communication would instead sound something like this:

“We’re adding a new API to the Client Configuration Tool (using SOA-Lib) to support the new BV Read-Only API”

“We updated the Cloud Conformity Enforcers to use non-HTTPS healthchecks (the Monitoring and Metrics Service doesn’t support HTTPS), and fixed a bug that prevented the Metrics Agents from being deleted”

“The Feature Flagging Service was down for a couple of hours, and Client Configuration DB had a data loss – we’re restoring it from two days ago”

The quotes above still require context to understand (BV, SOA, healthcheck, etc), but they’re at least 5x easier to understand and process in real-time than the originals (for me at least).

Fortunately we’ve started to make progress on tackling this problem.  After pointing out the issue, and hearing a chorus of endorsement from newer employees and other teams outside of R&D, we’ve started asking R&D to use helpful and descriptive names for their services (with code-names in parentheses if desired).

Reaction

Surprisingly to me, however, some folks don’t agree that there’s a problem at all.  Take, for example, one colleague whom I highly respect:

“From my perspective we don’t have a naming problem, we have a branding problem.  Changing project names provides a superficial level of understanding to the reader that doesn’t accomplish enough in my opinion.  I want people in the target market of my projects to think of this when I talk about Badger:

<snapshot of awesome service monitoring UI>

Now, although he says “we don’t have a naming problem,” what he goes on to describe further in our exchange is the problem that is on his mind, namely: How can he increase awareness and adoption of the services that his team is developing.

Like so much communication, we’ve got separate agendas and we’re both talking about our own problems, trying to be heard.  Mine is decoding what he’s talking about when he says Badger (or Bouncer, Beaver, etc).  His is having people understand what his service provides.  But I struggle to get him to recognize the relationship of my problem to his.  If I can see the image of his beautiful and amazing service in my mind, but I cannot recall or recognize its name, I cannot think of it further.  If I want it to fit in the architecture in my head, I have to substitute a useful name; the Metrics & Monitoring-service.  Now I can work with it in my head.

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 suppose that I should really stop being lazy and actually take the time to learn and memorize each of the 35 (and growing) project / service names.  I am a development manager after all.  But what about people a little bit further on the periphery?  What about our Product Managers, our Support Engineers, our Marketers, our Salespeople, our Executives?

The solution is to legislate a “Clean Air Act” for communication, enforce it, and reap the health benefits of clarity and understanding.

Stop making me work so damn hard to understand what you’re staying – if it means speaking to me like I’m stupid, I won’t be offended.  Sometime, somewhere, it might make all the difference that our company understands the implications that “ABBA is down” or “BHive lost a days worth of data” or “We’re understaffed on Omnia.” [or positive stuff too like “Yente is seeing 5x more usage and engagement than anticipated!”]

And I’m sure this rant applies to other companies too.