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?
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 …
"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.
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.
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.
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.
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....
"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.
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.
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.
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.
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.
...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
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.
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.
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?
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.
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".
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.
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.
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
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.
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.
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.
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
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.
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.
"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.
From the engineers I know and the comments here, this guy was bang on!
Some engineers *are* creepy loners unable to work in teams -especially the youngest ones. That's part of the culture and that's *not* *good*, despite what a bunch of them seem to think. Sure, if you're good you'll probably manage to solve the problem this way. But it's never be the best -or even one of the best- way. So you'll either come up with a working but sloppy and short-lived hack around the problem, or have your solution(s) refused (or self-censored) 24 times before reaching some acceptable compromise between deadlines and fitness-for-purpose. Both are considerable waste of time and can be avoided by rounding up and discussing ideas, problems and solutions beforehand. But then again, the danger here is endless useless meetings about the colour of the file in which the specs for the flowchart of the prospective roadmap will be stored.
It takes good management for this to be efficient, the current shortage of which may or may not explain the tendency towards loner habits when you want the work done. ;-) It might or might not be done right, but at least it'll be done.
As for the procrastination part, it's not specific to engineers and is not necessarily a bad thing. In older types, it turns from "wait idly till the last minute" to "study and discuss the ins and outs till the last minute", which usually leads to a much more suitable solution than starting doing random stuff blindly. And coincidentally it looks remarkably like team work ;-)
But again, I'm not an engineer myself and I tend to be a dreadfully procrastinating loner, so what do I know?
It took him years to figure out something that could have been verified in a matter of hours. Had the booger-eating-moron known where 'most' engineers hang out after work (either bar or online), he could have:
1) Sent a team of reasonably attractive interviewers out to ask said Engineers.
2) Set up a website and placed links to it in several placed where we go to either research, read or blog trivial crap.
In conclusion, what ever the learning institution paid his sorry arse to conduct this study got a screwing of a life time as one of us could have had it done faster and cheaper.
As for waiting for the last minute to do stuff... It's been scientifically proven that one exerts less energy when they work in short, but intense, bursts, rather than at a laboriously slow pace, over a series of hours/days/weeks.. Since our nature is to either make things easier on society (as well as us) or figure out complex tasks so others don't have to, it's in our nature to be as efficient about it as possible.
Mine's the one that says "I dare to slack by not playing well with others" on the back
I work in a small company with lots of carefully selected developers (of varying ages and capabilities).
We work in small teams of about 4 and use a moderately agile planning process that means we have a 'deadline' every three weeks, and we know roughly what the team has in store for the next 10-12 weeks.
10 minutes of "What I did yesterday"/"What I'm doing next" every morning and an hour of planning at the start of every three week chunk works brilliantly.
Managers? What managers? There are a couple of blokes higher up bringing work in and doling out large tasks for the teams to split up, and that's it.
Quite different from when I worked in Civil Service. Much much more productive. And more manageable too, when it comes down to it.
There are some social misfits, and some who aren't. Within the team we know who's who, and one man tasks get done by one man, bigger ones get spread. Egos don't really come into it, we just get the work done.
I think all the people the prof has interviewed have commented above!!
As someone who is an engineer (software) and works with a lot of other engineers who are very bright (brighter than me!) with a lot of PhD's between them, it does leave a lot to be desired. Most are much younger than I, without the real world experience, and it really does show.
I am not I hasten to add, a waterfall style team leader - although am a certified Scrum master. Scrum (and other agile approaches) seems to me to give the bright one a good chance to go off on their own, to do work that just requires a single engineer, but in return, gives the team (and the teams are small, 7-9 people) shape, and management the visibility required to actually keep the project going.
The problem with bright engineers going off on their own is there is no chance to know how the problem is being fixed until the last minute at which point you can either breath a sign of relief that its OK, or fill your pants because it all a load of rubbish and has just blow the deadline to the middle of next week.
You NEED a lightweight team approach like Scrum no matter how bright the engineers are. It compensates for social and communication inadequacies, keep the (small) team motivated (how do you motivate a team when you hardly ever see them together?), and enables the team to see where problems are arising (people not pulling their weight, being overloaded, or stuck on a problem that another member of the team knows the answer too or can help with)
In my experience, you can easily have a few geeky loner people in your team who can achieve 10 times what the others can, but only if they're left to get on with it themselves. Actually, you can also have well-balanced normal people who can do that too.
So do you insist on teamwork? That way everyone's got traction on the project, but the best people get slowed down to the average pace. Or do you give them some freedom and deploy the others in supporting roles? I guess the answer depends on the project, the deadlines and the risks you can take.
Anyway, it's worth recognising that not all engineers are equal and they all have personalities. A good manager knows that and tries to allocate tasks accordingly. But then lots of managers are poor team players too in my experience, so it doesn't always work too well.
Actually, I find it quite refreshing that people are individuals. Its a pity most employers wished they weren't.
Why is "teamwork" viewed as the solution to everything?
Seriously... what is the point of having two or more people doing a task when one would suffice?
All that happens when you have people all working on the same thing is they either duplicate the work, step on each other's toes and get nothing done.
This type of teamwork only benefits the 'deadwood' on the team, as other posters have mentioned.
First, engineers are professionals, not drones, not computers. Managing and teaching students who are to be engineers requires special care. We are expecting these people to create things than never existed before, and make then safe, and create a manufacturing process to make them cheap. This is not a simple command. Most people do not think of the details, and believe that engineers are being truculent when observing that this process could well eventually kill the employees. What does a manager care about eventually killing employees?
Second, to say again, engineers are not machines. There is not one form or teamwork. Engineers by definition create things, so it is reasonable the first thing they would create is a process to allow the project to succeed. While some people need to explicitly brainstorm, detail, and celebrate they fact that have created a process that any brain-dead person could have created in a week, engineers just do it as part of their job and move on.
Third, not everything that looks like procrastination is procrastination. Very often engineers read, and discuss and create prototypes without ever asking anyone to acknowledge or celebrate this work. Once an idea has developed some legs, the engineer will present the idea. To the outside world this look like magic, but those of us in the know realize the work that goes into it. This applies to school where a students may do homework all at once. Not everyone thinks on paper. Many people can sketch up solutions in their head, and then scribble the solutions on paper to the credit.
I have noticed that the smartest people seem to be working alone. I am not the smartest so I work in a team sometimes and sometimes I work alone where my limited smartness is effective.
Breaking big problems into many little ones is the smart thing to do.
This guy sounds like he got his education somewhere way to the east before 1989. The skillset he likes reminds me of the East-bloc refugees I interviewed in the '90s.
Still, I love the title: The Enactment-Externalization Dialectic: Rationalization and the Persistence of Counter-Productive Technology Design Practices in Student Engineering. Hitting all the right notes - Dialectic - great word, but Hegelused it better. Then there are the conjoined words (two!), and the nice alliteration (En-En - a song in my heart!). I could go on but I might get ill.
Maybe this guy belongs in the Department of Deconstruction.
This is the classic 'everything you learned is wrong' approach - Woody Allen did it much better in Sleeper back in 1972, but let's take it from the top:
Break the project into parts - we are taught to do this, but now it's BAD.
Listen to our elders - we are taught to do this, but now it's BAD.
Solve problems for yourself - no comment.
Glad I went to school before they realized all these things were bad - I don't think my career would have lasted a year, much less thirty (and counting).
This survey is crap. The idea that student engineers break a problem up into smaller tasks to prevent working together is false. They break it up into smaller tasks as this is the most efficient way to work on the problem and solve it, with as many people working in parallel! It's called division of labour.
The more time that is spent communicating with each other is time that is not spent actually getting on with the job in hand. Same in parallel processing tasks in IT.
The idea that engineering students leave projects to the last minute is human nature full stop! It applies to everyone not just engineering students.
And students not following the instructions for the task, well perhaps it might have been better if they had, but if you ask me, they're being creative and that's what engineering is all about, solving problems using one's initiative, coming up with ideas. It's fun and an essential skill for student engineers to develop, to practise.
I get a feeling the authors know little of engineering and probably see it as a geeky subject anyway.
As for engineers being loners, sometimes we f**ng well have to be, and not through choice!
Those of you that are graduate engineers, ask yourself, have many people have you tried to talk to about your work who are not engineers, how many of those people even understand one word of what you are talking about? How many of them are remotely interested in what you do?
I don't even admit to a woman I'm an engineer, or that I work in Information Technology: it's an instant turn-off for them and they immediately lose interest in you.
All too often now, when someone asks me what I do for a living, I have to respond with "I could explain it to you but you wouldn't understand anyway" and it really isn't bragging, it's blatently true.
If I told someone, a woman, my own mother "I carry out systems integration on network management packages, customer relationship management and large scale relational databases", they don't have a clue what that means.
My mother, in her 70's, repeatedly asks me what I do for a living, and I can't explain it to her: she wouldn't understand, so I tell her I'm an IT consultant, but then I get the question "Yes, but what do you actually do, day to day?". For someone who has never heard of Oracle, Netcool, Remedy I don't stand a cat's chance in hell in making her understand.
Leonardi has trained as an ethonographer. No, I'd never heard of it either - I had to look it up. The ethnographer joins groups of people, integrates closely into the group and monitors their behaviour.
From research I've done on Leonardi, it doesn't look to me as if a) he has any kind of engineering background, b) he hasn't undertaken engineering work - other than monitor engineers.
I don't think he 'gets' engineers. I don't think he understands what engineering is about.
I'm about to start a new job, where my new boss is an engineer, but in a completely different branch of engineering to myself, but because we're both engineers - and have studied the maths to a high level and have the wide reaching engineering understanding of the real world and what makes it tick, we both know we'll get on really well with each other and will understand each other.
It's a philsophy, it's a way of thinking, it's a personality style, it's a mindset. It's not just a subject you study at University.
A friend of mine once read out aloud to me an article he'd read in a highly respected newspaper about Engineers, about the skills we have, the article was basically saying we're the best kind of people, with such wide skills (intellectual and practical) and understanding, I walked away feeling proud..but then thinking "the newspaper rates us so highly, so why are we paid such crap pay!".
I agree with much of what FredFlintstone has said.
Bad humour is definitely required in meetings: it makes things more enjoyable and that leads to better moral, greater productivity.
I've come across a couple of people in recent years, IT graduates that to me didn't seem very good at the subject of computing. Technically they weren't very good. Guess where they want their career to go? Into management!
Another engineer said to me independently, "you'll often find that those people going into management want to go into management because they're not very good technically."
Seems like he was right.
The best managers I've come across are those that have had an engineering/technical background.
Was a trained project manger and engineer (ex NASA & LM), who once a week would get his team into the room and ask three questions:
1. What's finished from last weeks jobs?
2. What's holding you up, and is there anything the team can help you with?
3. What are you planning to do this week.
It combined the best of accountability, team support, motivation, and low friction oversight, and it produced some insanely cool stuff. He realised he had a team of clever people, and that collaboration just a tool that should be used by the individual trying to solve a problem.
Contrast that with the current job where my lovely but out of his depth boss asks my team to explain how our stuff works (by going through code), four hour team white board sessions, and requests to re-design the lot because 'OO seem quite complex', and we have a product that gets dumber by the day.
"Mr. Smith, treat yourself to a pint! I couldn't agree more!" ... By Anonymous Coward Posted Tuesday 9th June 2009 15:52 GMT
Seconded, AC. And without the Lone Wolf, and Wolves alone which Lead with AI Following, will the Pack be Lost to Impotence and the Reckless Impudence of Conspiring Dark Forces in every Phormed and MetaDataBase Trawled Field.
And man, have y'all got something Really Different in the Great Game to Virtually look forward to ..... http://www.ksatria.com/Studio.html
When does a Game with AI start being a Great Game, rather than a Future Perfect Imperfect Present Reality ..... and would the average Jane and John Doe either know or care to know, if they would not have the Intellectual Ability and/or Mental Faculty to Input Constructive and Universally Acceptable Change? Ignorance would then be Bliss ..... but it is a Mock Fort.
"The best group I lead built infrastructure in 50% of the officially planned time. And nobody knew how ..... I prefer to lead more people to magic. It's more fun." ... By Fred Flintstone Posted Tuesday 9th June 2009 16:52 GMT
Amen to that, Fred Flintstone, that's how to do IT.:-)
A point which I haven't seen made yet. Waiting until the last possible moment, at least for me, has a lot to do with the fact that requirements frequently change during development. Designing stuff early is pointless if the customer will switch reqs on you a week before the deadline.
First off, I am an engineer, a real engineer at that. Glorified-basket-weaving skill reliant crafts like software 'development' can not be expected to relate to the concept of team work (just read some of the nonsense posted here). When was the last time you EVER saw a bunch of seamstresses 'collaborating' on a 'project'? Only real engineers can relate.
Well done prof. Truth hurts.
That's code for what's mentioned earlier : splitting the work into individually assignable tasks so that blame can be easily assigned when some fuckwit doesn't complete their work.
At least at work, *sometimes* it's possible to get rid of deadwood - there are no such sanctions at college/university. I could have done without having to pick up things at the last minute at university, because it turns out the person assigned to do one particular task was an alcoholic and busy getting pissed instead of doing the work.. Getting people together to meet in pre ubiquitous mobile and very early web days? Not easy..
In properly run work environments, I'm not certain I entirely agree with letting everyone do their own thing. It only works if everyone is fully aware of the procedures to follow, is of comparable levels of intelligence - or has a task ideally suited to them. If there's insufficient management/monitoring of work, it's very easy to produce inefficient solutions, reinvent the wheel, store up trouble for a later date (an employee produces a working solution, but does not use the objects/resources they should do. The next release is extended presuming compatibility due to using these objects/resources. The employee's work breaks..), use time inefficiently or otherwise needlessly over-engineer things.
If everyone has been working as a team for a while and knows exactly what to do, less management is required. If this isn't true, the above applies.
In my experience engineers tend to be refreshingly ego-free level headed types who just know what they know. Bit like pilots.
Its drama-queen know-nowts that have issues and egos that need constant attention.
Some problems are best worked on individually and some benefit from group interaction. Anyone who doesn't know this should not be criticising the working practices of professionals.
Stupid little man.
I am a lazy egotistical loner. That's why I chose engineering as a career. I am a social misfit and a wierdo too and sometime I have poor personal hygiene. But I need to pay the mortgage and save up for my next car, so can I please keep the job I have already, without any extra team-working meetings and other boring time-wasting frustrations? No you can't play with my Lego.
Yes I am smarter than you, and if you want to know the answer to that great question "if you're so smart, how come you ain't rich?" its because my people skills are really very poor indeed!! (see above)
@Dave: Hey mate how are you doing?
The ultimate riposte to the negative aspects of this argument is open-source software development and the tools and social structures that support it. Linux does not have and does not need a corporation and all its parasitic management types sucking on it. (That's the kernel, desktops, webserver, compilers, languages, various other large apps ... not just the kernel).
That said, engineers in general probably do gain from certain personality traits in moderation, which at the extreme lead to Asberger's and autism. Attention to detail, the ability to concentrate on one thing to the exclusion of everything else, a desire to achieve perfection (though recognising that it's impossible), and intolerance of irrelevant or damaging demands made by the morons that call themselves managers and marketing.
To the parasites, why not just f**k off and create your own perfectly socialized software teams and leave us alone? Oh, you can't write code that works. You can't write code at all. You'd rather pay Microsoft whatever they demand for a heap of crap that's broken by design. What a shame. F**k off and die, then!
I feel quite qualified to comment here because a) I have been an engineer and a good one at that IMHO, and b) I am a manager of both engineers and business types, who has an MBA.
I've seem both sides of the argument and, you know what, it's everybody's fault! Some engineers don't seem to feel the need to seek other people's input in what they do or tell people about it, and sometimes managers make decisions which are clueless or appear clueless because they've failed to tell people why it's actually not a clueless decision.
Firstly, we need to understand what we mean by collaboration. This doesn't need to mean four hour status update meetings with touch-feely talk about our emotions to a backdrop of whalesong (although that's fun too - hey, I am an MBA after all.) All it really means is getting input from people with an interest in:
a) what the problem really is and not what the engineer thinks that it is, and
b) the best way to solve it because, even if you really are a genius, then there may be other people out there who have a better way of doing it
...and then letting people know what you're doing and how it's going so that know when they can do whatever follows on from your work. Let us not forget that engineers don't (shouldn't?!) work in isolation of the rest of the organisation.
Actually doing the work largely is a solo event I agree. I've never had much luck doing something detailed or complex with someone else breathing over my shoulder either; and division of labour is clearly the way to go; but that division of labour must be based on a common understanding of what the problem really is, and what the right way is to go about solving it.
Engineers are often bad communicators and lack empathy; the failure to see a problem from someone else's point of view leads to bad engineering. Managers need to recognise that engineering can be a creative work and standing over someone and shouting "Be creative now" Go team!" in their ear rarely yields good results.
I'm a real enginer too - working a lathe at nine years old, MSc in the kind of real manufacturing engineering that used to make Britain wealthy, but I've also spent twenty years in IT (so far).
The team of which I am currently a part is composed of about a dozen people with differing skills. We have just completed a software project that has been welcomed with joy by our internal customers (they're buying us drinks tomorrow) and it was finished pretty much on budget and on time. If we had procrastinated a bit until the customer really understood what he wanted we would have delivered early and under budget.
The team members met once a day for a few minutes to discuss progress and problems and then split into mainly individual teams to get the work done. We would seek each other out when help or information was needed but mostly respect each others' expertise and not interfere. The same team has now started its next project and we have actually reduced the formal contact between team members.
We have several people with technical degrees, all of us have years of practical experience - we have no MBAs. Perhaps that's why we're successful.
My preferred reply (and have to fight not to say it) is:
"But there's a U in c*nt"
How do they suggest engineers work together? Fit every second wire in a panel, taking turns? Type out alternate characters when writing something in C?
You have to understand how they work before you can suggest improvements.
"Given a detailed roadmap by professors, they tended to ignore it and instead get to a solution by their own means."
We used to call this, "Initiative", some people get bored when a task is just a list of simple steps they must complete.
"students would procrastinate about actually starting work"
We used to call this "thinking", thinking about a task before you start on it, often exposes the best way to solve a task.
Whist still at university (about 3 years ago) we had an engineer from the US as one of our lab demonstrators. He was studying some masters material at our university after completing his undergraduate course in the US. As part of our laboratory work we always worked in pairs and sometimes as larger groups, the US demonstrator remarked that you would never see engineering students in the US co-operating like this or working happily in teams. He said that the education system was so competitive that to get to the level of undergraduate on a reasonable course people were so used to fighting so hard to look better than the next guy they were unable to stop. He even went on to say that students in the US would sometimes provide incorrect advice to others and keep their results from their own groups so that credit for their would would remain guaranteed to them alone.
sounds exactly like teamwork to me.
It's not usually possible in engineering, or IT, to actually produce something in a group. Just try sitting 4 or 5 people around a computer to create some software and watch as nothing happens.
The very essence of teamwork, in a technical environment *is* dividing up the tasks for each person to get on with alone. Generally a project is broken down into individual chunks and designed seperately. Athough, a get togetther with the designers up front to ensure a consistanrt approach is a help. The main bit of collaboration is a way into the designs, where all of the seperate designers will sit around a table and walk through the interactions to make sure that everything fits together properly.
Once the design of those is laid out it is then farmed out to a larger number of people to create, who don't have to have any interactions with each other at all. Just create something that does what the design says, and has the interfaces specified.
This to me is outstanding teamwork, that gets results, and all of the actual *work* is done individually. Maybe we're just doing it wrong!
I seem to do that alot, but I got about halfway through the comments here.
I agree completely that breaking the project down into chunks for each person works best, you just tie that up a bit so everyone knows a little about everyone elses part to make it a team effort.
I will paraphrase: Those who can, do. Those who can't, manage. And to be frank, I have seen this alot: Those who are good at their jobs don't want to become managers, they want to do their job. Those who are crap at their job want to train to become managers. Not always true, but it seems to apply the majority of the time.
So techies are loners? What are they supposed to do - hangout on face book? Wanna know why my "friends" are on irc and I hang out with them? 'cos no one in Real Life knows/cares what I am thinking about or will appreciate the hurdles I jump to get stuff __done__.
Some techies smell, others fear sunlight but most are normal people that have (shudder) social lives, friends and families.
If this guy is a Prof then I am a CEO of a major start-up.
Part of my training as an Engineer, was to take a complex task, break it up into much less complex, and manageable blocks, and a part of this process was to identify which key skills and resources are needed to complete the task, and then to pull in the resources required for the various subtasks. An engineer is supposed to be able to know when their own skills are insufficient, and then to pull in the necessary skilled resources for what ever task, which means they're a long way into the management side of things.
Once the set of manageable subtasks were identified, and specified, then resources would be assigned, according to skills and interests, which may or may not include teams.
At the same time you are expected to keep your eye open for opportunities to improve the processes, that is not just to do things as "we usually do", while assuming the responsibility for the tasks which you are working on.
I have had a lot of debates with MBA people about Hollistic task performance, where the problem is to be solve in entirety, as a single unit. Then the complex task is not broken down, but a lot of people try to solve the problem simultaneous, in a forum based on concensus, resulting in nothing is even vaguely working, until it is completed, where problems are identified late in the process - Do you ever wonder about the huge budget and time line overshoots ? I don't.
When teamwork is necessary for a task, then teamwork is good, if the task is too simple for a team, such that the inter person communications consume vastly more resources than the task it self, then teamwork is not a benefit, and is actually a delaying problem, it is a part of an engineering approach to identify these situations.
On a side note, the best department head I ever had, came with an interesting statement on his first day, that I'll never forget.
"I know nothing about what you do, nor how you do it, but it is my task to make sure you have whatever you need to do whatever it is you do. I trust that you will do your job as best you can, and I will do mine"
He took care of customers, politics, finances, resource requests, and acted as a filter between the customers and us. He managed the non-technical tasks, and we got on with the technical tasks, coordinating when needed.. Basically the engineering approach, the appropriate resource on the appropriate task, and team work when needed. Never seen a more efficient group in my life.
About procrastination, well everyone does that to some extent, it is rare that people do not do this.. As an engineer, I prefer to be ahead of schedule, if it is possible, as it is then possible to anticipate problems before they become really bad problems. However, that aspect is down to personality, and not so much skills or training.
......The guy is a natural manager.
An engineer says "One should never subcontract ones higher brain functions".
A manager says "The first thing one should do is subcontract ones higher brain functions".
This is why engineers and managers exist. It's also why they often insult one another.
I kid you not, TFA sensitized me to the concept, and one day later I see this management article about how the downturn in the economy, layoffs and part time are playing havoc with teaming.
Oh the managerial horror!!!
We have fewer people, they have to spend time working, actually producing, not collaborating on committee meetings! The Managers won't have enough work to do and will be the next on the chopping block, taking their team building skillz with them!
ooh another attack on democracy..these bl88dy engineers eh..
look.. mate.. . you can't design/invent by comittee.. sorry .. perhaps this is discrimination against dim wit fluffy sociology types (who spent most of their time in the bar or handing out radical anarchist pamphlets at Uni if memory serves me correctly)it involves constant decision making and that 'vision thing'..
here's a typical randd conversation..
accounts/ penpusher/ whatever..'how long will it take to program (invent).. such and such' ..
engineer.. 'i don't know i haven't invented it yet'
Want to bet the companies who want to outsource everything to India etc will use this research as their latest pretext? Their babble about how Indian engineers 'demonstrate more appropriate attitudes towards teamwork' can be translated, as usual, as 'they co-operate with our cheap labour policy'. Politicians in on the game will tell Western engineers that they need to get better social training before companies will hire them and then have their minions put out courses designed only to part desperate or ignorant students from even more of their money. Meanwhile, the West crumbles...
Paris because she doesn't like things that crumble.
"I know nothing about what you do, nor how you do it, but it is my task to make sure you have whatever you need to do whatever it is you do. I trust that you will do your job as best you can, and I will do mine"
He took care of customers, politics, finances, resource requests, and acted as a filter between the customers and us. He managed the non-technical tasks, and we got on with the technical tasks, coordinating when needed.. "
Fatastic. Unfortunately, I have a manager (but not for much longer because I've just quit), that is a utter control freak. He freely admits he's not technical, yet, whilst I'm out on a client site in another country, he proceeds to tell *me* - a technical consultant with nearly 20 years experience - how to debug a software problem!
Later in an email to me he made a sly reference to the earlier issue implying that I was wrong. Being incensed I put him in his place reminding him that my analysis and solution were indeed correct, not suprising given I had nearly 20 years experience.
I don't think he liked that! 8 months later, when the company starts laying people off, I was the first to be kicked out. The final result is they laid 5 us off without pay, indefininitely, telling us to go get benefits or jokingly find a job at B&Q !
So they've been getting rid of their consultants, the people that go out and bring the money in, meanwhile the managers pay themselves a secret end of year bonus (trying desparately hard to keep that fact hidden from their staff - they normally pay their staff a bonus each year) and the over paid managers that do SFA and are nothing but an expense on the compaby suck the company dry.
This is a company where the IT manager can't even spend £25 or over without asking permission from said manager. This is a company where the ADSL router on the site is a home based £100 router which keeps malfunctioning, where if you need a memory upgrade for your laptop, it has to be scavenged from other laptops, where we're working with software packages costing £50K up and we''re given a 30GB hard disk for the laptop.
Where the email system, being an external service, doesn't even have an address book, so if you don't know the address of your colleague you can't look it up! If you send them an email and the address is incorrect, the email doesn't get bounced back to you! So you can't even make an intelligent guess at the email address and determine from the bounced email whether the recipient received it or not!
And this is supposed to be a professional IT company!
I say good riddance to them.
Author writes: The prof believes that this stereotype of solo engineering comes from "television programs and other media".
Um excuse me. Media stereotype? Where? I can't remember the last time I saw an engineer on my telly. There are never engineers on the telly. Only Doctors. (Who btw are usually portrayed as only slightly less worthy of reverence than God.)
Did they ever stop to think that yeah, maybe that just IS what engineers do? That maybe that's just how they are, genetically? I'm not saying it is, but I sure as heck suspect it.
Author writes:...typical engineering students would instead break the project up into separate jobs so as to avoid working collaboratively.
Well duh, maybe that's because they're smart enough to understand that the way to make people accountable for what they've done is to make it clear who's done what.
Author writes: Another troubling tendency, according to Leonardi, was that student engineers didn't much care to follow instructions as to how to solve a problem.
Why are these professors giving engineers detailed instructions on how to solve a problem, anyway? I seem to remember learning something in school about how the essence of engineering was the determination of how to solve a problem. If a person wants to follow instructions I suppose they oughta try cooking.
I worked as part of a team once. They were all shite except one other guy. We worked away separately and every now and again liaised over some caveats. When we were done we briefed first the sales monkeys then the management scum. Then the sales monkeys demoed the system to the "team" and we rounded off a few rough edges before demoing it to the people with the money or customers as we called them.
I thought it was shit, then I went to a place with ISO9000 and that COPC fuckology and I realised the first place was in fact the good old days.
The moral of the story for you young un is this: Those management arseholes would rather you were weeks behind on the project as long as they have an armful of reports and e-mails. In management circles those things are like cigarettes in prison, they try to buy their way out of an assraping with them. They always prefer paperwork to productivity.
Biting the hand that feeds IT © 1998–2021