Steven05
Building High Performance Engineers and Engineering Teams
"Imagine engineers and technical managers, who are
as effective with people as with technology"



STCerri International eZine

"Engineering Buying or Buy-In"
http://www.stevencerri.com                            eZine #40
Greetings!
 
Here is an interesting question:  Is there a similarity between engineering and buying a car?

Now before you say "no", read another paragraph.

Because you might not think that engineering and engineering management have much to do with marketing research but they certainly do.  You see, marketing research has come a long way and there are several conclusions that apply directly to the field of engineering and engineering management, especially in these times when the impact of engineering decisions can have an important impact on everyday life.  

New Scientist
There is a great article in the latest issue of New Scientist.  The article is titled "We have ways of making you buy", written by Graham Lawton.  Graham writes that marketing research traditionally used questionnaires and focus groups to determine why people did what they did.  Based on asking people what they think, they in turn heard what people said.  Over the years it has become clear that what people say and what people think are not always the same.

This conclusion has very important implications for engineering and engineering management.  Engineers and engineering managers may often be saying more by what they do not say than by what they do say.  Reading between the lines can be as important as reading the lines.

In fact, Graham goes on to write, "Its not just that people are inclined to say what they think others want to hear, and to give answers that they think reflect favorably upon themselves...."  According to Gregory Berns, a neuroeconomist at Emery University in Atlanta, Georgia, "...the problem is that much of the decision-making process happens at a subconscious level, and experiments reveal that people are generally not very good at explaining the thinking behind their choices.  Sometimes they simply don't know why they choose things," he says.  "They connect explanations after the fact, or make up explanations that are socially acceptable.."

Functional Magnetic Resonance Imagery and EEGs
Using Functional Magnetic Resonance Imagery (fMRI) and Electro-Encephalograms (EEGs) to look into brains, marketing research is relying less and less on what people "say" and more and more on what their brains "show".

Mirja Humber, a consumer researcher at Zepplin University at Friedrichshafen, Germany, puts it this way; "... most decisions are much less rational than traditional (research) suggests.  We find that emotions are really important.  Even rational decisions are not possible without emotion."

So from the article we can make the following conclusions:
1.  People often have difficulty "articulating" the rationale they use to make decisions.
2.  People often use emotion to make their decisions along with logic.
3.  A purely "logical decision" probably does not exist.
4.  Often an decision based on emotion is supported, after the fact, by logical justification.

Now these four conclusions have some very important implications for engineers and engineering management and for society.  When I was growing up, more than once, I heard my parents say, "If only this world were run by engineers, everything would be much better."  The embedded assumption of course being that engineers are logical and reasonable and would not be influenced by emotion.

The article seems practical
As I became an engineer and as my management career developed it became clear that Graham's article rang truer and truer.  Engineers and engineering managers are people, after all.  However, unlike many other professions, engineering requires us to bounce back and forth from a predominately logical to a predominately emotional structure.  Here is what I mean.

F=ma... Data versus Decision
Suppose I plot a graph of F=ma for a constant mass.  The vertical access is Acceleration and the horizontal access is Force.  For a given mass, as I increase the force, I increase the resulting acceleration on the mass. The graph is a series of straight lines for different masses.  A purely logical application of mind (seemingly).  The graph is straight forward.  The data rules.

But now suppose that the mass represents that of a human being and suppose the acceleration represents the g-forces that an astronaut will be subjected to during a launch.  How do you decide what is the maximum g-force an astronaut should be subjected to?  The maximum g-force a person can withstand is probably a number that varies depending on the person and their conditioning. and a whole group of other parameters  However, a decision has to be made.  It is not a decision that can be made with black-and-white "data" like the graph we produced showing F=ma.  The decision as to what an astronaut should be subjected to is much more emotional, much more a function of judgment than of reason.

In fact, as you think about these two examples, the graph of the data and the decision based on that data, you can probably "feel" something different going on in your nervous system.

In fact, while I do not have "hard" data to support this next statement, my experience seems to bear it out and that is, logical data analysis informs us as to the way the universe works, while our emotions often get heavily involved when we use that data to make decisions about how to apply that data.  That is why two people can look at the same data and come to very different conclusions.

Perhaps more than many other careers, engineers and engineering managers "live" in a world in which people move back and forth between the logical analysis of data and the emotionally-based, decision-making that is based on that data.  This then can be a challenge in the engineering world in which we take pride in our ability to unemotionally analyze the world and yet we are emotional beings as well, driven to make decisions based on judgment.

Tom won't release his software
An example of this occurred with a young software engineer who would not release his software to the customer.  He had been given the task of developing a software interface for a customer database.  The development of the interface prototype, with approval by the customer, comprised Phase A of the contract.  Phase B was the actual development of the software and the interface and the database.  Tom was in Phase A.  He was nearly half-way through Phase A when his manager asked if the software was ready for release to the customer.  Tom said "No, not yet."  

A week later, Tom's manager asked him again if the software was ready.  Again Tom said "No, not yet".  Tom's manager wanted to get the software into the customer's hands and kept asking Tom if the "software was ready?"  This went on enough times that Tom's manager was concerned that Tom would not release the software but would keep attempting to "make it perfect".

Tom's manager asked me to intervene.  He wanted the customer to receive the software with enough time to review the interface structure and send it back in time to make some changes.

I visited Tom and casually asked him what was up?  I also asked him for the status of the software.  He said that the software was not yet ready. 

The question for me was "Is this 'data' I'm hearing from Tom or is it a 'decision'?  If it is 'data' I'm probably not in a knowledgeable position to dispute the data.  After all, Tom is the one developing the code.  On the other hand, if his position is a decision, I may be more capable of influencing him.  But first I must  understand "how" he is making his decision that the software is not ready.

So I asked Tom some questions.  One was critically important and it was, "Tom, what is it you are trying to accomplish by continuing to work on the software?"

If Tom had answered that he had not yet finished certain important subroutines and sub-commands in the code, that would have been a "data" position and I would have asked Tom for a schedule update.

However, Tom didn't answer that way.  His answer was that "He wanted to give the customer as complete an interface as possible so they could give him their suggestions and revisions."  This is a purely emotional decision.  How does one define "as complete an interface as possible?"  Each of us has a different concept of this phrase.

My response to Tom was to deal with the emotional aspect of his decision.  My response to Tom was, "Well you now Tom, if you get the software to the customer in the next day or two, they will have sufficient time to look at your design, give you feedback, you can then incorporate their suggestions, make the necessary adjustments, and get it back to them for one more iteration, giving you even more feedback from the customer.  You'll get two cycles of customer input instead of one."

The customer had the software the next day and Tom got two iterations from the customer.

The conclusion and the question
As engineers and engineering managers we pride ourselves in running on logic.  But many times we also run on emotion.  Knowing when we are in the field of data and when we are in the field of emotion (i.e., decision-making) can be of great help.  Specifically when in the world of emotions and emotional decisions and judgments, it is important to ask questions that expose the "decision-making" processes. 

Direct orders or directive commands can work fairly well when it comes to "data" discussions.  For example, "I want this to be a graph of F=Ma" with the vertical axis Acceleration and the horizontal axis Force."  However, directive commands work poorly when it comes to "emotionally based decisions".  For example, "I want astronauts to withstand 5-gs sustained."  I can see an "heated discussion" coming.

One of the most important questions I ask is, "What specifically are you trying to accomplish by taking this position?"  It is important to ask this question with respect and rapport, but the answer to this question will allow you to see the structure that lies somewhere between the questionnaire and the fMRI.

Be well,

Steven Cerri

P.S.  Feel free to pass this eZine on to your friends.

Note:  If you have missed my previous eZines/newsletters you can find them archived at:  Archived eZines/Newsletters

"eGold" becomes "Connecting With Cerri"
I have received some very helpful feedback regarding the eGold Mentoring program that I am about ready to launch.  Thank you all for your input, your interest, and your questions.

There has been some confusion regarding the name and regarding the availability of the program.  You do not want it to be limited only to engineers who have graduated in the last 10 years so I have decided to open it up to anyone who is interested, not just graduates of the last decade.  I have changed the name from eGold to "Connecting With Cerri".  These are "Group Coaching Teleseminars". 

All pertinent information will be up on my website www.stevencerri.com under the button "Teleseminars" and that information will up by Monday, August 30, 2010 (maybe before). 

Just as a heads-up, the first Group Coaching Teleseminar is September 7, 2010. 9am-10am Pacific Standard Time.  The topic is "How to Avoid Being Micromanaged and How to Avoid Being A Micromanager".   The fee is $57.  You can find all pertinent information and registration links by Monday on my website under the Teleseminars button.

Be well,

Steven Cerri



"Building High Performance Engineering Teams with engineers and technical managers who are as effective with people as they are with technology?"

Steven trains, coaches, and facilitates engineers and technical managers to perform at a highly effective level.  Steven's unique focus is communication, the ultimate and only tool for effective contribution, management, and leadership.  Get Steven's latest thoughts at: http://www.stevencerri.com

"Your technical competence and expertise are a given to me.  What's missing are the communication and influence skills to turn that competence and expertise into real actionable decisions and ultimately results."

I'm sure you'll find the information in this Ezine/Newsletter and other products useful to the advancement of your engineering and/or management career.  Send questions, comments, and suggestions to:  steven@stcerri.com

Copyright©2010 STCerri International and Steven Cerri.  You are free to pass this information on to others and to reproduce it.  If you reproduce sections in whole or part please give attribution to Steven Cerri.  Thank you.

Be well,

Steven Cerri
STCerri International
Steven Cerri
STCerri International
925-735-9500
Visit our website:  http://www.stevencerri.com