First, a joke -
A man is floating in a balloon, a few hundred feet off the ground, above a field. He sees a man walking his dog, below, and calls to him.
"Hey", the man says, "Can you tell me where I am?"
The man below looks up, thinks for a second, and replies, "You are in a balloon, 55 feet above ground level, going northwest at about 2 miles per hour".
"Gee, you must be an engineer", the man in the balloon calls down.
"Thats right! How did you know?"
"Because you have given me information, that while technically correct, does me no good whatsoever!"
"I see", said the man on the ground, "You must be a manager".
"That's right", the man in the balloon said, "How did you know?".
"Because, although I had no part in getting you into your predicament, you have made me feel somehow responsible!".
A while ago, I gave some talks on the languages design engineers must be familiar with. The need for this became apparent when we were changing over to Earned Value Accounting methods, and training the engineers. The finance people became very frustrated when they discovered that these hot shot, advanced degree engineers and mathematicians couldn't understand what the finance people were saying. The trainers had to take a step back and define the terms and goals to meaningful for the audience. Once they changed the language, the engineers were able to easily follow the lectures. They just were using too many new words for anyone to understand the underlying concepts.
It then occurred to me that I had been given a talk by our business development people about interfacing with customers, on what to say, what not to say, etc. And the business people often asked me to translate engineering talk to something they could run with.
So I realized that there are four languages that are spoken in our business, depending upon the audience and circumstances. And here they are:
Public Language
Friends, Family, Strangers
Customer Language
People who are paying, or will potentially pay you or your company for a product or service
Technical Language
Technocrats in your field, or a field very similar to yours
Business Language
Program Managers, Finance, Contract People, Lawyers
Why should you learn to speak multiple languages?
People will be more receptive to your ideas if they are placed in their language. If they don't understand you, they may think you are smart, but since they may not trust their understanding of the subject, they will be more hesitant or unable to act.
Speaking the language speeds up interactions, and leads to more accurate understanding. If you don't do this translation, then you will have to depend on someone else to do it for you, slowing everything down, while adding an additional perspective you may not like.
Learning the language provides insight into the thought processes of your teammates. " It looks to me like all you are offering me is more risk...gee, when you put it that way...."
The act of translation can reveal inconsistencies and errors in your position. There are some things that sound good in one language, but "don't sound so good when you put it that way".
This language you probably learned in college, and strengthened in industry. It includes acronyms, verbal shorthand, and is very dense. Even those who know all the terms may have trouble keeping up. Throw in the names of specialized, similar equipment, and some local dialect, and it can be very daunting to follow for a non techie. Engineers tend to start talking in the middle, assuming that everyone knows what the engineer just figured out this morning. Also, some engineers can take 10-20 sentences to complete a thought, even at a very high level.
An engineer can become very frustrated with others who are trying to decode what they are saying. The listener may not be interested in the technical minutia, but be searching for concepts they understand, or something they can take action on. Like in the joke above.
When I designed power supplies, many times I was the only power supply designer in the organization. When I went to technical conferences on power supply design, It was like returning to your native land after living in a a foreign country. At these conferences, everyone around the lunch table pretty much understood everything I would say, as fast as I could say it. And I could follow them, since they talked my language. Back at the plant I had to streamline/translate my explanations quite a bit. Sir, that approach would make the unit big - big as a lunchbox! And you want a deck of cards!
So the engineer must be aware that when she breaks into technical language, she will lose some of her audience. Unless she is speaking to other engineers, who have similar training and dialect.
Be aware that engineers tend to start all discussions in the middle. Yes, that means you. Develop the "two sentence frame", to locate a discussion in space, unless you are sure that the others are up to speed with the current thinking. If they are, they will find the "two sentence frame" very annoying.
Be careful with terms. Different disciplines use different words to mean the same thing. Or the same word can have radically different definitions in different fields.
Here is an example: Synchronous has two completely different meanings based on who is using it.
In digital or telecommunications design, synchronous means a set of signals are sampled with respect to a common clock (i.e., time) to determine a state change. It is derived from Syn-Chronos - the God of time.
In Network or API interface design, synchronous means that each data transfer requires a response before then next data block is sent. This Network synchronicity has nothing to do with time, or any gods in particular.
I have even been in organizations where different departments used different words for the same thing. All were all comfortable with the using different words for the same thing for different people, even in the same meeting. This made presentations very confusing for the uninitiated. Find out if you are talking to someone familiar with the field, and will understand your terminology, or whether use of different terms is required.
Use sketches and pictures as much as possible. When I was giving presentations to engineers, I was told that if I didn't show a schematic or mechanical drawing by the third slide, I would lose the audience. If it is breaking down verbally, head to the white board, draw pictures.
Paraphrase tough questions. It may be definitions that are bogging things down.
When having trouble understanding the what the issue is, "Take a note". The act of writing down the issue on paper, or on the white board, often will allow for clarifications.
Allow, and be prepared to give, fairly in depth explanations of issues and solutions. Be patient during recaps, they establish equal footing after a rocky period.
Don't take it personally - techies discard whatever minimal social graces they have during technical discussions. You are far smarter than a stump. Most stumps, anyway.
Respect mental exhaustion. When someone's brain is full, you can't cram any more in. Better to wait until tomorrow.
Be suspicious of an immediate answer from an engineer. Engineers create answers using analysis. If they haven't done the analysis (and if it is a new question, you know they haven't) and they answer immediately, then they are guessing, or bluffing. Or get the same question a lot. Which means that the topic requires frequent explanation. Hmmm....
A customer has an attention span of about two sentences. Very different from the Technical Language above. Any more than this, you are digging yourself a hole. It is OK to pause before responding to a complex question. People are used to engineers and scientists thinking, it is what they are paid to do. It is also OK to say that the explanation could be long (at least, longer than two sentences), and ask if the customer wants to hear it. Some customer questions are spur of the moment things, and they may immediately edit or rephrase the question, helping you a lot. You may need to practice putting things into two sentences if you have been working with engineers a lot, where this behavior is not demanded.
All Customer Language statements must be positive. Customers have historically been presented the rosy side of life, and are biased toward everything being totally under control. This leads to two types of customers:
Ones who have always heard everything they want to hear, and are giddy with the possibilities, and
Ones that have gotten jaded, and don't believe anything anyone says.
In either event, both types will expect to hear positive statements only. Don't let them down. This is a cultural bias that is pretty ingrained, few customers are exposed to anything different. Keep your dirty laundry in the hamper, for the engineers.
Never bring up a problem without a solution. Just don't tell them until you have figured something out. Problems that are left unsolved, even for a short time, are serious worry points for most customers. By presenting the problem, with a solution in tow, you can adhere to the positive statement requirement above.
The customer will listen to you based on their priority list. They will rarely make this public (because it may affect negotiation), but you can figure out what it is by seeing what his attention is to you as you talk to them. Better yet, ask someone else, who is not talking, to monitor their attention for you. This is valuable intelligence.
Customers expect engineers to be a little...coarse. But remember, that while you can drop your propriety with your technical comrades during heated discussions, you must maintain your professionalism with the customers. Yell at the sales guy after the meeting, not during it.
Some people automatically use bridge expressions that customers find distressing, without realizing it - "I'm going to level with you", "Honestly", "junk", "hack", "WAG (Wild Ass Guess)", etc. Think of how these would sound to a positively biased person. You weren't being honest before? Your design is a hack? Your estimate is a Wild Ass Guess?
Identify with the customers point of view as a user/purchaser
Customers know more about what they need than you do. They may not be able to communicate it, but they will know a good solution when they see it. Never tell a customer he is wrong about what he needs. If you just have to, show him something better with a demo or prototype.
Customers know less about your technical approach than you do. If they have an expert, you may have to respect his point of view, but in the same way that you do not know all the customers problems, the customer does not know all of yours.
Be careful being too chummy with the customers business people. Program Managers always hear during negotiations "But your own engineer said....!"
Don't be afraid to defer to the Program Manager if the discussion gets dicey. Customer interaction is theirs to manage. Discuss with your program manager a signal if the question is not one you can answer confidently. Usually just a long pause will alert the PM to jump in and table, deflect or otherwise move the situation along.
Be confident, and know that for a custom design, trust is everything.
To communicate using the business language, each sentence must include one of the elements below:
Schedule
Budget
Risk
Specific Future Opportunities
Other information will probably not be heard. Businessmen, which includes most finance people and lawyers, expect yes or no answers to all questions, even when this is clearly impossible, technically speaking. This is especially true if you are in negotiations. The bright side is that they will accept exact numbers almost without question. Give them numbers, and show them they all add up. Since this is what they understand, it will make them comfortable. If you have done an analysis, they will expect an immediate, (often single word) answer.
Here are some responses I got after exhausting, technical solutions were presented:
"Nowhere in all that conversation did I hear a date"
"So...what will it cost again?"
"Who else would use this?"
"This isn't going to affect CDR, is it?"
"Are your projections in '94 dollars?"
Show plenty of numbers, and make sure they add up. Spreadsheet errors can total a review, and lead to "Marsh Board Madness", where anything is possible.
Ask your Program Manager how he would like to represent the company to the customer. This will give you a good idea of how you should carry yourself to him
Program Managers view all tasks as implementations. Design is a spirit world to them. They know it exists, but is pretty creepy, and they do not want their job hanging around there.
Be sure to state whether you believe your answer is a fact, or you are providing an opinion.
A Program Managers primary skill is negotiation. Their first impulse in any discussion is to negotiate. Don't go into the ring with them on this, you will get beat up. You can negotiate on actions, but don't negotiate on facts, or your honest opinions.
Know the difference between and Estimate and a Bid
Learn the laws of Business Physics. They are not that hard, and will enhance your communication skills greatly.
Know your audience - who is in it?
Business people? Numbers, concrete predictions, and include the bottom line
Customer - show benefits in terms the customer uses and understands, and steps you will take to make sure that they will be satisfied
Techies - hard facts - Mark Twain said about science - "Never has so much speculation revolved around so few facts" Get the facts out there, and make sure you identify you opinions clearly. A handy phrase is: "if you are asking my opinion, then...."
Below are some Rosetta Stones for various discussions to show the difference between the four methods. In each case, I am speaking a different language, depending on who I am talking to. But all responses say the same thing.
Problem under discussion: Programmable Gate Array is 50% full, but suddenly will not route. Vendor confused, working the issue. Have experienced this in the past, cured by changing internal paths after direction from vendor.
Technical: "Their router doesn't like this feedback design. I've seen it screw up like this before, this router is really a piece of junk. The vendor is looking at it, but I may just change the signaling to avoid the problem this go around. It is not as efficient, but I think we will still meet the timing if we......(ten sentences).....and it might work."
Customer: "The implementation we have chosen has given the commercial software some problems. The vendor has promised to address this issue, and we have some workarounds we can implement if his corrective action will not meet our schedule. "
Business: "The PGA ROUTER PROBLEM is going to cause a two week hit in the schedule. It is not in the critical path. The software is under maintenance agreement, and the vendor has promised to respond by next week. If we can't use their solution, it will cost us another 100 hours to work around."
Each of the above says the same thing, in a different way.
By the way, did you ever wonder in Star Trek, how they knew how long every repair would take, to the minute, within seconds after something went wrong?
Problem under discussion: Units that have been in the field for some time are suddenly failing in great numbers. Failure analysis shows power initiation transients are to blame. Testing has shown that it is several, unrelated pieces of equipment interacting during power up cycles. There are many possible solutions, but completely defining the problem will be difficult given the number of interacting systems.
Technical: " The power up sequence is uncontrolled and has been changed by the LBPR to enable TRDP cycling. This causes the reactance of another WRA (we are not sure which one) to induce enormous transients across our hash chokes in the GR-A and its backup TDP. We have duplicated it, and are checking the contactor sequence now, but getting consistent data from these tests is a bitch. Here is a drawing of the setup, and you can see these contactors are...."
Customer: "It appears that the equipment is susceptible to the order that power is applied to the individual units. The original power application sequence was inadvertently changed to one which causes this problem to occur. We have it fully reproduced, and are testing now to determine the optimum power sequence."
Business: "The contactor sequence is not controlled by specification. This introduces risk into the power up sequence. It will take us two to four weeks with vehicle equipment to determine a bullet proof sequence. The customer has provided the assets we need. This will be followed by testing on the vehicle. When we determine the proper sequence, all the power controllers built to date will likely have to be modified. It is the best way to do it, it would be quite expensive to modify all the fielded equipment to remove the risk induced by an undefined power up sequence".
I violated a rule above - which one is it? Look below for the answer.
Keep Going.
The customer definition is too long. How to shorten it is an exercise for the reader.