Communication skills 20

[ParabolicTet]

My obervation is that good communication skills are much more valuable than technical knowledge. Typically an engineer with good communication skills will always move up fast no matter how weak their technical knowledge is. These are the ones who dominate meetings with non-value added comments that just state the obvious.

For example in a technical review they will bring up the simplest and lowest priority issues to discuss and waste 20 professionals time. Why do these engineers get so far and why is their non-value added chit-chat so respected by engineering managers?

Personally I speak only when I feel the team may be overlooking something. I never waste people's time with trivial comments that can be addressed one-on-one.

I need to learn to speak up more but first I would like to understand why technical knowledge ranks so far behind good communication skills? In fact I believe strong technical knowledge is actual a liability in the engineering world. This is because you analyze things from a different perspective from these technically inept engineering managers. As a result you either end up confusing them or annoying them by not following conventional analysis methods.

Your thoughts and experiences?

http://web.peoriadesignweb.com/eos

 

[CARF]

Parabolic,

Here is a must read book that I think will help you:

http://www.pubs.asce.org/BOOKdisplay.cgi?9991759

see also: thread731-82411

Good engineering skills + Good communication skills = Authority (not arrogance!).

Engineers with autority will be listened to, up to the highest worklevels. Even my boss listens to me (now and then)altough he still loves most to hear himself talk ; )

PS. Real detailed engineering stuff we discuss (and decide!) without the management, this speeds up projects dramatically.

Hope this helps,
Carf

 

[Gate2wire]

Parabolic - Before you read this make sure that you are open and non-defensive:

I sense your yearning to communicate better (because you see that it makes a difference) but your pride has attached good communication to inept engineering because you are a great engineer that hasn't honed his ability to influence a target audiance with your words.

I can give and keep my word to my 4 year old daughter 19 out of 20 times. When you ask her if I keep my word - she might say no - because she only remembers the one time that I failed and didn't. The same is true of all people - it's not what reality is, it's how it occurs to people. And, communication occurs to people more powerfully that actual reality.

You're a great engineer - you already know that. A fraction of the population understands that language of engineering - the rest do not and they are the ones that we engineer for.

Gate2wire

 

[GregLocock]

Vaguely on topic:

Every year or so I write a forty or fifty page report, going in to some technical aspect of whatever I am working on to the Nth degree. These get issued, and nothing much is ever heard of them again.

So, just last week, I decided on a new approach. Shorter, more pictures, few equations, and a bit more of a story.

Result: 1 phone call and 3 emails, in the first 2 days, all asking relevant and detailed questions, ie they'd read it and understood it. Also requests for about a month of follow-up work, which would be just great if I was paid by the hour!

I think participating here, on eng-tips, has helped a lot with my writing style.



Cheers

Greg Locock

 

[IRstuff]

One thing that I've learned is that you should start pretty much any communication with a short summary, no more than 2 or 3 paragraphs.

If the reader gets interested, they can then slog on through the rest of the stuff.

The lazy reader will have at least read your talking points.

Conclusions are OK, but many readers are too lazy to slog through the whole thing and will often wind up not reading any of it.

TTFN

 

[Jaq]

IRstuff

I quite agree, a lot of the reports I write are a record of what has happened for the technical departments as well as communicating the results to a wide audience. I always use as many pictures as I can, try to move technical data nto an appendix and have a front page with just a summary of what I have done and what I have found. I find that evryone reads the front page, then skip to the bits that answer the questions they have. Since doing this I get far fewer silly questions that are clearly answered in the report and better feedback.

It is true, people will not slog through an entire report unless they absolutely have to.

Take care,
Jaq.

 

[jmw]

Greg,
you mut have read my thread (Your new pet etc.) in the language forum!

JMW

http://www.viscoanalyser.com

Eng-Tips: Pro bono publico, by engineers, for engineers.

Please see FAQ731-376 for tips on how to make the best use of Eng-Tips Fora.

 

[pmkPE]

Know your target audience. To know them is to know what they can and most likely do not understand. Speak (or write) accordingly so that they understand what you are trying to present.

When we as engineers write a report we are putting part of ourselves part of our lives into the report/design/analysis etc. We, as everyone else in the world, wants to be appreciated - did you catch my details on page xxx? Don't you like how I arrived/deducted my conclusions and recommendations? Don't you think that I should be the one to contact when you need to know something in my field? Everyone wants pretty much the same thing, to be loved, liked, respected, appreciated, etc. But we are not all alike. Some engineers are purely technical and very much enjoy reading details and theory written by others as well as their own publications and reports. Others do not. That does not mean that they are not necessarily incompetent; they have different reasons for listening to our presentations or reading our reports. Know what that reason is.

Communication is being able to relate to specific as well as different people and or groups at appropriate times. When we attend a meeting - what is the purpose of the meeting and who called it? Perhaps that chairperson is the target audience and we should address their wants or needs (with respect to the company business at hand). They have the responsibilty for the meeting agenda it is our responsibility, if we are on the same team, to help them achieve those objectives. If they have done a poor job at stating what the objective/agenda of the meeting is then each of us should try to help define that objective/agenda, get the meeting going and move on. I once attended a toast masters training session and learned that to be effective you have to understand and focus on what your target audience came to hear/wants to understand on their level. It was very worthwhile.

There are some excellent posts in this thread and I belive they have a common thought and that is to be positive, succint and to the point.

 

[toolmantwo]

OK for Jaq, would you not agree that any professional should have the professional courtesy to read all of any document that they receive if they are expected to interact with or approve or use this document to make recommendations? I think it is just sloppy practice to only read part of a document from an associate within the same company. Would you not expect to have a Lawyer read all of a document before he gives you advice? Would you want your Doctor to read your entire chart before prescribing new medication? (Not a personal attack, but just setting up an argument for the thread).

On the flip side, if the person does not need to read any of the documents or if they only need to read part of the document how valuable is this person to the company? For example if the party does not need to interact, approve, or use the document to make recommendations why are they reading it in the first place? Are they wasting company time and money reading something that cannot benefit the company? If it is true that they only need to read one segment of the document it could be formatted better or trimmed down which would save the company money in the long run.

I attended a writing clinic recently and the things they stressed were to know your audience and to reach an agreement with your manager on what and how to present documents to other parties. If this is not agreed upon with your manager you can be in the position where one party is fine with what is presented and the other party thinks it is poor or too long or too short (incomplete). I feel it would take much too long to try to please all parties and they will evolve at the same time to expect a different format and contents while you are in the process to improve your written documents in the attempt to please all parties.

P.S. just FYI my manager still has not agreed upon what to present and did like the idea to standardize our engineering documents, yet has not found the time to complete this task.

 

[jmw]

Toolmantwo,
I would agree entirely that that should be the expectation but that is not the reality.

In practise I find that if you want action you need a simple executive summary.

The explanation or discussion that follows are often only there for protection. You said it, it justifies your recomendations and findings. It isn't esential that anyone reads it if they are prepared to act on your recomendations.

So it depends what you have written your report to do, if it is documentary or for recording purposes, it doesn't matter who reads it now. If you want action (or if you want to discourage action) your report has to be written so that it produces the desired result. If that means that management must make decisions, and management don't have the time or the necessary technical knowledge to make a decsion based on the technical information you provide, then you present the recomendations, suitably worded, in the exectutive summary. Ideally less than half a page.

Graphs and diagrams, any visual aids included in the body are of great value, not just because they aid the clarity but because they can be mined for presentations at management meetings.

PS while much of what I said in my post referred to above was somewhat tongue in cheek, the core truth remains, "what do you want your report to do?" and how do you achieve your objective. It is more than just regurgitating everything you know, it's also about understanding how decisions are made and what will or won't be read.

In any presentation, well constructed and presneted, the average retention is around 10% which may fade with time. So why give presentations? why write reports? because decisions are often made for emotional reasons not logic. Your reports and presentations build a reputation for you that conveys confidence in your abilities. Management then find it much easier to make the decisions you want if they trust you. It has very little to do with whether they understand you or the detail you present.

If you make the decisions, who are you writing the report for? Just announce your decision.

JMW

http://www.viscoanalyser.com

Eng-Tips: Pro bono publico, by engineers, for engineers.

Please see FAQ731-376 for tips on how to make the best use of Eng-Tips Fora.

 

[Sparweb]

The engineer who puts the approval on my work hasn't the time to read the whole thing! We have to trust each other, and it is in fact through verbal discussions that he assures himself that I have done a complete job. It has been a long road for me, steering away from writing elaborate reports with infinitessimal details, when all I'm writing is a document that a bureaucrat will file away. Real progress on many things I do occur in face-to-face meetings (I find the 1-to-1 kind can be very productive) or just on the phone. Both require enough wits to analyze facts, make arguments, and establish trust.

Similarly, when I'm doing research, I can't read every detail on every document I reference. That would waste too much time on irrelevancy. I have on some occasions missed important details, but by admitting to it honestly I only lose face, not others' trust.

When preparing for a presentation, practice on someone who will tell you when your logic is falling apart. If your audience is technical enough to follow, then your credibility is shot if you make a mistake.


Steven Fahey, CET
"Simplicate, and add more lightness" - Bill Stout

 

[pmkPE]

toolmantwo,

In the chain of command in any business people have been selected based on past performance and interaction with those making the decision. If a brand new engineer starts at a company, as an EIT, straight out of college, yes those in responsible charge of that persons development and work will need to throughly review all of that person's work. After time and as the person has shown the appropriate development, those in charge know what questions to ask, they will not be AS questioning of that person's work. An experienced engineer, having the right background can tell when things are "right" without going into the details; the same holds true for when things don't add up; just because those that are in responsible charge have seen and designed something similar many times before. Also remember that there is a relationship between the two unlike your example with the attorney or the doctor that is reading your history for the first time.

I write reports for clients and my first page past the cover and table of contents is the Executive Summary. This lists the client, the reason for the report, a brief summary of the findings when needed and the conclusion(s) and recommendations. The rest of the report, should they care or even have the time to read, is my documentation of my efforts and those of my associates: What was done in SUFFICIENT detail, the procedures, methodologies, findings (in greater and sufficient detail for those that would most likely question it) again the conclusions and recommendations. Appendices would include drawings, photographs, calculations whatever is pertinent to the final recommendations and conclusions. If the Executive Summary is read by a principal in my firm - they have sufficient knowledge of my abilities that they do not have to verify by reading every little detail. As experienced engineers, they can tell by the Executive Summary and by being aware of the project what the prime issues are. I am not offended that they don't read everything, they have plenty to do to keep the company profitable. They do need to read the Executive Summary because they are responsible for what is issued by the firm.

Now attorneys will read the entire report, because it is their job to find out what the weaknesses and the strengths of the report/study are. They also will spend much time interviewing authoring engineers to understand what the report and key considerations are. And we as engineers have to educate the attorneys about the nuances and complex issues because they are not familiar with our discipline and therefore do not always know what is important from our perspective.

Regarding who reads what, as it has been said it depends on who your target audience is. Keep in mind that there often can be other audiences that will be interested in some if not all of the report.

 

[schwarz]

I looked at the original post of ParabolicTet "good communication skills are much more valuable than technical knowledge"
Communication skills are very important as one goes up the ladder, however good communicator is not necessarily technically weak. In fact if you are technically sound you will be more effective communicator in your domain. I however agree that one should speak only when one can add value.

As a manager one has to lead a team ( engineers and maybe others from finance and commercial background)and needs to communicate effectively . Preparing technical proposals /presentation for customers or a project plan, quality analysis, test plan, engineering drawing - in fact all activities require good communication skills -written or verbal. In my place we interact with customers on e-mail without one-to-one meeting for years.

For those who are not comfortable in communicating it helps to do home work, understand audience,do trial run, and being early for meetings. If you have really important to say and have done all the ground work audience will LISTEN. Be interactive , make people part of the process.
For written reports summary report is must, a short well organised report with substance ( that is where tech knowledge counts ) is preferred over lenghthy useless stuff with dozens of graphs and lists. Keep all detailed papers ready with you in case anyone is interested.

I have some conviction in saying above as I have risen from being a R&D Engineer( still a techie at heart) to middle management and good communication and good tech knowledge have always helped.

Good Luck.