Sixteen years ago, I attended my first meeting with engineers as a new product manager.
My boss had warned me that I wouldn’t understand much.
“You are a Microsoft Word person entering an Excel world,” he said.
After the perfunctory greetings, everyone got down to business.
Not only did I not understand the concepts, I didn’t understand the words. It reminded me of the year I spent in Europe as an exchange student.
The group started out with a heated discussion about squirrels.
Later I learned they meant SQRL, a mnemonic one of them had coined to describe a proprietary Bloomberg system that stood for Search Query Language.
My immediate thought at the time: COMMUNICATION IS HARD!
Unable to participate, I resorted to frantically taking notes. My chicken scratch from that first meeting included these examples:
“Will we be ready for the build?”
“We are pushing them out to one cluster. We don’t want to run the risk of crashing on all four clusters.”
“We need to do the primaries. We are moving out the new ingesters and even now on Alpha I wouldn’t feel comfortable with major changes.”
“We could flush the queue. Test it on dev and then alpha.”
“Where are we on the new keyword cooking?”
“Does anyone have any objection to wildcarding German? We already wildcard Japanese.”
“Y516 is slower than the other boxes. Network blames the systems guys who are blaming the network guys.”
“Is priority queuing in place? Is there any protection for the 2 go events?”
“We talked about de-duping the two versions from the eco lock.”
Every tribe has its vernacular.
Complicating matters was the realization that some of the terms were general tech jargon and others were unique to Bloomberg.
So while anyone at Google would know what “wildcarding” meant, they wouldn’t know about the “squirrels.” (Later, some engineers used the acronym SQRL to denote a login authentication standard.)
I learned what most of this meant over time, but the engineers didn’t make it easy.
One of the biggest changes I saw in product development over the following 15 years was a serious effort both on the part of engineers and product managers to close the linguistic gap.
Jargon comes in different sizes, of course. There is the secret-handshake variety that is meant to obscure. And then there are the delightful turns of phrase that are mysterious, but understandable.
My favorite one of those was “non trivial.”
That was the default answer when any engineer was asked to assess the difficulty of a project.
Nothing, product managers learn early on, is ever “trivial.”
(Part of a series about lessons from three decades at Bloomberg LP)