Fourth in an occasional series on iGEM at MIT.

Earlier, I wrote a post ostensibly about choosing an iGEM project.  When I went back to look at it, though, it was all full of flowery pedagogy and very little about the brass-tacks practices and issues.

I’m happy to report, then, that the overall structure for the IAP experience I outlined in that article has worked well for the last three years.  Recall that we start meeting as a team in the MIT IAP (January term) — we meet for two hours an evening, the from Thursday of the first week through Tuesday of the last week.  So, if we don’t meet on MLK day, there are 13 IAP meetings.

Recall also that the point is not only to help the team choose a project, but also to help them learn while they’re doing so — about iGEM, about synthetic biology, and about research. My strategy has been to explore these topics through the lens of past iGEM projects, both at MIT and elsewhere.  Around the Weiss lab, we generally break a synbio project (in general) and a synthetic gene network (in particular) into three phases — sensing, processing and actuation. That is, the cells sense either something about the world around them or their internal state; they combine those signals to make some sort of decision or representation; and then they do something as a result of that computation.

To help the team explore these different aspects, I and the other team mentors (students and non-students) meet before IAP to choose some exemplar projects from previous years.  For each of the three topics, we choose three teams whose project embodied that topic done well. We also strive to be diverse — for example, the sensing projects are generally sensors of some intracellular molecule, some biological extracellular molecule, and something physical (like light.)

We break the iGEM team into three sub-groups and each sub-group will be responsible for presenting one team’s work.  The first day, the team mentors work with the students to understand the project and make a (brief! uncomplicated!) presentation about it. The second day, each sub-group presents. This has two goals: first, it helps the entire team learn about all of the projects.  Second, and perhaps equally importantly, these presentations help students get comfortable talking about other peoples’ science.

We also give the students a (brief!) template slide deck to help them think about the project — help them ask the right questions.  There are four slides:

1. What was the team’s goal?  What problem were they trying to solve?
2. What was the team’s approach?  How did they go about solving their problem?
3. What were the team’s results? Did it work?
4. What transferrable ideas are there? What could you maybe use in your own project?

This also helps students begin to see that there is a traditional structure for talking coherently about science.

We also include a fourth topic for the groups to study: human practices. Here, diversity is particularly important — teams do all sorts of cool things in outreach, yes, but also in ethics, in IP, in business development, and in other areas.  It’s really important to help new iGEMers appreciate the breadth of possibilities so they can choose a human practices aspect about which they are excited.

If exploring other teams’ projects takes 8 days, that leaves us 5 days to work on choosing the team’s project for this year.  As we go, we remind the students that they should be thinking about problems they might want to work on in the context of a synbio solution, even if they don’t know how they might want to approach it.  Then, when we get to day 9, we start with an open whiteboard, and ask people to propose problems they might want to work on.  People can propose multiple problems, or people can decline to pitch one.  After soliciting ideas, each person chooses one problem. A problem can (and frequently does) have multiple people working on it.

Then, we go several rounds of pitching the problems, getting feedback and questions, and refining. Here’s where we start thinking concretely about what kind of approach we might take. In general, the approach is written out as what a cell senses, what the cell does in response, and how this solves the problem we set out to address.

This is also an excellent time to think (with the team!) about what makes a good iGEM project.  Note that this is usually condordent with what makes for a good research project, but not always.  In my personal view, a good iGEM project is:

• Impactful — ie, it solves an important problem.
• Exciting — ie, a synbio approach has the potential to be a much better solution than “traditional” approaches
• Feasible — a thing that our lab has the expertise and resources to support.  In general, this means we’re a mammalian synbio team, but not always.  (Yeast might also be okay.)
• Supports strong modeling and/or computation.
• Supports strong integrated human practices

As the project ideas get more refined, we insist more and more that the people pitching them get more and more explicit about how their proposal fits these ideas, and more and more concrete about the approach they want to take. Then, at the end of IAP, we vote for the first time.

A quick aside about voting — I have found that formal voting processes work better than informal ones.  Ie, we don’t vote by holding up hands in our conference room.  Instead, especially because there are (usually) a large number of possibilities relative to the number of voters, in recent years I have run a Borda count using the Opavote website.  (It’s free for small polls.) Instead of producing a “winner”, it produces a ranked list, and at this point in the process we generally narrow ourselves down to three top candidates and ask the team to split into subgroups to further refine their ideas.

(Sometimes, everyone wants to work on one project, at which point that is the project we go with.)

At this point the semester begins.  We generally tell the team that we expect them to spend 4 or 5 hours each week on iGEM — 90 minutes or two hours on a weekly meeting, and 2-3 hours working independently.  Each meeting is just the “update/pitch” part, and we encourage the subgroups not only to work together offline but to consult with the mentors as well.  At this point, the “what problem are we working on and why is it interesting?” part of the conversation is generally pretty solid.  What we continue to work on is the approach — making it more concrete and more detailed, so we can evaluate feasibility.  I generally give the students a deadline of the end of February, which means they’ve got 4 or 5 more weeks.  Finally, we revisit the discussion of the things that make for a good iGEM project, then we vote again, again using Opavote, but this time using an Instant Runoff rule.  The team members still rank the projects, but at the end a single choice is made.

One final note. Students can get really invested in their chosen project, which is a good thing — we want the students working on things that they are interested in, even passionate about. The flip side is, if that project isn’t the one that’s chosen, those students can be quite disappointed. I always try to address this head-on — by this point in the semester, I usually think all three projects are really cool. I like to let that enthusiasm show. And I always promise the team that, if they want to come back after iGEM as a “traditional” UROP, we’ll work on their project together. (So far, nobody has taken me up on it.  Some day, maybe?)

Next up — refining the project.