iGEM: Money concerns

A quick post today because I’ve spent the last week at ABLE 2018 and my brain is full.  (Side note: ABLE was amazing. Looking forward to Toronto next year.)

Running an iGEM team is resource-intensive (read: costs a lot.) Here’s a breakdown of the MIT team’s budget (all numbers in USD):

Item Per-student Total (for 12 students)
Team registration 416.66 5,000
Summer stipend 4,600 55,200
Materials & supplies 500 6,000
Jamboree registration 700 8,400
Grand total 6212 74,592

A couple of notes about the above table:

  • Team registration is fixed — no matter whether the team has 3 people or 30, the cost is $5000
  • We commit to paying our team members a summer stipend — otherwise, very few of them would be able to stay the summer (and work 40 hrs/wk on the project). That is our biggest line item, but other schools may have a different situation
  • We are fortunate that we don’t have to worry about travel or housing for the Jamboree. Even so, Jamboree registration is consistently our biggest one-time expense.
  • The M&S budget is a round number based on prior experience.  We are fortunate that IDT’s iGEM sponsorship defrays most of our synthesis costs.

So yeah, that’s a lot of money.  (I am not going to dive into my feelings about how this excludes other teams who might otherwise want to participate — perhaps in a later post.)  The operative question is — where does the money come from?

In the MIT team’s case, we are fortunate to be supported by a significant amount of institutional resources:

  • ALL the iGEM team members (the undergrads, not the occasional highschool or grad student) apply for direct funding from the MIT UROP office. This is non-negotiable, because direct-funded students have their summer stipends taken care of.  The down-side is that the number of funded students fluctuates dramatically year-to-year.  This year, we had 9 undergrads apply and all 9 got funded.  Last year, we had 10 apply and only 6 were funded.  Then, we were left to find another $18,000 on short notice.
  • The Department of Biological Engineering generally chips in.  (Thanks, Doug!) This is founded on the fact that most of our students are BE students — and in the past, when we have students from other departments, we have asked the other departments (such as EECS) for support as well.  The latter has only seen mixed success.
  • We have been fortunate in the last few years to have had a number of one-off funding sources, from the MIT Media Lab and from philanthropists associated with the MIT Center for Gynepathology Research.  While we are incredibly grateful for the generosity of these donors, they don’t support us year-to-year.
  • Frequently, Ron’s grants have education and outreach components on which we can draw.
  • We generally solicit donations from companies in the area. This has never been particularly successful — I know other teams have had more success, so maybe we’re doing it wrong? What we’ve found is that companies are interested in funding particular projects instead of undergrad education more generally. That is, if we’re doing a health & medicine project, we do better asking from drug companies than from (say) energy companies.  (Aside: this seems really short-sighted. Pfizer, are you listening?)

Generally we can get our budget covered via some combination of the above sources. Unfortunately, what we are missing is a single, dependable, continuous stream of funding — what I would love is a regular contribution from the Provost, or an endowment of a million dollars from some grateful alumni. Unfortunately, this question causes major stress some years. And if a well-resourced school like MIT has trouble finding funding, I can’t imagine what it’s like at smaller schools.

iGEM: Choosing a project, part II

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.