Most of us think that translation always involves more than one language, for instance, English into Simplified Chinese. But there are many forms of English-to-English “translation” necessary to prepare internal data for release to the outside world. Nowhere is this more evident than when you are required to act as a liaison between sequestered developers/engineers and sales/customers.
I was left to my own devices to decipher what was worth carrying back to the outside world. Over time, I found some techniques that actually worked.
I learned this years ago while working for a small start up company in Boston. The company had yet to make its first real sale; think pre-IPO start-up on a “below” the ground floor opportunity. Living on the west coast, I was supposed to spend two weeks in our Boston headquarters to “get acquainted” with the product and developers. I documented and shared my impressions internally; that trickle of critical internal business intelligence led to three and a half months of living on Commonwealth Ave and life amongst the Clan of the Code Creators. Soon I was spending every day with the “smartest guys in the room.” I didn’t know it at the time, but I was developing a “translation” skill that I continue to use to this day.
At times I felt like Jane Goodall, only it was more like I was the chimpanzee, and the engineers were an enclave of exotic humans.
The Lion’s share of our engineers had come from the same company. Having worked together for so long, they had developed a “tribal” form of communication probably found nowhere else on the planet. At times I felt like Jane Goodall, only it was more like I was the chimpanzee and the engineers were an enclave of exotic humans. I’d worked with many developers one-on-one before, but never in a pack or tribe. But there are recognizable patterns in how engineers communicate, both verbally and in writing.
Because the clock is always ticking against how many lines of code they write, time is highly valued by developers. And they can be less than patient if you can’t articulate your question in less than 15 seconds. “Max, are you going to tell me the time, or build a damn clock?” Emails and written communications (e.g. draft text for an RFP) can even seem down right rude to the initiated. If I had a dollar for every engineer authored email reply that started with “Anyone with a brain can see that …”
Learning UNIX was easy, but …
Learning UNIX and creating content from code remarkably like XML on our turnkey publishing systems was the easy part. When our engineers gathered together, with no civilians in the room, communications changed radically. Although I was clearly a “civilian”, I soon became a familiar fixture and the pack of developers reverted to their “native tongue”. Since sales support and marketing people live or die by painting word pictures to propel a message, the “disconnect” can be pretty awesome. It’s kind of like watching Marcel Proust trying to communicate with the masters of Haiku.
I was left to my own devices to decipher what was worth carrying back to the outside world. Over time, I found some techniques that actually worked. People who are gifted at handling three streams of conscious thought while writing or debugging code have to be a different breed by nature. And one of the things that nature didn’t give them was that hackneyed resume phrase: “excellent written and oral communications skills.” At least not for mere mortals.
Actually, engineers and developers do communicate quite effectively amongst people who live and die by the same “code.” But their limited access to customer site drama and sales dynamics can inhibit their “outside world” communication skills. If you find yourself in my situation, acting as the translator/liaison between your developers and the rest of the world, here are the rules for capturing critical data when there are no engineering release notes, and “getting out alive”:
- Understand why they are the way they are: you may be dealing with someone who appears bright, refreshed and ready to face a new day. You may not have noticed that he is wearing the same clothes from yesterday, he just put in 22 hours of solid bug fixes, and hasn’t eaten anything for 11 hours. What kind of mood would you be in under work conditions like that?
- Get over it: never, ever take anything said to you by an engineer personally. If engineers seem downright rude, (“are you just stupid, Man?”) they probably have no idea that they are perceived that way. They communicate with each other this way, and time is of the essence. In their world there isn’t time for the diplomacy part of their brains to go active when addressing non-engineers.
- It’s their way or the highway: realize up front that you will need far more patience with the developers or engineers than they will ever have with you. In that sense, it will always be a one-way relationship. The engineer may want a 7 second question from you, yet take 45 minutes to describe something that should take 10 minutes. Don’t bring this behavior to their attention. Hang on every word and keep questions to a minimum.
- Pretend your watching an Opera: most of us aren’t fluent in Italian and don’t really follow an Opera’s libretto word for word. If we’re familiar with the story, the performer’s intent comes across. Engineers can be highly elliptical in their explanations: many of them seem incapable of committing to a solid conclusion. “We need further testing.” Even if you have to endure a 90 minute “drama” regarding how/why it may take two or six weeks to complete some development, just try to capture the “big picture”. You can always go back for details later. As we all know, regarding software release cycles, it truly isn’t over until the fat lady sings.
- Come bearing gifts: be creative in discovering a way to earn the respect of engineers. You aren’t going to do it through writing code or being “one of them.” You have to find something to offer that they value. It may be a clever benchmark or Captivate demo showcasing their creation. Or, you may be able to share highly prized business intelligence on the competition. Before blogs were thought of, I created an email list with select engineers (with their director’s approval) and fired off a weekly “what’s hot” from the field emails. With one SW company I went “cute” and labeled these missives “FAX from the Max.” (Are any of these ancient messages in the Boston Computer museum?) The engineers loved it: (a) they were getting unfiltered feedback from the field, (b) they knew who the potential big fish were, and fashioned appropriate hooks to land new targets and (c) it was also an interactive process, in that replies from engineers were instantly woven (after translation) into my revised sales pitch. It became an iterative process that “snow balled” into proof of concept tests for new industries our company wanted to penetrate. Anything that stuck to the wall was disseminated to the field to replicate a new sales/engineering team strategy.
- The way to an engineer’s heart is through his stomach: shamelessly bribe them with food. Jane Goodall used bananas to draw chimps into the clearing. Draw your developers from their cubes with a box of Krispy-Kremes or several boxes of favorite-maker pizzas. This will go a long way towards stamping “value” on your non-tech forehead and buying more time in their presence. In some business situations, a couple of cocktails will loosen tongues. With engineers, a group feeding frenzy can often turn into a productive brain storm and a “Jane Goodall” moment for you to discover something new and brilliant about forthcoming product features.
- Blow their horn: help give individual developers deserved visibility within the rest of the company. Engineers often rightly feel that they are isolated and ignored. Who else is there at 2 AM? Letting sales and marketing occasionally know that so-and-so had a real break through in a feature that will make next year’s numbers can lead to a reprogrammed employee I.D. pass for you that unlocks a few more doors. (Caution: if you start eating only pizza and don’t remember what the sun looks like, you’ve gone too far, and need to go back to civilization for awhile.)
- Acting skills can help: learn to listen to developers and keep a straight face no matter how far out or ridiculous their suggestions for a proposed user interface may seem. (Baby boomers, imitate Dr. Joyce Brothers; younger team members, imitate your favorite “serious” sports commentator who knits his eyebrows, pauses, and looks concerned). If the Code Klan throws out something really wacky, don’t laugh until you get to the other end of the parking lot. Remember, these guys are used to handling tools and editors that make ordinary people feel like they just got off of a roller coaster. An engineer’s pain thresh hold will always be higher than yours. These guys probably get fillings replaced with no Novocain!
- Haste makes waste: sleep on it. Never fire off a multi-recipient email or an internal blog about your latest findings from the Clan of the Code Creators in haste. If possible, wait overnight before reviewing your commentaries “through the eyes of an engineer.” Then send it off for internal distribution. The more brilliant your developers are the more easily insulted or alienated they may be from a perceived slight. On an emotional level, the richest fruit doesn’t always hang from the strongest branch.
Improved habitat doesn’t lead to better communications
Thanks to the proliferation of social networking tools, various herds and tribes of engineers can find and connect with one another, and feel less isolated today. But it hasn’t done much to improve their communications skills. If you don’t believe me, have your favorite engineer write part of a response to an RFP and anticipate how the customer may react to some of the tone. Of bring a couple of engineers along at your next face-to-face customer meeting, when you expect to close a sale! “Hey, did you know that you can pull together a solution for free using Open Source Tool kits that you can download for free?” (I actually had an engineer say that to a customer in a trade show booth once.) Somehow, the connection between sales and salaries/bonuses hasn’t sunk in for much of this tribe.
The better the product, the higher the risk
Ironically, in small, pre-IPO companies that are heavily populated with developers or staff with technical degrees, there is a high degree of risk: being hypnotized by your own creation. If everyone in headquarters is beyond average intelligence to the point that “next generation” tools seem normal, there is a risk of not reaching the IT equivalent of “Joe the Plumber.”
In the movie Lover Come Back, Doris Day played a high-power stakes Madison Avenue Ad executive. Holding a garish Ad mock up , she wisely observed, “Leonard, we have to sell this product to ordinary, average every day people.” Her creative Director rolls his eyes and quips, “oh yes, Them!” Thus, there will always be a need for some internal “translation” between an engineer’s brilliant intent and the human-readable message that finally makes it to the outside world.
If our developers weren’t as brilliant as they are, the products they produce wouldn’t be worth selling. If our sales people had to decipher the first draft of product functionality into customer-ready language, they’d have to stop selling. And if traditional marketing people were familiar enough with the product or application to do this translation, a “Jane Goodall” liaison wouldn’t be needed.
Another group to translate for
So there will nearly always be somebody in between, that hybrid “liaison” person, well versed in the application, who carries forth nuggets of wisdom from the Code Cave into the light of day. Once your hybrid/liaison person translates the nuggets into usable feature/benefits, your brilliant creation can be sold in understandable terms. As we all know, customers and purchasing agents are not always the “sharpest knives in the drawer.” And that can lead to yet another level of English to English translation, and a blog longer than this one!