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,


Posted in: