As the semester comes to a close and everyone is busy finishing up their projects, I had a thought.

Working in groups at Olin is hard.

My Software Design team works on building Pricecod (Photo by Bennett '09)

And, well, this is why Olin stresses team-based projects in many, if not most of its classes. The idea is that by learning (suffering?) now, students will develop the teamwork and communication skills that industry tells us they so sorely lack. There is a huge discrepancy between the engineers in corporate environments who mostly work in teams, and undergraduate engineering students who traditionally focus on individual work and projects. Olin is specifically trying to resolve this discrepancy by reforming undergraduate education to incorporate the "increased emphasis on business, teamwork, interdisciplinary design and communications skills" urged by leaders in the engineering industry.

I think it's a great idea. I'm worried that Olin's approach of having mainly team-based classes is too broadly applied though.

The experience I had this semester made me feel that the structure of Olin's groups in content-based classes is fundamentally different than anything we'll see in our future jobs, and that this approach is neither helping us learn now, nor preparing us well for our post-graduation lives.

When working in San Francisco (never as an engineer), group responsibilities were always very well defined. In some situations, I would be working with the Designer and VP of Engineering to flesh out the product roadmap. In these meetings, we'd all bring our ideas and research to the table, and hammer out a plan. The designer would then go make the necessary graphical resources, I would write up a functional requirements document, and the VP Engineering would work out the database design and technical implementation. Later, I would be working with engineers to get the new feature built. They would ask me questions on the design, interaction, and prioritization of various aspects of the feature, which I would either know, decide, or go find out.

In my software design project, my three person team was at a bit of a loss trying to figure out how to divide up our tasks. We were all learning Python for the first time, we all wanted to learn how to design software well, we had different strengths in different areas, and we wanted the workload to be approximately equal. But where to go from there? The main source of difficulty was from not having a clear goal in mind - were we trying to learn the most about something new? Learn the most from each other? Become experts in one area of software design? Complete our project in the least amount of time as possible? All of these goals have very different work structures. I don't think this situation arises much in industry, and I doubt the usefulness of having us struggle through it.

So the question is, do teams have a place in subject-oriented classes? How much do they contribute or detract from learning? I don't know this from personal experience as I'm just now finishing up my 3rd semester, but I suspect (hope?) that Olin's pretty good at combining its interdisciplinary focus and its focus on teamwork in classes like PoE, Systems, SCOPE, PDD, and Rapid Prototyping. I'm excited to take these classes because I'd love to work with a team in a project/deliverable oriented class, where students from different majors (and with responsibilities corresponding to their majors) are intentionally brought together. I think these projects both increase the depth of a student's specific knowledge within their field of study, and increase their general communication and teamwork skills. It's when everyone in a class is trying to learn about the same subject that I have doubts about the value of working in groups. If there's a set amount of skills or knowledge students should have at the end of class, and completing a project encompasses all this learning, it seems all too easy for some things to slip through the cracks for some or all team members. Might it be better for them to do individual work rather than work in a group where knowledge and learning is necessarily fragmented?

Just some of my thoughts - let me know yours,



Working in a team with defined roles is significantly easier than having to subdivide labor and assign roles to each person. I'm going to argue that working in teams for subject oriented classes makes sense in a lot of cases because it forces people to confront those very issues, which makes us into stronger team leaders [because we are aware of these potential problems and have some experience dealing with them]. Besides, we also have very few "subject oriented" classes, and most of them involve much more minimal teamwork - I would say that Software Design was never a "go sit by yourself and code" focused class, and was always project and collaboration oriented. After all, we were expected to learn nearly as much about documentation, language, good commenting, and UML as actual coding.
I guess I'm basically still all for the group work stuff, although I agree that having to define your own roles and divvy out work is unrealistic for most entry level positions. Useful if you're doing a startup though...

I actually feel like having to work in groups in subject-oriented classes is one reason why I feel like I am lacking some solid knowledge in certain areas. Because no matter what, time is a huge source of pressure at Olin. In my experience, there were many times where we were pushing to put out the highest quality work in the shortest amount of time we could--because we had dozens of other projects competing for our time. In a situation like that, sometimes it seems to makes more sense to let everyone work on something that plays to their strengths to streamline the process. I definitely feel like that sort of situation played out many times in my Olin experience, and as a result, I've learned less than I could have, because I didn't get involved in aspects of the project that I wasn't as skilled in. While I guess you could argue that if I were truly responsible for my own learning, I would have gotten involved in those more difficult portions of the project to make sure I was learning that material, I did often find myself or my teams collectively deciding that it was more important to put out a quality deliverable in as little time as possible to save ourselves some sanity (and sleep).
I also want to point out that for me personally, grades were definitely an added pressure to get things done in teams quickly, and efficiently. Which meant sometimes I did choose to do work that I was already skilled in, while letting other team members do work that I would have loved to learn, but would have taken me much longer to do (thus slowing the project down). I know at Olin we don't like to talk much about grades, or like to believe that grades become a motivating or relevant factor in our experience and learning, it is definitely something that companies, graduate schools, professional schools, etc. care about. So whether it is talked about or not, it does affect (at least for me, and I'm sure other Olin students as well) how we choose to make projects happen at Olin.
I wonder what would happen if, in subject-oriented classes with team projects, we had frank discussions with our team members before starting the work, about what our personal learning goals for the project work, and divided work up accordingly? Rather than trying to go for maximum efficiency. Maybe it's okay to turn out a smaller deliverable, if everyone learned more?
I definitely did not intend to write that much--so I'm glad Maia, that you are putting this out there for discussion :)

@ Nikki
I do agree that for a start up and particularly a small company, you must have some team effort. However, in my experience I have seen that there are so few people that are able to function as a team that it is hard to surmount this barrier. One summer I was working with a web design team and they were working on a website, at that time I had little programming experience so I sat and watched. I noticed that they were unable to coherently work together and this cost us many hours of trying to backtrack and so forth. I also noticed that every time there was a major problem, the programers typically went outside to take a smoke and cool down. For some people, the inability to work in groups makes them more vulnerable in the higher tier jobs, because larger companies or even small startups need people that are efficient and do not waste time. When the boss comes in and says "I need a program to calculate Pi and display the results in Roman Numerals," the programers must be able to realize that they can break up the task in various object classes and yet they must work as a coordinated effort to prevent unnecessary waste of code, time, and money.
@Carmelle ' 08
After working as a publisher on the school newspaper I have considered your opinion, and reflecting upon it, I agree to a certain degree. However, I am aware that I do not currently attend Olin and that I can not speak for your current situation. In the past 3 years I have been working for the school newspaper, I have had to work with 2 other publisher for a paper that is published monthly and is typically only 12 pages. I have learned more about having to work with others who have completely different skill specialities. For example I am very crafty at the actual layout, but my skill with photoshop is next to nothing and that is managed by another publisher. I have noticed this and attempted to make the files myself, but in the time it has taken me to adjust one image the other publisher has completed around 5. I have realized it would be a drag to attempt to become widely versed. I have noticed a trend in the 17 years of my life and noticed the trend since I have been in high school for a grand total of 3.5 years as of now. And the trend is that we are trying to be knowledgeable in many areas as opposed to specializing in one particular area.
I will say that in my Computer class, we have two different groups. Those who care and embrace programing, and those who did love programing until we started arrays and then it went downhill from there. One problem that we continually have is making the decision to have groups or work alone. And if we were to have groups should we segregate the skill levels or should we mix and blend the various knowledge. All three options have their pros and cons. However, sometime it is best to embrace all 3 in various regards.
On that note, I have a semi-unrelated question. Is there like an underground website for the students where the professors post their lectures, notes, and assignments? Because I am unable to find this on I am assuming it is not so easy to get to. Is my hunch correct? Is there a different website for all of the other daily items? I am also curious as to that Carmelle stated that you think that the lack of the variety of discipline when it comes to certain areas of programming and I am guessing other group related assignments (possibly labs?) does this prove to be a big issue or just one of the setbacks of certain programs?

In my personal opinion, I think subject oriented classes should have both. The best example of this I can think of is Brian Bingham's dynamics class. The class makes sure that students individually take the time to learn the "solid" material through problem sets, exams, individual assignments, etc. But what distinguishes the class from a typical dynamics class are the opportunities to do team work as well - there are "application problems" and some pretty cool labs where you work in groups as well.
I think it is important to make sure that specific engineering programs (i.e. MechE, ECE) provide students with the technical knowledge they need to succeed as engineers, and I agree that subject-oriented classes that incorporate a large course project risk undermining this goal because of the reasons Carmelle and Maia outlined.
However, I think there is room within subject-oriented classes to incorporate group work. I believe it is an important skill because at many jobs you not only need to have interdisciplinary teamwork but also intradisciplinary teamwork as well. These group assignments shouldn't be the "final deliverable" of the course, because we have enough awesome project-based courses at Olin, but they should still motivate students to develop teamwork skills within subject areas.

To begin, Jason: no, such a website does not exist. Each course either has it's own website, somewhere on the internet, or homework/etc. is sent out through a mailing list, or something along those lines.
On the team issue, I agree totally with Carmelle: we should sit down at the beginning of the team and talk about what we want to learn and divide up the tasks that way. I definitely remember this being something the profs addressed in a Design Nature lecture as a recurring problem and one we should actively try to correct.
I definitely feel like I've failed at that on some teams; I had a lot of experience with programming before coming to Olin and sort of instinctively took most or all of the programming work. I'd try to make sure my teammates knew what was going on, but they would have probably learned a lot more by doing the work than I did.
Some stuff I found that works, besides sitting down and talking about what you want to learn: working in parallel. When working in smaller groups like pairs, just do all the math/coding/whatever in parallel. This is especially great since you get to see if there were any mistakes made a lot easier - if the two answers don't agree, you made a mistake. And both people would generally understand what was going on better: it's very easy to agree when someone tells you how they did something, but when you have to do it yourself, any uncertainties or lack of understanding is a lot more obvious. It might seem like twice as much work, but it's a lot better than one person mathing and one person picking their nose. :P Or even one person mathing and one person coding.
But on the whole, I'm glad Olin is so full of team projects. I think even overcoming the challenges of making sure everyone learns what they want versus everyone doing what they're best at is a great lesson. I've also found, and maybe this is just a skewed sample, but that projects are generally not judged very harshly: and even if you mess up, as long as you learned something and can explain what it is, profs will cut you a lot of slack. Which maybe makes everyone learning vs. everyone doing it quickly more feasible.
Just my thoughts.

Recent Assets

  • BuildDayCrop14.jpg
  • skating2.gif
  • p5.jpg
  • p4.jpg
  • p3.JPG
  • p2.JPG
  • p1.JPG
  • p6.JPG
  • 1238275_10203822713793076_1989476177796862635_n.jpg
  • P1040918.JPG

Recent Comments

  • Helen: To begin, Jason: no, such a website does not exist. read more
  • Nitin: In my personal opinion, I think subject oriented classes should read more
  • Jason Baron: @ Nikki I do agree that for a start up read more
  • Carmelle '08: I actually feel like having to work in groups in read more
  • Nikki: Working in a team with defined roles is significantly easier read more