What is it about engineering that others really don't get?
I have written/edited a book, Rhetoric for Engineers, that includes nearly ten years of lecture notes on various subjects bridging gaps between topics in engineering and topics in written and oral argumentation. But that the book exists (and for now, anyway, is FREE) isn't nearly as important as my interest in always keeping it up to date. So it's on version 2.0 now and I'm already working on version 2.1.
So what I'm looking for is new questions to answer. New subjects to address. New complaints about communicating engineering concepts to non-technical people, or so-called "soft" topics to technical people.
If you're an engineer, or are otherwise technical in some way, tell me: what topics do you have the most trouble communicating -- and find you have to anyway?
If you're not an engineer, and you need to deal with us (LOL), what topics do you have the most trouble communicating to your own techies?
The current list of topics I deal with (or at least did in version 1.5) is found here: http://www.tcnj.edu/~rgraham/rhetoric/ -- and I'm looking not only to add new ones but to "deprecate" topics that are out of date. So your non-trivial ideas are most welcome, and I am generous with author and contributor credits!
Good Answers (9)
Hello Ron,
Part of what I've done throughout my career is "technology translation" - helping engineers and executives understand each other. I've seen too many situations where engineers can't get their jobs done because management has them sitting in meetings providing basic technical education to the rest of the team. I've also seen engineers frustrated because they know the best solution to an issue but can't communicate it in terms that management will understand and appreciate.
So, there are two issues I've seen that create the most communication difficulties for these two groups.
First, the use of techical jargon that management does not understand. This leaves the managers puzzled, and feeling a bit vulnerable. The managers don't ask questions because they are afraid of looking dumb. So, they stay uneducated and now are also nervous about interacting with the engineer. Sometimes the brilliance of engineers scares other people. So, they need to tailor their message to the audience. (And be patient about it; not everyone is as smart as you - so have some empathy for them).
Second, engineers tend to think of solutions for their own sake. They know the best solution for the issue and communicate why it's superior in technical terms. This is often true - and incomprehensible to management. So, tailor the argument in support of the solution to terms that resonate with the manager. Talk about how it solves business problems, makes customers happy, increases sales, decreases costs, and otherwise leads to outcomes that will make the manager's managers happy. That is what will convince management to adopt your solution more than the technical superiority of the solution.
Hope that helps.
Irene Boland Taouabit
I am a communicator who is often positioned between highly technical engineers and the rest of the world - I am a translator, of sorts. I have deep respect for engineers and make it my personal mission to defend the integrity of the process and methodologies they deploy and the excellence in execution their mechanics can yield.
What I find most challenging is the rigidity of engineering language. I think that in many cases, non-techie folk can be on the same page as the brilliant engineers, but the hang-up on using very specific words to describe very specific steps overrides the ability for the two worlds to collaborate harmoniously toward a shared goal. Take the concept of change management, for example. Ask an engineer and they will wax poetic on six sigma and the 22 steps in this very specific sequence, etc. Ask an OD professional and they'll cite general human change process theories and famous people's names. In reality, both are right and both have a place in the overall change process - at least when both a product and people are involved in the implementation process, which in most cases is the real-life scenario.
Sometimes, the intellect of engineers is a double-edged sword and can create a lot of blind spots to the real-life application of the theories and processes they have to offer. On one level, I have to agree with Richard's point: "Engineers become human tools used by smarter, wiser, people with broader and deeper social/emotional skills." I wouldn't say "by smarter, wiser people" as this is to say that social skills override technical prowess. But, generally speaking, I condone the fact that there is a time and place for engineers - and social representation and salesmanship of engineering concepts by engineers is not one of those places.
Larry J
Consumer Electronics Consultant and Contractor
Best Answers in: Equity Markets (2), Engineering (2), Mentoring (1), Government Policy (1), Offshoring and Outsourcing (1), Organizational Development (1), Quality Management and Standards (1), Product Design (1), Telecommunications (1), Web Development (1)
I think one of the gulfs between engineers and others is the exactness of the language being used.
I will give two real world examples:
1) Engineers often choose their words slowly and with deliberation. Sometimes you ask a question and there may be a noticeable time delay prior to an answer. This should not be taken as a sign the engineer does not know the answer. It may actually be a sign the engineer really understands the subject and is trying to phrase the answer so it can't be misinterpreted.
In a group setting, this can be a real problem, because someone else may throw in their comments before the engineer even gets through their thinking process.
This one brilliant engineer had such a delay, that I developed a technique. When I wanted him to answer a question or comment, I tossed him a marker and declared no one else could respond until he had answered.
This worked very well.
2) I was the leader of a project team with a number of engineers. In one of my meetings, I was going through the list of tasks required. One engineer, I will call him Charlie (not his real name) responded to about every third item. "I can do that".
At the next meeting, I was reviewing progress. Charlie had made no progress on any of his assignments. I said, "Charlie what gives?"
Charlie replied "Yes, I said I can do that." I asked, "How come you didn't do any of these things?" He replied, "I didn't say I would do them, only that I could."
**** Switching gears ****
A) It is amazing fuzzy logic can survive as an engineering technique in a world that is dominated be exactness.
B) Very good engineers strive for perfection. Marketing is often happy with something that is good enough. Great engineers recognize when something is good enough.
C) Engineers often don't recognize what features are important to customers and marketing, but put their own insight into the product. They push for lots of detailed features desired only by other engineers.
**** Switching gears ****
An example I used to use with my engineers was a four legged stool. First I asked what would happen if I cut off one, two, or three legs. It was obvious that these cases would not make a good stool.
Then I labeled the legs:
FEATURES
COST
TIME
QUALITY
Next I said to them, "To have a successful engineering program you must deliver it with all three legs. Features at the cost target and on time with an acceptable quality level.
**** Switching gears ****
Another important communications concept is to communicate in the medium the recipient is most comfortable with. I have found many engineers are much more comfortable in written communication than oral communication. But this is not universally true.
The best solution is to communicate in both oral and written modes. Some may only gain understanding, when they rewrite it themselves.
Those are a few of my tidbits from 30 some odd years in the engineering game.
Larry J Manson
themicrokid at yahoo dot com
As a science communicator I work with scientists and engineers a great deal, as well as with parents, teachers, young people, politicians and many other groups within society.
I've found that if there is one topic which is most difficult to impress on techies, it's this one:
That the end user is the most important part in any equation.
Basically, engineers need to approach a problem from the user's perspective - and check and cross-check that they really understand what the issues are - if they're going to successfully hit the mark. This seems to be difficult for many technical people - after all, they're engineers, not public relations specialists - but is very important to the success or failure of a new technology.
When I work with public audiences, the questions that are asked about the engineers and engineering behind a piece of technology are usually along the lines of:
1. What are they talking about? - this usually means there's technical jargon or language being used, which non-engineering people don't understand. It can also mean that the interpersonal communication skills of the engineer themselves need improvement. Basic skills in plain english writing and speaking are crucial if any expert (engineer or otherwise) wants to communicate with a non-expert audience. Technical instructions written by experts for end users are often hard to read, dense, boring and full of unnecessary jargon.
2. Why is this important anyway? - usually means the work isn't clearly relevant to the audience/user, or lacks any clear social value. Engineering and science communications benefit from being framed in terms of why it's important - who benefits from it, and why the work is being done.
3. Why was it done this way / why doesn't this person get me? - usually means that a genuine interest in the individuals who make up the audience is lacking. It's essential that engineers know who their audience is and why that audience has come to engage with a particular piece of information or product.
For example, if you're designing a new piece of software you first need to understand the old software that your audience uses and learn what they like and dislike about it. Most users are occupied with issues of the aesthetic, the mobile, the useability, the graphic and interface design, the quality of content, accessibility, and the cost as well as the quality of the engineering. You may write a supremely elegant bit of script, but if your interface is clunky, your graphics non-existent, your look uninviting and your structure counter-intuitive, then you'll fail to impress.
Just a few thoughts.
Bobby Cerini
Don't forget the problems that engineers have from the other direction, too: from the scientists, who look down on engineers as being soiled by the concerns of the real world (rather than studying things for their own sake), and hence of dabbling in the commercial world, and at the same time of settling for compromise.
In reality, the act of settling for compromise is the engineers real added-value that he/she offers to the world.
One of the finest examples must be the transistor: neither a perfect digital switch, nor a perfect linear amplifier. It takes an engineer to harness the discoveries of the scientist to leverage sufficient advantage from the imperfect world that workable machines can be constructed that do something useful for the advancement of humanity.
All this to say that engineers fit into the jigsaw of society, along with the scientists, and marketing professionals, and politicians. But I think you knew that anyway :-)
Marion K
Computational Linguist, Ontologist, Writer
Best Answers in: Education and Schools (1), Occupational Training (1), Writing and Editing (1), Career Management (1), Communication and Public Speaking (1), Ethics (1)
This is a great question.
Speaking as an engineer, communication with non-engineers most often foundered when I forgot that I was speaking to non-engineers. There's a
need to switch gears, to generalize over the extremely detailed, multidimensional and highly-interconnected mental picture that I've been working in with other engineers, to create and convey an overview.
Such an overview may need to be missing huge and vital areas of the project, if the non-engineers in question don't need to know about those parts. This can be hard to do. Providing less than a full and accurate account can feel like violating the engineering ethic, and it goes against one's training to a certain degree.
For me the hardest topics to communicate have had to do with the necessity of precision, and that getting the terminology exactly right is critical and actually possible! One of the most memorable quotes I recall from a non-engineer in this regard is, "Gold, silver, same thing."
In presenting an overview to an audience, with luck and practice an engineer will learn to avoid making them glassy-eyed. If most of them glaze over, then the communication is no longer useful. (Because most engineers value usefulness very highly, usefulness can be an effective metric for them to apply to their communications.) Engineers may need to learn how to pay attention to the audience and actually watch their faces--not their shoes, not the white board--and interpret what is going on with them. For many non-engineers these signals from the audience are obvious, received and interpreted without conscious effort; for many engineers, learning to decode them is like learning to read an oracle from from a lamb's guts.
For a technical presentation to non-techies, the point of an overview is to set the stage so that you can go on to address what is actually important to your hearers--with any luck, a good technical manager will already have clued you in on this. If not, you can usually figure it out if you know who you're talking to (your boss' boss? a funding source? a vendor? marketing folks? schoolkids? reporters? actual customers?) Logic can actually be useful here in getting at what's probably important to the audience; when in doubt, follow the money, use shorter words and assume that if anyone wants to know the details they will ask for them. Try to include a Q&A, just in case you totally missed figuring out what they wanted to know.
In my experience it's actually easier to train a techie in the ways of non-techies than it is to train a non-techie in the ways of techies. Also, some non-techies are also latent techies, and if you can spot those folks they can help you in your efforts to bridge the gap.
Speaking as a former non-engineer, once I realized that engineers are tons of fun to be around, habitually act from rational views, think that problem-solving is how to deal with problems, and usually don't notice or care who in the office crowd is in or out with whom, I too became an engineer. :-)
Clarification added April 8, 2008:
Looking at the many insightful answers here, one of the things that leaps out to me is that managers, executives and HR folks would do well to try to avoid becoming a problem to the engineers in their organization. Engineers solve problems.
There are areas of conflict and disconnect in any organization, often around resource allocation. Consistent basic fairness--sharing both the burdens and the rewards--can go a long way toward creating a basis of trust. So can learning to communicate the rational and/or realistic basis for difficult decisions. Engineers understand compromise and tradeoffs. In addition to material rewards, deserved recognition, accurate praise, access to more fun problems and support in tackling them are things that engineers tend to find motivating.
Stevan V
Storyteller, communicator, product visionary
Best Answers in: Events Marketing (2), Business Development (1), Public Relations (1)
As an engineer who went over "to the dark side" and now works in marketing I'd offer the following.
The hardest thing for most engineers to communicate about their product or technology seems to be its value. They, and all of us in high tech often fall victim to this, get so wrapped up in what it does and how it does it that they forget to tell the audience why that matters. Telling the audience that this new computer has "double the clock speed, supports four times the RAM, and has 1 TB of fully RAIDed storage" does not say "you will get your work done faster and everything you store in it will be immune to those scary hard drive crashes you've heard so much about."
Yes, I know fellow techies will infer that value statement from what was said but the audience should not need to do the work of interpretation - value should be made clear snce that is all people pay for. However the customer assigns value, it is value that causes people to open their wallets.
Coming from the other side, of trying to communicate to the texhies, it is often similar. It is often hard to get across what the customer wants in "simple English." Engineers generally need/want to hear about specific features to implement such as faster clock speeds or RAIDed storage when the customer just wants to get the job done faster and might be satisfied with a better keyboard or speech-to-text software to speed her writing.
I believe the crux of the problem is that too many people in marketing and sales do not adequately understand the product and technology and are thus not well able to translate customer-speak into engineer-speak. And I believe that translation to be the single most important one for any marketing person. Just as the techies need to be able to communicate value so too do the marketing and sales people need to communicate customer needs in terms the engineering team can process. Nobody is a dummy, we speak different languages and need to work at making sure the other understands.
A second challengs is in setting development priorities. I have often gone through a detailed presenattion of customer wants and needs only to be met with "Just give us an ordered list of the top ten features you want and when you want to release and we'll let you know how many we can get done." As with the above, communication sins lie on both side of this often yawning chasm. When communication is working well you can get down to discussions like "Hey, I'll gladly sacrifice feature B if we can get features L, M, N, O, and P." That often is the case, drop one or two features that require huge time alltoments and replace them with half-a-dozen that can be done in the time once allotted to the single feature you dropped. Viola! - happy customers. That type of discussion is not "negotiating" or "horse trading." It is maximizing the value to be delivered to the customers.
I hope there's some value in this. One of my goals for retirement is to teach "Marketing for Engineers" at the college level. Here's hoping!
Dear Ron,
I spent the better part of my Master’s degree answering these questions, both from the software development side and the technical writing side. I would like to address the question, “If you're not an engineer, and you need to deal with [engineers,] (…) what topics do you have the most trouble communicating (…)?”
The easiest way to explain my answer is in context. To some extent, both technical communicators and developers are “techies.” Naturally, this is a generalization because many writers really have not worked in the engineering or development field for very long (and we see this with new English-major graduates who go into the field looking for their first technical writing job). The problem is not one of “communication” as much as it is a problem of relating to an external discourse community (i.e., the engineering group versus the technical writing group).
Most engineers and software developers remain engaged in their specific discourse community on the job (for example, they hang out with other developers, speak the same lingo, etc.). In addition, the engineer or the developer is a subject matter expert (SME) who is well-acquainted with his or her product. When the writer (a person who most assuredly does not have a developer’s level of expertise or knowledge of the product) attempts to glean information from an engineer or developer, they are now outside of their own discourse community. The rules are unclear. Perhaps the timing is bad—when is it that the technical communicators start asking questions? Are they at the kick-off meeting, when they are examining the Scoping Document to see how the product will be put together, or is it after the product has been developed and the technical communicator is expected to “pretty up” the engineer’s notes?
Discourse community-related jealousies and idiosyncrasies aside, it will always be easier for an engineer and a technical communicator to exchange information earlier in the project. Barring that, I find that dangling chocolate in front of an engineer while asking questions usually helps.
I would enjoy hearing more about your project.
Sincerely,
Michael David Todaro
I have spent a good part of my adult life around engineers (computer hardware and software) as a salesperson, product manager, marketing exec and wife. I know one of my greatest frustrations in communicating product requirements to engineers was the "can't do that" response, when what they meant was, it will be very difficult, take too long, or cost too much.
Though I have worked with some outstandingly smart and creative engineers, I've also worked with some inflexible and hidebound ones. The word can't should be stricken from the language of engineers, and replaced with the willingness to discuss what the challenges and solutions might be to doing something new or difficult – even when that discussion requires a good bit of education to help everyone understand the issues.
And I know it's an old, old book, but every engineer and non-engineer that has to deal with them should read "The Psychology of Everyday Things" by Donald A. Norman. It helps to understand that the mental model a non-engineer develops of how something works can be very different from the Engineer's understanding of how that same something actually works. Without that understanding, and engineer can never design a product that will satisfy the average consumer.
More Answers (19)
James M
Technology Support Representative, Sr. at Orange County Public Schools
Best Answers in: Education and Schools (5), Staffing and Recruiting (5), Career Management (4), Organizational Development (3), Using LinkedIn (3), Mentoring (2), Business Development (2), Professional Networking (2), Blogging (2), Computers and Software (2), Facilities Management (1), Job Search (1), Personnel Policies (1), Public Relations (1), Change Management (1), Labor Relations (1), Manufacturing (1), Quality Management and Standards (1), Starting Up (1), E-Commerce (1), Enterprise Software (1), Software Development (1), Web Development (1)
I have heard several sales people say that engineers are the single most difficult group to sell to.
I do beleive that this is true becasue most engineers will know more about the product than the sales person that is selling it. Slick sales tricks don't work on engineers, because they see right through them.
I have also noticed that engineers are more likely to do things themselves rather than hire an expert to do it. As an engineer I have installed plumbing, electrical circuits, drywall, ceramic tile and hardwood flooring in my home.
Miccilina P
Writer/Author/Poet; Educator with Marketing/PR , Editing, Copy/Ad, Non-Profit & Cust Svc Experience.
Best Answers in: Career Management (4), Using LinkedIn (4), Government Policy (2), Government Contracts (1), Criminal Law (1), Public Relations (1), Writing and Editing (1), Organizational Development (1), Professional Networking (1), Computers and Software (1)
Ron: When I worked for a Construction firm in San Diego, working with the engineers was actually alot of fun - they can do the neatest things with stuff just lying around - we had miles of laughs and lots of Hmmm, moments that I can remember. Engineers are geeks, yeah, but they are interesting geeks! At least that is what I found - I don't have any trouble speaking engineer - you just have to make sure to pronounce the terms correctly and they are grateful that you care! LOL Micci
Richard T
Experienced Moron & Tedius Narcissist: wish to set up Excellence Science & Creativity Colleges via new PHD job in 2011
Best Answers in: Education and Schools (10), Organizational Development (7), Change Management (6), Career Management (5), Professional Books and Resources (4), Business Development (3), Ethics (3), Using LinkedIn (3), Occupational Training (2), Staffing and Recruiting (2), Internationalization and Localization (2), Communication and Public Speaking (2), Purchasing (1), Air Travel (1), Car and Train Travel (1), Freelancing and Contracting (1), Job Search (1), Mentoring (1), Financial Regulation (1), Advertising (1), Graphic Design (1), Corporate Governance (1), Labor Relations (1), Non-profit Management (1), Social Enterpreneurship (1), Project Management (1), Supply Chain Management (1), Personal Investing (1), Branding (1), Product Design (1), Professional Organizations (1), Professional Networking (1), Biotech (1)
It is not a matter of rhetoric or language or "communication" skill. It is a matter of social skill, social interest, emotional interests, and excess maleness of environment, career, and genetic endowment. Engineers become human tools used by smarter, wiser, people with broader and deeper social/emotional skills. The flight of young men to "things" and "machines" and "logics" is fleeing--refusal of parts of life that are all important and set the context for most technologies and when and how they get used/commercialized. Engineers turn themselves into human narrow tools because they flee, like cowards, from important parts of life.
Some of the dumber ones try to justify this by extollling their own technical virtuosities, but most just quietly and neurotically get used all their lives by smarter, broader, deeper, more emotional, more social others. MIT grads end up all working for Harvard bosses!!!!!
So giving engineers skills for expressing things is pointless--they fled from having anything emotional and social to express!!!!!!!
Katey D
Design Professional
Best Answers in: Using LinkedIn (3), Freelancing and Contracting (1), Job Search (1), Professional Networking (1)
The engineers that have been easiest for me to work with understand that the end-user's mental model and the engineer's mental model are not the same. And they are willing to work with a designer or another intermediary to allow their technical expertise to be elegantly translated into something a user can understand and enjoy! An example would be engineers mental model: MSDOS, user model: windows. Ok, maybe that's not a great example, but I hope that clarifies what I mean!
When engineers "get it" we get awesome new technology and gadgets to play with. When they don't, people can feel overburdened by new technology or innovations.
Hope that's useful!
Joy M
building your business system so you can build your business
Best Answers in: Using LinkedIn (6), Staffing and Recruiting (2), Public Relations (2), Manufacturing (2), Professional Networking (2), Job Search (1), Mentoring (1), Occupational Training (1), Foreign Investment (1), Personnel Policies (1), Events Marketing (1), Business Development (1), Search Marketing (1), Writing and Editing (1), Corporate Governance (1), Planning (1), Philanthropy (1), Supply Chain Management (1), Branding (1), Market Research and Definition (1), Engineering (1), Interface Design (1), Career Management (1), Ethics (1), Small Business (1), Databases (1)
I enjoy working with Engineers and have notes for an eventual book on effective communication for engineers and programmers (only because engineers and programmers have often asked me for input). What is fun is their passion for, and ability to focus so perfectly on, finding solutions. Maybe we should be electing them to public office.
Hi Ron,
My firm (advertising & PR) works exclusively with technology companies that market to engineers. Over the years, we have conducted several "psychographic" studies of engineers, trying to understand who they are as people and what makes them tick. And, being marketers, how to best communicate with and influence this smart, quirky group. Last year, we extended the study to China, so we now have information about what makes Chinese engineers tick and the ways in which they are similar and different to their North American counterparts. The study is free and available on our website if you'd like to take a look. If you'd like to discuss further, please let me know.
Links:
The biggest problem I run into is articulating requirements. Many non-engineers see things that exist and say "well this company did this, that means you can too". They fail to recognize operational and research and development costs realistically because they don't understand the concepts.
I am more into software engineering so I may see this more than in other fields. So many non-technical people hear a story of a teenager developing some product and thus believe everything like it should be made cheaply. They don't understand all the aspects that make these things "go" and base their judgments off of a poorly degraded media that covers them.
Alex D
R&D Scientist at IPEX Inc.
Best Answers in: Internationalization and Localization (1), Supply Chain Management (1), Using LinkedIn (1)
Ron, consult this handy managerese-to-engineerese “dictionary” for the true meaning of some business directives which spells out the difference between manager speak and engineer speak:
When Managers Say...
Engineers Hear
Challenge...
Dirty job that nobody else wants
Advise...
Order
Ambitious...
Unlikely
Aggressive...
Very unlikely
We couldn't reach a consensus...
We're in total disagreement
Encouraging process...
No tangible results
Historical...
Nobody remembers why
Contribution...
Anything a manager likes
Leverage...
Borrowing someone else's problem
Opportunity...
Problem
Learning experience...
Mistake
Diagnostics...
Something that might give us a clue
Controlled introduction...
Let the customer do the cost analysis
The project has been elevated to management level...
It's dead
Dynamic...
Unstable
Positioning problem...
No one will buy it
Quality...
Japanese; otherwise not well-defined
Functionally complete...
Can do something that appears to work
Scenario...
Fairy tale
Strategy...
What we tell ourselves we are going to do
Strong personality...
Intolerably obnoxious
Strongly encouraged...
Ordered on pain of death
Project transfer...
Start project over again
Time frame...
A period of time in which something will not occur
We...
You
Source: "Lost in translation" ThomasNet
Links:
Michael E. P
Published author & writer
Best Answers in: Writing and Editing (5), Accounting (2), Travel Tools (1), Mentoring (1), Small Business (1)
Michael E. P suggests this expert on this topic:
Bart is a writer, photographer and a PE. He was selected Army Engineer of the Year last year. I suggest you contact him.
Kristen F
Sourcing Recruiter - UW Medical Centers at University of Washington/Harborview Medical Centers
Best Answers in: Staffing and Recruiting (8), Job Search (5), Mentoring (3), Career Management (3), Resume Writing (2), Ethics (2), Change Management (1), Wireless (1), Using LinkedIn (1)
As a technical recruiter, I need my hiring managers to be able to tell me from a layman's perspective how something works in the least number of words. Explain it to me as you would like the marketing message sent to the public at large.
Jessica G
Software Engineer at Google
Best Answers in: Economics (4), Career Management (3), Government Policy (2), Employment and Labor Law (2), Internet Marketing (2), Equity Markets (2), Personal Debt Management (2), Software Development (2), Web Development (2), Using LinkedIn (2), Travel Tools (1), Personnel Policies (1), Internationalization and Localization (1), Offshoring and Outsourcing (1), Intellectual Property (1), Advertising (1), Writing and Editing (1), Planning (1), Pricing (1), Ethics (1), Biotech (1)
I think the hardest thing for engineers to get across to others is that we can only build what you want if you both know what that is and tell us it.
Too often we are expected to mind-read what people want or are forced to guess at what trade-offs are desired. If you don't know what you want, how are we "social inadequates" supposed to figure out what you want? Along the same lines, new features and changes will make a project take longer. There seems to be a real problem with magical thinking.
Additionally, the lack of social skills bit is horribly overstated. Engineers are more likely to be introverted, but most have rich lives with deep interests in and out of their field. I don't many fields where so many people have the time and money to get into rock-climbing, surfing, travel and social causes.
We know the basic psych tricks used by poor managers and marketers and they annoy us, to put it mildly. We do notice when we don't get bonuses and the CEO or boss does, and we tend to vote with our feet rather than get jerked around by more empty promises. It is called impatience with interpersonal manipulators. If that falls under poor social skills, it is at least a technique that has served us well as a group.
Jason H C
Friendly Neighborhood Software Engineer
Best Answers in: Enterprise Software (3), Software Development (3), Web Development (3), Wireless (2), Venture Capital and Private Equity (1), Starting Up (1)
My all time favorite is, "why will it take so long, all you have to do is..." As an engineer, this isn't the nails on the chalkboard, it's the dentists drill hitting the root without anesthetic.
I don't know that the statement is intended to be offensive. I think that for non-technical staff, and worse yet pseudo-technical staff, it sounds like a perfectly reasonable question.
It is also probably pretty effective at frustrating an engineer into silence because it provides a unique uncrossable chasm where if the answer were to be explained would not have much bearing because the non-technical person is at the peak of their technical understanding of the question and the engineer really has no way to put it into terms that are consumable by their audience.
A number of years ago, I heard of this interesting thing called the "introvert /extrovert paradox." You'll have to excuse the generalities, I am going to try to explain it the way that it was explained to me.
Generally the people who really excel at management/marketing/sales are extroverts. This ability to relate well to others allows them to motivate the people around them and communicate with their superiors and customers.
Good technical staff is usually introverted, and because of this, they are very good at working on complex problems because they are without the need for affirming interaction from others, their work functioning as required is that affirmation, and speaks for itself. But when a conflict arises and comes to an impass a paradox forms.
The introvert will usually stop talking at their pinnacle of frustration, assuming that silence is a clear indication that they are done talking. An extrovert will usually want to pursue an issue until there is no more discussion, assuming that if there were additional unresolved issues that they would be voiced.
Because of this when the two leave the encounter, they have two totally different views of whether or not resolution was reached.(* I do owe someone credit for this, and my apologies if you are reading this)
The statement posed at the beginning is a statement that I personally feel short circuits the loop completely. It's a quick way to frustrate an engineer into silence, and, after they are silent, it's interpreted by the manager/PM/marketing/sales person as an affirmation of the fact that the engineer was just over-complicating things in the first place.
Tim B
Architect at Science & Technology foundation
Best Answers in: Change Management (1), Career Management (1), Enterprise Software (1), Databases (1)
As an I.T. systems engineer I am increasingly frustrated by the lack of a job title named as such. It seems these days we have business analysts communicating with developers (programmers). However there is a large gap in the middle that used to filled with clever characters named system analysts. These people can speak both languages and usually become key to successful systems. It maybe in asking this question that we can see that these people are excluded from the modern day project set up. I think possibly the accountants running projects these days see them as an unrequired expense and cause the question to be asked.
I figured out some time ago that, when I'm writing for a target audience of engineers: to them, the journey is the destination.
The question "What is it about engineering that others really don't get?" closely resembles the famous Freud remark, "What is it that women want? 'Appiness, that is what a woman wants."
If by "others" you mean non-engineers, may I suggest that everyone "engineers." Physicians "engineer" surgical procedures; Accountants "engineer" audit trails; Attorneys "engineer" litigation; Educators "engineer" curricula; Politicians “engineer” campaigns, etc.
What "others" do not get is why anyone would voluntarily choose engineering. Some students leave engineering early in their studies because other majors require less effort leaving more time for social activities. University settings tend to revere classical studies and relegate technical studies to an inferior status. Perhaps this distinction initiates geek separation. Does Oxford even have an engineering curriculum?
With apologies to the many talented female engineers, men cannot give birth and contribute to human survival by empowering creation of structures and machines applying historical knowledge and accomplishment.
Engineers rely on Rudyard Kipling’s “… six honest serving-men (they taught me all I knew); their names are What and Why and When and How and Where and Who” for inspiration and guidance. Non-engineers might refer to Beethoven's response to people who questioned what he was doing "They are music not for you, but for a later age” and "Do you suppose I consider your wretched fiddle when the spirit moves me?" for insight into engineering arrogance.
As evidenced by engineering failures, Mother Nature does not forgive. When a blueprint fails to convey construction details accurately, misinterpretation can be costly. Thanks to engineering standards and methods, industries worldwide can produce and share goods and services successfully. When MBA’s fail to foster communication with technical staff, Challenger disasters ensue.
"What is it about engineering that others really don't get?" Others don’t get motivated to value engineering for its essence. Maybe they do not need to and maybe engineers would rather they do not.
I think that the issues at hand can (and need to be) boiled down to one essential concept: the natural "impedance" between linear and non-linear communication.
To give both engineers and non-engineers a break, nature struggles with this, too. How nature has "solved" this engineering task is by separating highly-developed linear thinking (left-brain skills) and non-linear thinking (right-brain skills).
A similar metaphor exists, of course, for "conscious mind" (highly linear) and "unconsicous mind" (highly non-linear).
It's important to recognize that the underlying mechanism in the form of the human brain is most efficiently constructed for non-linear processing, as described in the book "Blink." Even the highly linear engineer is using an underlying foundation of non-linear processing...so it's not at all like they're incapable of embracing the concept.
Engineers notably are most uncomfortable -- as indicated in some of the above comments -- when it seems to them that someone can't describe what they want, whereas in fact the person doing the description may be doing it in a highly articulart, but non-linear, way.
The most capable engineers recognize the situation for what it is and make the effort to develop their non-linear communication skills, e.g., via drawings, physical models, "object-oriented" software designs, etc. Speaking frankly, the least capable engineers arrogantly (and incorrectly) presume that the communication disconnect is "the other guy's problem." In continued frankness, I sense more than a little bit of that in the question as-formed.
Word to the wise: As noted in "A Whole New Mind," we are entering a post-information, "conceptual age", wherein right-brainers will likely rule. This is already in evidence in the U.S., which is outsourcing nearly all linear/procedural jobs to foreign countries. Sure, there is a non-linear creative act in every engineering effort...but if your specific engineering job is highly linear and procedural, you may well want to consider other alternatives. The world is full of them.
Links:
- http://en.wikipedia.org/wiki/Blink_(book)
- http://books.google.com/books?id=LrIzAAAACAAJ&dq=A+Whole+New+Mind
- http://en.wikipedia.org/wiki/A_Whole_New_Mind
Clarification added April 9, 2008:
A good article by the same author as "A Whole New Mind" is listed below. It comes via "Wired" Issue 13.02, and is titled "Revenge of the Right Brain."
http://www.wired.com/wired/archive/13.02/brain.html
Hi Ron,
I would like to receive a copy of your book. But here comes my question: How do you talk to engineers who are not talking the native language? So (in my case) both speak English (more or less) but one is Italian (the Engineer) and the other person (German) is a businessman.
I am looking forward to hearing from you.
Best regards
Peter
Shanice W
Computer Science and Mechanical Engineering Teacher at Prince George's County Public Schools
People look at me funny when I read the definition of recursion. recursion - see recursion. Or they look at me funny when I read there are only 10 people in the world. Those that understand binary and those that don't.
I have trouble communicating protocols and the need for standards. I believe if people truly understood the need for standards those people will be able to grasp other concepts. I teach mechanical engineering and the biggest problems comes when students do not have the requisite math skills. Also, some students are not able to conceptualize the different branches of engineering or the core technologies.
Peter P
Independent Marketing and Advertising Professional
Best Answers in: Advertising (8), Internet Marketing (2), Compensation and Benefits (1), Business Development (1), Writing and Editing (1)
What they don't get is why an engineer would ask other engineers what non-engineers don't get. Get it yet?
