It’s the most wonderful time of the year!  The beginning of a new iGEM team!

For those of you not in the loop, iGEM is a synthetic biology competition: teams build biological systems using reusable genetic parts, then compete for fame and trophies at the iGEM Giant Jamboree in Boston each fall.  iGEM started at MIT twelve years ago, and has since grown to over 350 teams (primarily undergraduate) from all over the world.

Oh, and I’ve run the MIT team for the last few years.  This year, I figured I’d try posting a few things from the perspective of a team instructor.  I think there’s a lot to be had out there on the experience of the team participants, and maybe a little less on the challenges (and rewards!) of being an instructor.

Today’s topic: choosing a project.

I and my boss are trying to provide the most authentic research experience for these students that we possibly can.  And so we let the team choose their own project.  This has some advantages and some challenges:

• The team owns the project.  This is huge.  You get a huge boost in engagement (and, I suspect, learning!) when the team is working on something that they want to work on, a problem they think is important.  It gets a lot easier to log the late nights (especially towards the end of the summer and into the fall as we get ready for the Jamboree) when it’s your baby from start to finish.  When we talk to past MIT iGEM students about what their experience means to them (or listen to them talk about iGEM to prospective iGEMers) this comes up over and over and over.
• The team doesn’t know what’s not possible, and they come up with great ideas.  This has resulted, a number of times, in projects that have since become research foci for the lab. Are the kids going to turn out a publication’s worth of results in a summer?  Not likely.  Is there enough to put as preliminary data in a grant application?  You bet.
• They consistently overestimate how much they’re going to be able to get done in a summer.  And so we have to help them scope the project.  Unfortunately, we as advisors sometimes get it wrong too.
• Sometimes they want to do something that we as a lab don’t have much experience with.  That got us into trouble last year: we let them choose a project involving both some DNA manipulations and some analytical techniques that we as a lab didn’t have much experience in, and it took us a long time to get up to speed.

Image credit: Shinjini Saha

Unfortunately, choosing a research project is hard.  Even when you’ve been in the field for years, it’s hard to pick a project that is exciting, important, and feasible.  How can we expect these poor students, usually completely new to research science, to get it right?

No, that’s the wrong question.  The right question is, how can we help them learn to do so?

Ah yes.  Much better.  Now I can apply all those good pedagogy skills I’ve been acquiring.  If choosing a project is something we want the students to be able to do, then what kind of knowledge will they need to do so?  What skills?  What scaffolding?  What support?  What opportunities for practice and feedback?

I’ve been working with some amazing students from previous years’ iGEM teams on this problem.  The plan is to do most of this over MIT’s Independent Activities Period (IAP), the four weeks in January where students are on campus but not taking classes.  (Whenever you hear about MIT students doing something crazy, it likely happened over IAP.)  I think we’ve got it broken down into a couple of pieces:

1. Get a sense for iGEM.  We’re going to start with a deep dive into a single exemplar iGEM project (either the 2014 MIT project or the 2013 Paris Bettencourt project) as a way to get a handle on what an iGEM project generally looks like, and all the deliverables.  I think both of these teams did things that were interesting, important, and feasible, and I would love to see something similarly scoped from this year’s MIT team.
2. Get a feel for how we do synthetic biology.  The Weiss lab tends to think of synthetic biology in terms of sensing the cell’s environment, computing some sort of function on a set of inputs, and actuating some output whereby the cell modifies its environs.  The plan is to spend a day on each of these, choosing various past iGEM projects we think did each of these things particularly well for the students to explore.
3. Capture ideas. This is the point, right?  Each of these discussions will include explicit brainstorming about how this year’s team could apply a similar strategy or approach to problems they find interesting.
4. Refine those ideas.  This is the last few days.  Hopefully, between asking the students to propose things in their submissions, and the discussions we’ve had as we explore past projects together, we’ll have a huge whiteboard (or a wiki page) full of interesting things to think about.  We’ll start with one person per idea, and they’ll go off and try to build a project proposal around that idea.  Then they’ll all present, and we can offer feedback.  Eventually we’ll start winnowing down to the ones that are interesting and feasible; I think that will happen organically, but others have suggested that we’ll need some structure.  We’ll see.
5. Foster ownership.  This is something we’re still working on.  In the past, we’ve always come down to two or three ideas and a team vote: and that always leaves someone disappointed.  This year, I want to do something to try to address that: maybe we’ll round-robin people and projects, and say “okay yesterday those people worked on this project, today you work on it and see what you can come up with.”  That may dilute out expertise, though…. ?

Credit: Shinjini Saha

I think this plan has a few nice pedegogical things going for it:

• Demonstrate expert thinking.  The case studies of previous well-structured and well-executed iGEM projects will be chosen by the instructors.  I think we all have a pretty good feel for what a “good” iGEM project looks like, and even if we say “focus on aspect X of this team’s work for tomorrow” I think that repeated exposure to generally good projects will hep steer the students in the right direction.
• Provide structure for learning.  It’s easy to say “go look at a few previous teams’ projects!” — but there were 360 teams last year; if we go back 4 years or so, we’re at well over 1000.  I think we’ll have much better success with “this team did a fantastic job at building a new sensor; go learn about building sensors from that team.”
• Provide resources for missing knowledge.  There’s an immense amount of domain-specific knowledge required: from basic biology (who remembers the central dogma from highschool biology?) to research techniques (quick! what’s the difference between a Southern Blot, a Northern Blot, and a Western Blot?) to a basic feel for the state of the field (who wants to do something fun with CRISPR?)  I think the only good answer here, for such an ill-defined question, is to have people around that can answer these questions in a high-throughput way.  If we make them go look everything up in Wikipedia or Alberts, they’ll never get anything done.
• Provide opportunities for practice and feedback.  The general structure for the first few days will be “go off and look at this team’s project, focusing on (say) how they applied information processing … and then come back tomorrow and tell us about it.”  Later in the week, it will be “go do some research on this idea that you had … and then come back tomorrow and tell us about it.“  I think this opportunity to try their hand at understanding someone else’s work, or at thinking critically about their own ideas, and then having some close-to-immediate feedback to help them refine their thinking, is really going to be key.
• Provide structure for learning, part 2.  The tasks here (“research this project idea”) can be awfully ill-defined; our answer is to use templates and rubrics.  If the task is “tell us about Paris Bettencourt’s design of a new TB drug screen” it’s not necessarily obvious which parts we want them to pay attention to.  If we say “give us a brief presentation tomorrow on this project idea” it’s not clear what will help us, and the team, evaluate that as a possible iGEM project.  So the plan is to offer rubrics and templates to help them do so.  Questions to answer; maybe a PowerPoint template to fill in.  The risk here is that a template puts the students in “minimum effort” mode — “I have answered these questions, now I’m done.”
• Keep the students focused on their goal.  The goal, remember, is to choose a project idea!  So, if we spend a day talking about other teams’ biological sensors, that discussion will have explicitly threaded through it a discussion on how similar ideas, or similar approaches, could be used on problems the team is interested in.
• Keep the students engaged.  I want to absolutely minimize the amount of time I or the other instructors spend talking.  This is not knowledge transmission: this is a set of skills to learn by practicing them, with support and feedback, on interesting problems, in a context that will actually matter because the end result (an iGEM project) is something we’re going to be working on the for next nine months.

So I’m pretty excited about this plan.  I think there’s some sound teaching philosophy here, and the authenticity of actually starting iGEM (instead of “let’s do some basic lab work that you won’t remember in three months!”) is going to be a heck of a motivator.

Thoughts?  Leave a comment, I’d love some feedback.  Want to follow along at home?  The syllabus and all of the knowledge we capture is going to be posted on the MIT iGEM wiki.  At the moment it still has instructions for applying, but that will be changing soon.