US researchers say that graduate engineers tend to be egoistic loners who can't work properly in teams, much to the aggravation of their employers. Responsibility for this distressing state of affairs lies partly with the media, which portrays a misleading image of what it is to be an engineer, and partly with older students at …
What are these dozens of TV shows they are talking about with lone wolf maverick loose cannon engineers sticking it the Man while going their own way fighting crime?
Did they just watch the entire boxset of MacGuyver or something?
Trust me, it's laziness
"Finally, students would procrastinate about actually starting work, leaving a task until the last possible minute and deliberately completing it under severe time pressure. Leonardi says this was not laziness, but rather a form of boasting designed to show off one's competence among other students."
One of the few things I recall in great detail from my school days, is putting work off till the last moment.
Cart, meet horse
What an arrogant prick! So the engineers broke tasks down and dished the work out among themselves - so bloody what? If I gave a team a big job and they did that, met the deadline and delivered to the required quality level, I'd reward them, not criticise them. That shows a damn sight more in the way of good organisation skills and initiative than a lot of people with "manager" in their job titles possess.
But what really annoys me (OK, maybe I'm having an off day today) is the implicit assumption that collaboration in teams is the only way to do things. I've been in IT for longer than I really want to remember, and the people that have had the skills, the ability and the can-do, go-for-it attitude have often been loners. I can recall several projects where these folks have pulled things back from the brink of disaster while the huggy-feely types did sod-all apart from demand status reports.
Managing people like that is not easy; you can't just organise group hugs and send them to sleep with PowerPoint presentations full of management speak and exhortations to all work together, boys and girls. You have to work at it, gain their respect and more importantly, accept that people with those sort of skills can't be moulded like sheep.
But that's probably too hard for most snot-nosed MBA graduates these days.
Did the professor work alone or as part of a research group? My guess is "solo"- those guys don't like sharing credit- especially if there is a possibility of an award.
No Engineers I know look like the shower interviewed by this Prof.
American Engineers are no different to UK Engineers in team working respects so his students must be of a type unique to his institution?
Seems as though he's looking for a tabloid headline.
That IS what engineers do
Why am I thinking of the IT Crowd "Team team team team team- I even like saying the word 'team' "?
In my experience as an engineer, of university and the workplace, the breaking-down of "team"work into individual chunks is the ultimate safeguard against 'deadwood' team members contributing little to the project. Individual responsibility creates accountability if that chunk of work doesn't get done. The engineers I know/have known also prefer to have the opportunity to think about a problem in depth on their own, without being distracted endlessly by others. This of course does not preclude collaboration when appropriate, eg when they get 'stuck' or are touching on an area of another engineer's/person's expertise.
Sounds to me that some pointy-haired bosses are bemoaning the fact that engineers generally don't take to their faddy management practices, and this Prof is taking their complaints at face value.
I can't talk at all about procrastination (I'm one of the worst), but I thought that was a problem with students in general rather than especially engineers.
New discoveries are not found by following roadmaps. We already know what's there.
Get to them before Uni
I spent much of my first working years helping to integrate new scientists and engineers into our research lab. The ones who had spent a gap year working with us before going to Uni and then came back to work their holidays arrived after graduating with a much better attitude and aptitude. They were more like PhD students with 3 years of working experience.
I dislike these studies that avoid the concept of motivation
Yes, theoretical people could theoretically work better in teams. But in reality, engineers are an egotistical bunch, because that is the personality type that is best suited to solve problems. If they weren't motivated to solve problems and show off, they'd have become doctors or lawyers or something.
The problem is managers that don't know how to manage engineers. You can't expect every type of employee to function the same way. Some work best in coordinated teams, others work best when competing to find a solution. Manage engineers like engineers: set it up so they can compete, and you get a super-productive team racing to solve a problem.
NASA knew this back in the day, but seems to have forgotten....
Production line > talkshop
"when told to work on something as a group, typical engineering students would instead break the project up into separate jobs so as to avoid working collaboratively"
So they chose a friction-free approach which requires considerable self motivation and self discipline, rather than risk the project becoming bogged down in the discussion of minor elements... and the problem with this was what, exactly?
Paris, because I doubt she understands either.
not follow road map
Is this not a good thing that they try and find inovative/different ways to solve a problem ???
its kinda what they are employed to do ....
"students would procrastinate... leaving a task until the last possible minute..."
Thank goodness that applies only to Engineers, and not to students in general!
The title says it all really. I find students perfectly capable of working in teams. The issues arise from a small minority who don't have the people skills to actually function in society never mind groups. I've known students to come up with solutions that they think will save time but actually make tasks more difficult. This is a process called learning from experience. It is something engineers need to do. It makes them better at their job. Giving people no room to investigate and understand the problem doesn't let them learn or understand. Engineers generally like to know why and how things work. So strangely enough they tend to spend the extra time looking into these things.
He sounds like a bad manager
Doesn't know how to tackle complex problems, doesn't let those under him who know the detail get on and do it. Thinks that consensus on the problem is somehow better than a working solution.
is a terrible thing to encounter when you're paranoid about your grade.
Working as a team risks a weak grade because that person who leaves it all to the last minute discovers he can't actually work as quickly as he thinks, or two people refuse to agree on a method/plan/design and the whole thing descends into a tiny power battle as they both try to get the rest of the group on side, or any other petty reason that makes people think they could lose marks unless they hang on to and are only marked on their own tightly defined region of work.
Then again, I'm writing this while not working a report for my PhD...
is about solving problems. How many people do you see sharing a crossword puzzle or sudoku unless they're stuck? It's the nature of the beast to try fix it yourself, for several reasons
1) you don't know if you can do a task, or if you'll need help, until you start to tackle the problem hands on
2) you might not want to piss people off with stupid questions
3) you might feel you can tackle the problem on your own and let everyone else get on with their own job
4) it's a creative process, people work in ways which may not be compatible with other people's ways of working
Anyway, the people sampled for this study aren't likely engineers, but programmers.
There's a difference, engineers rarely get to write code.
Well I graduated from an engineering school not too long ago... I know that in group projects we tended to divide up tasks and give them to whomever was most suited to handle them. That lead to a lot of working alone on things, even if there were 2 people assigned, because at 4 am, most people just want to be asleep, not in a lab.
And the reason we started anything late was eithe rof 3 reasons: 1) It's impossible to schedule meeting times for 4-5 university students with jobs. 2) If you've got to work on one project, you probably have at least 3, plus 4 classes worth of homework, plus jobs, plus maybe sleeping a bit. 3) Pure lazyness.
Any issues I noticed in group projects was when groups were assigned instead of chosen by the group members, which lead to all sorts of conflicting personalities within the group, plus at least 2 members that are inevitably completely useless. When one person spends a week designing the title for the poster and 3 other people put in 40 hours of work on CAD / FEA / Report writing each during that time, all sorts of things tend to go wrong.
I reckon that the real reason for problems when new in the workplace is because real engineering jobs are totally and completely different from engineering school. And there's quite a bit of adjusting for a lot of people to do in most every respect.
RE: Cart, meet horse
Mr. Smith, treat yourself to a pint! I couldn't agree more!
If the professor is going to tell the "engineers" how to solve a problem, then they are not engineers, they are trained monkeys.
Too much input spoils the soup...
Engineers are heralded for being creative and persistent. Light bulbs take 10,000 tests, batteries 25,000 tests... what bean counter could manage those projects? What team could stay on task for all those tests?
I designed the judges stations for the 1972 Olympics. When the word got out we had won the bid and the actual design had begun there were lots of managers who wanted their name associated with the projects. Lots of managers who could not keep their chance to inject an idea to themselves. I made 15 complete design efforts before someone tossed all the management and we went with the first design, the designed used in Munich. That need to stay focused is what kept me on small teams for such projects as my part of the Moon Walk, Apollo 13 display system, 1972 Olympics and lots of other fun projects.
And the first thing you must do when submitting your PhD, done at CERN on an experiment with 1000s of people and papers with 300 co-authors, is to sign a statement saying it is all your own work and not the result of any collaboration with others !
My guess is that the prof. is seeing the school's culture and incentive system reflected back at him.
Coming from a software background, can someone tell me what the actual development alternative is? I mean, rather than studying the problem, breaking it into tasks, giving the tasks to the most suitable people, and then keeping everyone informed on status... The only thing that comes to mind is a bunch of people sitting around a room arguing about why a case statement is preferable over a nested if-else for several hours rather than writing it and leaving it.
How about considering the counter example of a bunch of MBA types doing it as a team ... doesn't seem to work on the Apprentice does it ... even though they start work at 6:30am.
Nothing to do with TV shows...
...but with the inevitable freeloading idiot no-one wants to be dependent upon when getting grades for their group project - doing your own, separately identifiable work means you are in control of your grades - what part of this do lecturers fail to understand?
It's not a bl**dly drama class where everyone workshops and bounces off each other (or whatever it is they call work) - and even there individual contributions can be clearly evaluated;
It's simply that no-one wants to end up either being dragged down the the lowest common denominator or doing twice the work to compensate / cover for them.
As any reader of Dilbert knows, this is in fact excellent training for the realities of the workplace, which managers (i.e. probably those who were in the drama class) also fail to understand...
/ Wonders why lecturers can so magnificently miss the obvious
Sounds like this Prof. watches too much TV
Maybe if this guy actually got out into the real world, he'd realise that most companies that employ engineers successfully manage them to produce useful, reliable results - whether they work individually or co-operatively. it's not about the people - it's about how they're managed.
For example, just taking a group of people with similar skills and assigning them to the same manager does not make a team. To qualify as a team, the individuals must share a common goal and be able to contribute, more or less equally, towards it. They must also expect to share in the rewards and benefits of that success. Contrast that with the setup in most companies today: individuals are given their own assignments - which do not form any sort of coherent whole. They are assessed "competitively" i.e. there's only a certain amount of reward available and it's apportioned by a manager who is not involved in the assignments, nor is able to judge the quality of, nor effort that went ito producing the result - all they see is whether it was on time or not.
As it is, teamwork is vastly overrated. It loses a great deal of peoples' time spent communicating with other team members, ensuring that what they've done will work with what you've done, Waiting while a slow worker holds up the whole team, or for someone who is off sick to recover and get back on the job. Just look at a pyramid structure: it's only the poor saps at the bottom of the pyramid who contribute actual progress, everyone else is overhead. Plus, as the pyramid gets larger, the proportion of dead-weight increases faster than the ability of the workers to get things done.
Remember the two basic tenets of teamwork:
- If you want a job done right, do it yourself
- He travels fastest who travels alone.
Engineering management 101
Dear managers, please don't listen to this pilloc, listen to an anonymous coward on elReg instead!.
When tackling large projects always break them down. You'll just have people tripping over each other otherwise. You only need to manage the interfaces between people, not the internal choices within their work.
Don't think consensus is better than individual opinion. In any team you'll get people with different knowledge of a part of a problem, the person working on it, is the expert. Perhaps he knows 80%, the others 50%, 30%. Don't think you'll get 100% knowledge from consensus, the strongest voices often know the least, and you're more likely to get (50+30+80)/3 = 53% at best.
If you ever think you know better than the people doing the actual work, take a vallium and go sit in a corner, you are an idiot.
When coders choose not to talk to you, reflect carefully on previous decisions. Have you ever found yourself listening to what they say then making a choice different from their choice? Why do you imagine your choice is better? You've only got a tiny fraction of the info in their head, they communicated as best they could, you understood as best you could, but ultimately talk is a crap bandwidth transfer!
There is nothing wrong with exploring different solutions to a problem, it is important in learning, especially for students, especially in areas where technology changes fast.
IBM will never make an iPod. They have money, talent, yet somehow the management just can't coordinate that into successful commercial products. But yet they give out certificates!
Donald Knuth didn't take the IBM Certified developer course. You can put him in a team with other programmers and tell him the team knows best, but it's unlikely to be true.
This is mainly hogwash
To lead ANY team of engineers you need (a) some clue about what they do (no, I don't buy the "you should be able to manage anything MBA crap) and (b) be very clear on who does what and how you work. Oh, and (c) must have a personality worth mentioning.
And you do NOT *manage* any team of engineers (actually, any team of normally competent humans), you LEAD them. The difference is that you let people get on with what they're good at, keep it on one path and bollock the bejeeves out of any director giving them hassle without going through you. You do not micro-manage people to give the impression you're doing something.
My team meetings were short. We're here, this is where we're going, we have these issues, who takes them on, who can help, any other points - and bad humour is explicitly demanded rather than banned. They knew it was my neck on the block, and they trusted me to lead them.
The best group I lead built infrastructure in 50% of the officially planned time. And nobody knew how (actually, nobody knew we could at the same quality level either, until I had some rewards out of the board for early finish :-).
I have dealt with plenty of people who must have had a charisma bypass at some point, and those ego trippers are nothing but brakes on people they first had carefully selected by some HR type who doesn't know more than ticking boxes.. Such a team suffers, and becomes nine-to-fivers. Others create magic.
I prefer to lead more people to magic. It's more fun.
There was a recent article in New Scientist about how students doing only as they are told and therefore workers only doing as tehy are told is destroying creativity in universities and the workplace. Rewarding stagnant brown-nosers and exiling independent thinkers.
Asimov's pre-Foundation Empire, anyone?
Professor does not know how to manage engineers, misinterprets own failings
Who would have thought a group of engineers would quickly reach a silent consensus that a divide-and-conquer strategy was appropriate, and spontaneously create, nay, ENGINEER a team structure that mirrored the problem. Looks like excellent teamwork and good engineering to me.
Just who is he?
Paul Leonardi: Interesting CV there.
Claims to be trained as an 'ethanographer" (whatever that is). BA in "Communication and Spanish", MA in "Organizational communication" - with gems such as "Reciprocal Adaptation: Cultural Interchange Between Hispanics and the Internet" in his published papers.
In short, he's not even close to being an engineer - he's an academic that's drifted into bits of the touchy feely MBA domain to make money.
Oh, and when you look through his list of papers - not much in the way of jointly authored papers there.
File under "no practical understanding of why teams are a nightmare if you know what you're doing".
Prof's next dissertation...
Advanced, accelerated hive mind human evolution to produce the ultimate MBA manageable engineer, or an attempt to break the "Meetings, none of us is as dumb as all of us" committee road block effect.
Damn straight I'm not going to work in a team
Because let's face it I'm a better engineer than everyone else in the team.
And yes I will leave it till the last minute, it gets the work done in the shortest possible timeframe - surely this is just efficiency, not laziness or boasting rights.
It is our nature. Deal with it.
Managers are managers because they would make lousy engineers.
Didn't we do this in the UK already?
Back in 1980 there was the Finniston Report for the UK government about the engineering profession. Back then they recognised that fresh graduates from university normally took another couple of years to have academia trained out of them and industria trained in. (i.e. welcome to the real world). At the time it resulted in BSc/MEng courses being offered by various universities in partnership with industry, to give targeted industrial training to complement the academic learning, so that turning up for work with a shiny new degree, the graduate already knew a lot about how the company worked, having had the practical experience.
I think it's been watered down a bit since then, probably because producing high-quality graduates costs money and the big defence firms that signed up for it mostly don't exist now. And yes, I did one of those early courses, and yes I think it was a better way of doing things.
Working in a team
Anybody who has worked in a project knows that it is often best to break tasks down.
If done properly, this is much more efficient than group work. Decisions should be
taken at meetings, implementation should be done separately.
This is a work of brilliance. Not because its right, but because its so wrong. That means that it'll be cited by lots of people that know what they are talking about as the example of the moronic end of things. Cites are good for people's careers, so each time they do so the author gets a tick in the box.
Therefore by being deliberately dim, he's being deliberately brilliant.
If he shut up and bathed more often, he'd be able to get a proper job like everyone else.
Taking outside and given a right kicking
Engineers are generally engineers because they enjoy the challenge of making/fixing stuff, wether it is C++ code or CNC code.
The other problem is that engineers tend to be above average intelligence and know when you are spouting s**t.
But they will work in teams when needed, but they also know you can get a lot more done when you dont have to explain yourself to the other team members or explain 5 times to the guy whos alledgedly 'managing' the group.
Take my job at the moment, its to design and build the fixturing and CNC code to make 60% of a high pressure gas injector part, one of the other team members is doing the other 40% on a different set of machines.
Our manager would not dream of forcing us to work as a team and submit all ideas to the 'team' for approval as that would mean spending 1/2 the day arguing over every detail, instead he lets us get on with it who only the occasional word about delivery dates.
We may get stumped from time to time and bounce ideas off each other while having a quick smoke, but know what needs to be done and will get on and do it.
And indeed, we've just submitted the part to the customer for approval.. and production hopefully starts next week
they are working when they could be in a meeting saying "tipping point", "outside the box" and "paradigm shift" and looking at pie charts.
@ Mike Smith Posted Tuesday 9th June 2009 15:18 GMT
Right on there, pal.
I'm a graphic designer by profession, and not an engineer, but I have quite a few friends who are engineers, so I can totally empathize with them in that regard.
I first started my career in 1980, right at the dawn of that wretched fashion of managerial types using sports jargon like "team player" even though none of them looked like they'd ever been involved in organized sports in their lives, let alone having had to do any actual work on a project outside of "managing". If I had a buck for every time I saw a req for a new position, or a proposal presentation that used the phrase "team player" I'd be George Soros by now.
"Team player" to me has always been a euphemism for "give up your identity, your self, your soul, your life".
In every design department in every ad agency I've worked in, there were always designers who were best at one thing, whether it was layout production, pre-press, typography, photography, illustration, what-have-you, and it's like Mike Smith says back up the scroll there -- the creative directors would always break up the project into components which were handed around to the various designers in the department according to their particular strengths, and would be sure that we were all communicating regularly, and ended up delivering a campaign on deadline, on budget, and which made the clients wet their pants with delight. The CD never gave a rat's ass if we were "team players" according to some ignorant-assed pointy-haired managerial diktat.
That, to me, was always the true essence of "teamwork".
Reading this article, I found myself thinking: if the engineers working on Project Apollo were measured according to today's bullshit managerial blather about "team players", we'd never have put a man on the Moon.
Grrrr Grrrrr Slaver Wooof Woooof Chomp Chomp
I say Lewis, that's a bit uncivilised. Digging out some insignificant tosser and throwing him to the dogs....
Just in case....
Leonardi, P. M., Jackson, M. H., & Diwan, A. (in press) The Enactment-Externalization Dialectic: Rationalization and the Persistence of Counterproductive Technology Design Practices in Student Engineering. Academy of Management Journal
Can be read here
Without having to subscribe.
50 fucking pages of crap cross-referencing another bunch of meaningless shite spouted by another bunch of insignificants.... Probably pass muster at Wikipedia for 'sources' and that would be all.
Also includes links to other non papers with similarly warped titles. Sad thing is he will probably think there is something wrong with us. Delusionality is often the last barrier before mental breakdown.
Anyway, very tasty but can we have something with nicer shoes next time?
Grrrrrrrr snarl Bark Bark Wooof Woooof Woooof.
Solo is the right way
you split the problem up, and coordinate, anything else is sheer folly.
Projects solo can take 1 month, add a team of 12 it can take over a year and be a lot worse by the end, so 624 weeks versus 4 weeks, and the 4 trumps in quality anyhow.
The reason they don't like this style, is because the manager has a hard time comprehending the problem, the doers don't, and it offends the ego that others are a lot more capable.
You want tech to work even faster and harder still, hookers, cocaine and cash are more effective than grouping thinking on one problem. And far from being loners most are party animals, engineers work best when hardcore electronic music is pumping.
And the report is hypocritical in itself, little Pauly the Egotistical Loner came up with this bollocks all by himself, probably because they wouldn't let him play.
I think everyone pretty much said it all ;P People like that guy pretty much managed this economy to where it is today. And as far as egoists go, I think from him that would be the pot calling the kettle black, except most engineers actually have the ability to solve problems that back up such egos :P
I just hope no one important actually listens to this guy, because the kinds of people tho eat his crap ideas up, are also the kind of people who would never read a site like this to hear any real criticism for what this guy is saying. And their assistants, who are supposed to look into stuff like this and inform the decision makers, well we can see how well they've been working by looking at the state of the world :P
And the best managers for hard projects that are being worked on by engineers tend to be engineers also, or have an understanding of the engineer's purpose and methodology, but again people like that tend to be engineers anyway, or else work solo in the services fields. They solve problems for a living, and if there was a set way for solving problems, then we wouldn't need engineers.
If the work gets done what the hell
I work in an office with quite a few desk hoppers that do bugger all but drink coffee and talk crap while myself and a couple of other loners as they put it get on with keeping things up and running.
If we didn't business would grind to a halt because the coffee pits wouldn't notice a thing.
I'd rather go home feeling like I've done an honest days work than be a social animal at work anyday.
FFS, if the world were just made up of professors we'd still be in the dark ages
An experienced engineer...
...is either a team player, or innovative. Rarely both. And never in a big, credit stealing organisation.
There was an article in the LA Times a few weeks back about a private, high-immersion computer sciences college here in California (I think) called Neumount (or something like that)
which recently had to introduce various activities designed to teach students - read: computer geeks - basic social interaction skills, some as basic as personal hygiene (remembering to bathe regularly, for example, was remarked upon by the few female students on campus), based, they said, on feedback from employers of their graduates who, while praising the graduates skills, complained that many of them had difficulty interacting with other people and were generally lacking in the social graces.
Engineers who can combine technical with people skills tend to make mad money so there may be some truth to this, especially in combination with sales or even legal areas.
"Engineering management 101" - Exactly!
Project split into work packages, each assigned to a suitable engineer (with a deputy for holiday and sickness). Engineers then work on their own work packages unless/until they need help. They might work together for some tasks, like testing. Otherwise, the more experienced people are going to waste their time with trivia and the less experienced people wil not learn to devise their solutions.
If you try to design by committee, it takes ages because everyone thinks their way is best.
When not used in connection with maps and roads, the term "roadmap" seems to be favoured by managers with a grasp of Powerpoint and little else.
Management failure covered up, as usual
"US researchers say that graduate engineers tend to be egoistic loners who can't work properly in teams, much to the aggravation of their employers."
By God, they've got my number! The only people I want working in my team are a) people who know what they're doing and b) people who are willing to learn from those that do. Everyone else can poke it, and if that makes me egoistic, so be it.
To be fair, in the last place I worked, most supervisors had been engineers and they really sucked at being bosses... too arrogant to be able to see beyond their own prejudices and preconceptions. The best boss I ever had in there was an ex-NCO in the Dutch army, who had seen something outside of a physics department and knew how to lead people.
And that is the failing of modern management - plenty know how to 'manage', or play political games, but very few people actually know how to lead.