Peer pressure: the real reason engineers don’t play well with others

Last week, I wrote about two engineering stereotypes – the thinker and the tinkerer.  When I was attempting to add a bit of data to the fluff, I came across an article in Science Daily about how engineering stereotypes drive counterproductive practices.  In particular, they encourage engineering students to engage in practices that are actually harmful in a career.  Unfortunately, it wasn’t applicable to last week’s piece, but I found it worth discussing nonetheless.  (If you’d like to read the original article, you can find it here.)

The premise of the article is that engineering stereotypes are already prevalent in society and that students think about these when interacting with their coursework and classmates.  Specifically,

“There’s a stereotype that engineers do things by themselves,” Leonardi says. “So when students are asked to work in teams, they think, am I going to be disadvantaged? When I go to the workplace am I not going to be as valuable?”

In other words, students believed that if they weren’t able to do a project alone, they couldn’t consider themselves an expert engineer. Leonardi and his colleagues often saw groups splitting up group work, even if they were specifically asked to work on it together at the same time.

I found this idea interesting because it’s actually very counter to what I’ve experienced.  That is, most students do not make an effort to work independently because they want to make themselves into good engineers.  My observation is that most engineering students were often good students in high school and felt like group work was a negative experience for them.  Good students often end up doing the bulk of the work in a group, and they feel that they share an unfair amount of burden in groups.  Realistically, this doesn’t go away in college…and sometimes not even in the workplace.

Whether or not this is true, I will say that it’s definitely something I’ve seen pushed in engineering classes.  If you’re supposed to be a good engineer, that will be reflected on individual aptitude, which is generally believed to be shown on exams.

Another issue examined was how students reacted when given detailed instructions on how to build something: they ignored the instructions and tried to figure it out on their own.  Again, they said this was due to the fact that students believed that, as engineers, that’s what they were supposed to do.  My feeling was that most of them had been capable of something similar in the past and/or like a challenge.  Therefore, I would attribute this behavior to ego about one’s individual abilities more than believing a stereotype about engineers in general.

I guess I personally wasn’t convinced that it was stereotypes causing the problem so much as individual students used to working a certain way and rationalizing it in retrospect.  I’ve seen this among students in several different disciplines (almost always male-dominated).  I think it has to do with the culture of ‘smart people’ who push themselves more than trying to adhere to a stereotype.  What do you think?

6 responses to “Peer pressure: the real reason engineers don’t play well with others”

  1. Miss MSE (@MissMSE)

    I did not have a positive group work experience in a class environment until my senior year of undergraduate, for our final design project. I didn’t believe I had to do something alone to be an expert, I just believed that I was going to end up doing it essentially alone anyway and I might as well get started. What taught me how to work in groups was being in band, where you have to work together. You can’t play complex harmonies alone on a wind instrument.

    I also wonder if there’s a gender component on following detailed instructions. In 8th grade shop class, we were supposed to take apart an engine, clean it, and reassemble it. If we finished early, our incentive was extra welding time. I paired off with the only other girl, and by following the directions, we finished roughly 2x faster than our male peers who by and large ignored the instructions.

  2. Peer pressure to read EngineerBlogs « FCIWYPSC

    [...] trackback If you have the chance, please go read my post at EngineerBlogs today: Peer pressure: the real reason engineers don’t play well with others.  Just remember that all the other cool kids are reading it… Share [...]

  3. Charles J Gervasi

    Maybe the same traits that make us comfortable with machines make us uncomfortable with human beings. That’s a stereotype that appears to me to have a bit of truth behind it.

    In most modern projects you need to work in groups. The only way for it to work IMHO is for everyone to remember it’s a temporary arrangement to get something done. You’re not marrying you colleagues, customers, or vendors. You’re just trying to get something cool working.

  4. Stu

    In my case, I tend to work alone because I tend to make progress faster if I work without other people slowing me down. Not only is it hard for me to hear in the first place, but it seems to me that in groups people talk things to death.

    I do like working with another individual though, because working with one or two others is easier to hear and understand them, and it’s easier for me to direct the flow of conversation and keep things on track and moving towards a timely conclusion.

    The main benefit to group work, in my opinion, is that everyone operates on a different work/rest cycle, and when you need rest, others pick up the slack, and when they need rest, you pick up the slack. And if you’re working with people who are a good fit for you, the team can do very well. If the team doesn’t work well, then working alone seems more productive.

    This is from the perspective of office and IT work. :)

  5. ferd

    My experience is that an engineer’s ability to work in a team depends upon how he perceives the quality of his teammates. If he admires the talents of his teammates he will probably work with them. But when you mix talents within teams, as is often done in public school, you create discords that become negative experiences. Often the “cool kids” are lazy and loud and don’t care much about grades, which goes against the values of the “doer kids”. So it’s no surprise that doers withdraw from groups. They perceive teammates as “holding them back” or just plain “wrong”.

    There is no doubt that teamwork trumps individualism in most cases, provided that everybody on the team actually brings something useful to the table. Very few can do everything themselves, and fewer can present acceptable results in a timely manner. It’s management’s job to create workable teams, but many think that just throwing people together is good enough. So in that environment the engineer withdraws from a poor team and justifies the stereotype.

  6. Al Sledge

    Some project lean to going it alone, where other projects are too huge for a single person to grasp in minute detail. Two examples in my life come to mind.

    I was tasked to build a guidance system. I did the conception, put together the bill of materials, sent them to purchasing, and started my sketches. Of course my boss asked what he could do to help me. I told him to close my office door and not pester me for 30 days. Twenty five days later I went into his office with the prototype. Afterward we got drafting etc to document the stuff. The flight test was flawless and I got my usual “attaboy”.

    The second, a group project, was to develop a third party emulation of an IBM3270 Cluster Controller that was either 8085 or Z80 driven (don’t recall). It took three of us to develop the basic hardware layout. As I was also a software/hardware guy (everyone hates our types) I put together a team that included an outside software house. The IBM3270 comm is a nightmare in itself and after reading the spec, I figured it would take me a year alone to write and debug that software. But again myself and a couple other software guys put together a what, how, when, and flags book together and agreed to meet every Friday unless anyone had a stoppable crisis. And there were a few. One team worked on the “main loop” processing, one on communications, and I did the IO interrupt handlers and the comm handlers. Each group simulated what the other group was doing as far as passing data, including error handling. At the end of two months we linked all the new code together. The “big day” came and we tried to put it online with the remote mainframe. It was the only project I ever did that had no bugs that we could find. Not even a misswire. In all roughly 30 people were involved, each knowing no more than his own little part, but each as a qualified expert in his area. Frankly I was amazed that we could pull off such a huge group project without a hitch. Not a single slacker on any team. I miss working with them.