by Dan Heisman (Dan was the Quality Manager at Intermetrics about the time of this article's publication)
First published in the Oct 1990 issue of IEEE Spectrum Magazine.
This article was re-printed on two additional continents.
While the business world is driven by success, not every project succeeds. Engineers also reach for success, but not everyone succeeds, either. But failure, whether real or apparent, may often be prevented by a little management foresight. Managing people is not an exact science, and sometimes just the awareness of potential problems will help a manager perform this art more effectively.
We'll examine here nine reasons why good engineers may fail (We know why bad ones do). We assume in all cases that the engineer is competent and has basically a good work ethic. Not all of the following cases are independent, and often more than one may apply in a situation.
1. Lack of the correct prerequisites
Imagine being asked to take Russian III without Russian I and II. Or how about Advanced Integrated Circuits without Introduction too Electricity? Both are cases of lacking a serial prerequisite.
Examples abound in engineering projects. Someone may be hired with training in signal processing when what is needed is at least five years experience designing underwater acoustic signal-processing algorithms for parallel processors.
There are also parallel prerequisites. An engineering position may be given to someone with "a degree in an applied science with seven years experience in FORTRAN," when the company actually needs someone with an engineering background who has patience and the communication skills to babysit customers as they define their requirements.
All too often the following is heard, "He's got seven years' experience and/or he's a quick learner, so he should be able to pick it up quickly." Such assumptions pressure the employee to learn Russian I and II in three weeks. While many are willing and able to rise to the challenge, even the best-intentioned may fail.
2. Unrealistic expectations
Here, the belief is that an engineer with a good reputation can do anything. But not every engineer is a jack-of-all-trades or can pick up any assignment.
For example, an engineer might have had thermodynamics and power in college and done well in both. He or she also did well in a first assignment in power, but may have no interest in or feel for an upcoming thermodynamics project.
For senior engineers, the problem can be even worse: a series of successes in good situations may be followed by either a bad situation or a promotion involving the Peter Principle (where one rises to one's level of incompetence). Either may lead to a failure that will unjustly damage a hard-earned reputation.
3. Narrow skills
This is the final variation of the initial theme. The engineer is great as long as he is left in a field in which he feels secure, for example, COBOL programming on an IBM mainframe. In an extreme case, given an assignment outside this haven, he may even want to fail so that he may retreat to his prior, safe, work.
Of course, most engineers do not wish to fail, but the anxiety of stepping into a new area or the lack of prerequisites mentioned in situation #1 may be hard to overcome. The engineer's knowledge and skills may both be oriented toward one special area, and he or she may be much less valuable elsewhere, maybe even less valuable than a recent graduate.
4. No buy-in established
When an engineer is assigned to a project, the manager should establish the benefits to be gained by that engineer from the project's success. Those benefits should include sharing credit. A manager who takes all the credit for success - and, even worse, spreads all the blame around (to others) for failure - will find it hard to get troops to follow him onto the front line.
Each manager should also back up this promise with action, especially "behind the employee's back." Everyone likes hearing from third parties that they have been credited with a success. Conversely, many become suspicious if promises and praise are given in private and not in public.
To maximize the chance of success, an engineer must "buy in" to a project. As in the "win-win" sales philosophy, the manager wants to create a situation where the engineer, the customer, and the manager will all come out ahead if the project succeeds.
5. Interference by personal feelings
Lower-level managers seldom have full control over who is assigned to their projects. And not everyone gets along well with others.
For example, some engineers work in "spurts" because they have lower attention spans and/or less stamina. For boring jobs, these spurts may be short, while a fascinated spurt worker may have to be fed at his workstation to prevent starvation. Often these spurt workers may be seen taking a break or talking with others (who may not be spurt workers).
If measured by the bottom line, the spurt worker's output may be well above average; however, the manager may perceive his work ethic as being flouted. Unless very perceptive, the manager may become antagonistic and let hostility cloud his or her judgment of the other's performance.
And even a perceptive manager may unrealistically believe that hammering away at such engineers' work ethic and chaining them to their desks will make them more productive. Of course, the engineers almost always resent this intrusion on their natural pace and will inevitably work less, not more.
It is also possible the manager may not like such an engineer for other reasons, including habits, looks, attitude, nonverbal signals, background, and so on. In any case, the engineer may not get a fair chance and be branded a failure.
6. Expectations of failure
A psychological study once separated some elementary school children into two groups. The first group was treated normally, but the teaching of the second - of equal aptitude - were told at the beginning of the school year that the students were slow starters but had become more receptive toward the end of the previous school year. The misinformation became a self-fulfilling prophecy. The second group's grades reflected a slow start followed by a strong finish, whereas the grades of the first group held steady throughout the year.
Similar conditioning may occur with engineers. An engineer may come from a bad situation, and have unfair blame laid on him or her by the previous manager. The new manager begins with low expectations from which it may be impossible for the engineer to recover.
7. Prejudicial first impressions
First impressions can be strong. One way they hurt is by hindering the natural improvement process. A manager has to let an engineer learn from mistakes, not by curtailing the engineer's risk-taking, but by encouraging it.
For example, a young and inexperienced engineer making a technical presentation to a customer might, understandably, make mistakes. A good manager would point out what the engineer did correctly, while making constructive suggestions on what to improve. But all too often the engineer might not be given a second chance to make a presentation because the manager thinks it is "too dangerous."
8. An unrealistic situation
A project's schedule and requirements may be more unrealistic for some assignments than for others. However, the manager may presume that each assignment is equally clear and reasonable. For the engineers with the less realistic schedule, the failure of the manager to recognize the difficulty of their task may be held against them.
9. Perception vs. reality
Often, by an objective measure, the engineer's task or project has been handled successfully. For example, working in a difficult situation, the engineer either missed an unreasonable schedule only narrowly or made something useful out of poorly drafted requirements. Or the success may be unqualified: the engineer met all requirements and succeeded wildly beyond anyone's (except, perhaps, the manager's) dreams. Yet, for whatever reason, the manager did not get the message.
First published in the Oct 1990 issue of IEEE Spectrum Magazine.
This article was re-printed on two additional continents.
While the business world is driven by success, not every project succeeds. Engineers also reach for success, but not everyone succeeds, either. But failure, whether real or apparent, may often be prevented by a little management foresight. Managing people is not an exact science, and sometimes just the awareness of potential problems will help a manager perform this art more effectively.
We'll examine here nine reasons why good engineers may fail (We know why bad ones do). We assume in all cases that the engineer is competent and has basically a good work ethic. Not all of the following cases are independent, and often more than one may apply in a situation.
1. Lack of the correct prerequisites
Imagine being asked to take Russian III without Russian I and II. Or how about Advanced Integrated Circuits without Introduction too Electricity? Both are cases of lacking a serial prerequisite.
Examples abound in engineering projects. Someone may be hired with training in signal processing when what is needed is at least five years experience designing underwater acoustic signal-processing algorithms for parallel processors.
There are also parallel prerequisites. An engineering position may be given to someone with "a degree in an applied science with seven years experience in FORTRAN," when the company actually needs someone with an engineering background who has patience and the communication skills to babysit customers as they define their requirements.
All too often the following is heard, "He's got seven years' experience and/or he's a quick learner, so he should be able to pick it up quickly." Such assumptions pressure the employee to learn Russian I and II in three weeks. While many are willing and able to rise to the challenge, even the best-intentioned may fail.
2. Unrealistic expectations
Here, the belief is that an engineer with a good reputation can do anything. But not every engineer is a jack-of-all-trades or can pick up any assignment.
For example, an engineer might have had thermodynamics and power in college and done well in both. He or she also did well in a first assignment in power, but may have no interest in or feel for an upcoming thermodynamics project.
For senior engineers, the problem can be even worse: a series of successes in good situations may be followed by either a bad situation or a promotion involving the Peter Principle (where one rises to one's level of incompetence). Either may lead to a failure that will unjustly damage a hard-earned reputation.
3. Narrow skills
This is the final variation of the initial theme. The engineer is great as long as he is left in a field in which he feels secure, for example, COBOL programming on an IBM mainframe. In an extreme case, given an assignment outside this haven, he may even want to fail so that he may retreat to his prior, safe, work.
Of course, most engineers do not wish to fail, but the anxiety of stepping into a new area or the lack of prerequisites mentioned in situation #1 may be hard to overcome. The engineer's knowledge and skills may both be oriented toward one special area, and he or she may be much less valuable elsewhere, maybe even less valuable than a recent graduate.
4. No buy-in established
When an engineer is assigned to a project, the manager should establish the benefits to be gained by that engineer from the project's success. Those benefits should include sharing credit. A manager who takes all the credit for success - and, even worse, spreads all the blame around (to others) for failure - will find it hard to get troops to follow him onto the front line.
Each manager should also back up this promise with action, especially "behind the employee's back." Everyone likes hearing from third parties that they have been credited with a success. Conversely, many become suspicious if promises and praise are given in private and not in public.
To maximize the chance of success, an engineer must "buy in" to a project. As in the "win-win" sales philosophy, the manager wants to create a situation where the engineer, the customer, and the manager will all come out ahead if the project succeeds.
5. Interference by personal feelings
Lower-level managers seldom have full control over who is assigned to their projects. And not everyone gets along well with others.
For example, some engineers work in "spurts" because they have lower attention spans and/or less stamina. For boring jobs, these spurts may be short, while a fascinated spurt worker may have to be fed at his workstation to prevent starvation. Often these spurt workers may be seen taking a break or talking with others (who may not be spurt workers).
If measured by the bottom line, the spurt worker's output may be well above average; however, the manager may perceive his work ethic as being flouted. Unless very perceptive, the manager may become antagonistic and let hostility cloud his or her judgment of the other's performance.
And even a perceptive manager may unrealistically believe that hammering away at such engineers' work ethic and chaining them to their desks will make them more productive. Of course, the engineers almost always resent this intrusion on their natural pace and will inevitably work less, not more.
It is also possible the manager may not like such an engineer for other reasons, including habits, looks, attitude, nonverbal signals, background, and so on. In any case, the engineer may not get a fair chance and be branded a failure.
6. Expectations of failure
A psychological study once separated some elementary school children into two groups. The first group was treated normally, but the teaching of the second - of equal aptitude - were told at the beginning of the school year that the students were slow starters but had become more receptive toward the end of the previous school year. The misinformation became a self-fulfilling prophecy. The second group's grades reflected a slow start followed by a strong finish, whereas the grades of the first group held steady throughout the year.
Similar conditioning may occur with engineers. An engineer may come from a bad situation, and have unfair blame laid on him or her by the previous manager. The new manager begins with low expectations from which it may be impossible for the engineer to recover.
7. Prejudicial first impressions
First impressions can be strong. One way they hurt is by hindering the natural improvement process. A manager has to let an engineer learn from mistakes, not by curtailing the engineer's risk-taking, but by encouraging it.
For example, a young and inexperienced engineer making a technical presentation to a customer might, understandably, make mistakes. A good manager would point out what the engineer did correctly, while making constructive suggestions on what to improve. But all too often the engineer might not be given a second chance to make a presentation because the manager thinks it is "too dangerous."
8. An unrealistic situation
A project's schedule and requirements may be more unrealistic for some assignments than for others. However, the manager may presume that each assignment is equally clear and reasonable. For the engineers with the less realistic schedule, the failure of the manager to recognize the difficulty of their task may be held against them.
9. Perception vs. reality
Often, by an objective measure, the engineer's task or project has been handled successfully. For example, working in a difficult situation, the engineer either missed an unreasonable schedule only narrowly or made something useful out of poorly drafted requirements. Or the success may be unqualified: the engineer met all requirements and succeeded wildly beyond anyone's (except, perhaps, the manager's) dreams. Yet, for whatever reason, the manager did not get the message.