IEEE Home

Aug. - Sept. 2002

 

short circuits

Your Engineering Heritage: Titanic, Wireless Communications, and the Popular Delusions of Mass Media

World Bytes: Animal Wildlife Crossings

viewpoints

reader feedback

archives

career articles
policy articles
all articles
2012
Dec Nov Oct Sep
Aug Jul Jun May
Apr Mar Feb Jan
2011
Dec Nov Oct Sep
Aug Jul Jun May
Apr Mar Feb Jan
 
 

archive search

" size="18">

 
 

Comments on this story may be sent directly to Today's Engineer or submitted through our online form.

 
 

 

Back

Backscatter

About Working Together. . . or Not

by Donald Christiansen

I first thought of calling this column "The lone wolf: endangered or extinct?" That was based on the common belief that engineers who practiced before the middle of the 20th century (up until World War II, say) did their best work as individuals, not in teams. They liked to work alone, and even disliked working with others. And that with the technological watershed stemming from wartime developments and the subsequent complexity of systems, team engineering became the necessity and the norm. Can we possibly imagine today's extraordinary computer and communications systems being developed in any other way?

Yet most historians of technology subscribe to the notion that engineers are, or at least were, individualistic and independent, and proud and protective of their own accomplishments. They cite pioneers such as Tesla, Armstrong and Farnsworth, who seemed to do their best work in isolation and did not work especially well in the corporate environment. In those days, it seemed easier to determine who deserved credit for a particular invention. Admittedly, there were contests concerning who was first when engineers working independently developed essentially similar inventions, but ultimately the engineering community, if not always the legal community, was able to determine who did what and when.

Contrast that with today's situation. One seasoned engineer, serving as a judge for a major award to an engineer for outstanding technical accomplishment, told me recently that it is more and more difficult to single out one person for the award, or even judge the merit of a nominee's contribution. For one thing, he said, the supporting papers are likely to list multiple authors and, likewise, the supporting patents list multiple inventors. It would be embarrassing, he said, to have to ask the nominee, "How much of this work is yours?"

Engineers don't always relish working in teams, despite the need to do so. They embrace the idea of autonomy, and they don't expect the boss or even colleagues to have to tell them how to do their job. They respect originality, and thus neither favor nor enjoy copying the competition. Often they are even skeptical of ideas offered by members of their own project team, particularly if adopting those ideas means scuttling an idea of their own. They may go to great lengths to prove why a colleague's idea is unworkable — or at least how their own is better.

In part because of today's team approach to engineering, the EC2000 curricula accreditation requires that some undergraduate projects (e.g., research or design projects) be done by student teams. Aside from the technical and procedural knowledge gained thereby, students are exposed to both the advantages and hazards of team dynamics. A student project may fail or be poorly done in spite of technically competent team members. A strong leader may suppress the role of other team members, permitting little or no collaborative effort. The mere presence of a female on an otherwise male team may encourage stereotyping. She may assume the role of data taker or some other non-leadership role, or even become the subject of minor harassment (someone will write me that no harassment is minor, and they may be right). The solution here may be close monitoring of student interaction, or, as happened in one case, tape recording of the sessions for later analysis by the professor and team participants. In any event, these projects provide a preview of what the student may find in his or her first encounter with team engineering in industry.

Is there a serious downside to team engineering? Too many meetings? Too much time spent selling your ideas? Too little time for creative engineering? A lack of psychic reward for one's own contributions?

When social scientist and management consultant Michael Maccoby interviewed engineers in major U.S. electronics companies in the 1970s, many said they were nagged by thoughts of being merely part of a huge machine. For many, Maccoby concluded, the ideals of individualism persisted within engineers even in the contemporary corporate environment.

My senior colleagues and I ("old-timers," if you prefer) marvel at the amount and diversity of technical knowledge today's active engineers require and can assimilate, and the amount of time they must spend communicating via e-mail, technical conferences, and face-to-face meetings. How do they find time to think? Junichi Nishizawa, inventor of the semiconductor injection laser, demanded quiet and solitude while working. Prolific inventor Jacob Rabinow said that inspiration came to him in solitary moments — while shaving or driving, for example.

Could it be that there remains a bit of the lone wolf in each of us that we should nurture? Do we need to set aside some time for engineering meditation? Is there such a thing?

 

Resources

For more about the working habits of engineers, see:

Ingram, S. and Parker, A., "The Influence of Gender on Collaborative Projects in an Engineering Classroom," IEEE Transactions on Professional Communication,
March 2002, pp. 7-20.

Kidder, T., The Soul of a New Machine, Little, Brown, 1981, Avon, 1982.

Maccoby, M., "The Innovative Mind at Work," IEEE Spectrum, December 1991, pp. 23-25.

Vincenti, W.G., What Engineers Know and How They Know It, The Johns Hopkins University Press, 1990.

 

 

 Back


Donald Christiansen is the former editor and publisher of IEEE Spectrum and an independent publishing consultant. He can be contacted at donchristiansen@ieee.org.