When we look at how engineering student teams do the work they are assigned to, we can follow through the subdivision of tasks and come up with some "functional role"s that need to be fulfilled.
The matching of these roles to the individuals is not one-to-one, naturally, and should not be: Ideally, every engineering student is ultimately required and assumed to have gained the specific skill set required for all of these functions. But due to the diverse interests and dispositions of different students, such factioning can and does occur by itself. The plus side of this is that the students become better and better at what they do as they move through their years of college experience. The negative side is that they might ignore or fall behind in some of the relevant skill sets, even though it is not realistic to think that after four-five years, any student will not have at least some feeling for all the skill sets. But, especially if the same people keep on long-standing partnerships, preferred roles might also emerge. Similarly, if people who have not worked together before come together for the first time for a project, the group dynamics might naturally push them to perform in the same functional role that they have previously been comfortable with in previous teams, rather than try on new ones.
Often---especially when the teams are small---members can take on more than one of these roles to a greater or lesser degree. This piece of writing does not attempt to identify clear-cut boundaries between people, but does strive for identifying the nature of different tasks that an engineering project team performs in the course of doing their project. To a great degree, it is the tasks that are "personified" in the example students described below.
In broad terms, some of these functional roles can be identified as follows.
This student is at home in the library. Knows (online or otherwise) databases for research papers and books, tracks references, and builds a base of them for later use. For example, as the research group is writing a paper about a process that they believe is new, this person will come up with an obscure 1971 paper that introduces the same process, having tracked that through references of references of references. If the project group is not quite sure how to solve that complex differential equation, s/he finds which diff equations book has a section on similar equations, or might even remember reading the section heading in that particular book.
This student is at ease when interacting with computers. He/she will be more aware, than average, of the features of the simulation or CAD program required for the project and can therefore use it more effectively and speedily. If a new package needs to be learned and used, this person can probably start using it faster. As the student advances, s/he can make comparisons of different packages available for a job and choose one. When the project group needs to try many resistance value combinations to achieve a required amplification value in a circuit, this person will write a program that goes through the possible combinations and automatically picks out the best one, then distribute the program to the whole class. Usually the first to reach for the keyboard when a complicated symbolic integration appears in the homework.
The lab mouse. Knows what the XY-button on the oscilloscope does before the TA demonstrates its use. Knew how to use a drill before it was required in the project, or has less trouble/hesitation learning than others. Likes playing around in manufacturer catalogues to choose parts for the project. Comes up with makeshift test setups or repairs the existing, non-functioning one. Steps forward when something goes wrong during the demonstration.
Ideally, this student is what all students are supposed (or assumed) to be at the end of the course or project: The person with the most comprehensive grasp of the subject material. Analyzes the circuit to be designed by paper and pencil, derives the transfer function of the feedback/control system, writes the differential equation describing system motion. In these roles, can be the driving force behind the project. Explains/interprets test data faster than others and is an asset for systematic debugging.
The person with a knack for words and composition. Writes the report, prepares the documentation, creates pretty (read 'clarifying') illustrations. Has a hand in preparing the presentation and, unless other personality factors intervene, can be the most self-confident presenter. Can put a report together faster or write more methodically than average, creating a better presentation of the group's work.
These roles, of course, overlap as mentioned above, and the more they do, or the more smoothly they interact, it seems logical to assume that the smoother the project process will be carried out. For instance, if the same person has strong tinkerer and theorist sides, or if the tinkerer and theorist work together, the debugging of the product will be that much easier.
It might be interesting to relate these preferred roles to personal learning styles; to assess how the students develop in each of these skills; to see if there is an observable breakdown of social groups between these skill sets; to see to what degree specialization occurs or does not occur and how that affects the students' personal developments.
NOTE: To a great degree, the above is an attempt to distill personal experience and observation; I really do not know where to look to find citations for these points. I guess I'm not a literature researcher, at least not in educational psychology...
Zeynep Dilli, Nov. 7, 2001