Da Vinci, Frankenstein, Edison, Einstein, Every Evil Genius, Zuckerberg
Our science narrative has expanded to pairs of geeks in garages
Hewlett & Packard, Gates & Allen, Jobs & Wozniak, Brin & Page
but hasn't yet embraced the fundamental reality of modern science: most work is done in collaboration. Most great big ideas are the product of many great small ideas.
This is why there's no satisfying answer to questions like "who invented the atomic bomb". Was it Fermi? Einstein? Oppenheimer? Of course Al Gore didn't invent The Internet, but who did?
As a graduate student, you are, at worst, Igor, the hunchbacked assistant doing all the work and getting none of the credit. At best, you are a near-equal collaborator with your advisor. But there's a sea of collaboration waiting once you're out of the nest and on to the next step.
Since becoming a professor I've noticed a handful of types of collaboration. From intimate to remote, they each have a role to play.
Peer Collaboration
This can be the most satisfying and most productive way to work with a partner or team. You sit in the same room, or with a chat window open. You talk through ideas, big and small. You tackle the parts of the work you're most suited to, or most excited by. You debug code together. You run experiments together. Try to make sense of your shared results. You iterate over writing papers together.
It can also be the most frustrating. A group only walks as fast as its slowest member. If you don't work well with your partners, for any reason, the stress is visible almost immediately. If the partnership is strong, you figure it out, and get back to work. If it's not, you'll know pretty quickly.
Mentor-Student Collaboration
There's a similar intimacy in this collaboration, but there are some very clear differences. First the pace of collaboration is typically slower. At slowest, you may only work with your student only once a week. Even if you're in regular email contact it's only a couple of times a day. Typically it's only during the most intense periods of an evaluation or paper deadline does the collaboration reach the level of immediacy and proximity of peer collaboration.
The division of labor here is more driven by the hierarchical nature of the relationship. The mentor typically has a broader vision of the work, while the student has a better grasp of the details. (Or if they don't, it's part of the responsibility and training to learn about the details.) The mentor has the responsibility of contextualizing the work, either into a broader research agenda that will include the students thesis as an offshoot, or into a broader project or publication. At the start of the relationship, the mentor is typically responsible for guiding the research, determining which research questions are most fruitful and
Over the course of graduate study, a good mentor-student collaboration will take on more characteristics of a peer collaboration, with the student ultimately initiating most of the research ideas. But there's always going to be a level of deference that the mentor receives.
-----
As a graduate student, I had a lot of experience with the previous two types of collaboration. I even had some exposure to the next three, but so much as to be able to identify the differences, or how they impact the work.
-----
Project Collaboration
On medium-to-large multifaceted projects there are frequently multiple PIs (principal investigators) each with independent research groups. Collaboration across sites towards a common goal is different and challenging. The PIs coordinate with some frequency. There are bureaucratic reasons for this -- mostly around budgets and report writing -- but coordination between students is much less common. Each of the individual research groups have their own broad responsibilities, timeframes and agendas. Each are balancing a number of projects, student milestones (qualifying exams, etc.), and specific personnel decisions.
The biggest difference in this kind of collaboration, in my experience, is the pace. The interaction between groups when it comes to research is infrequent. Sometimes just a few times a month. Another difference is in the level of detail. When the groups share their work, it is usually at a relatively high level -- far removed from unsuccessful approaches and interesting failures. There are opportunities to get advice at a high level about directions and plans, but close collaboration about specific decisions and approaches is much less common.
This is completely understandable. The nature of this collaboration demands it. These projects are big enough to demand a large number of people working on them. This task oriented partitioning into research groups is probably the best way to manage the effort.
However, there's the time when the rubber meets the road. This is usually in the form of deliverables, where you have to send a report or code to a funder, evaluations, where all of the moving parts that the groups have developed have to work together, or presentations at site visits or PI meetings, where you have to show that you're all working towards a common goal.
Often, these moments demand closer coordination and collaboration. Having made a few mistakes. The lesson I've learned is to stop and drill down. Take meetings offline to deal with discrete questions and issues. Get the students involved in these meetings. If at all possible, visit your partners. With your students. One hour face to face can take the place of a few days worth of emails.
Still another step more removed is the kind of collaboration you have with the scientific community which you're a part of. This is the sort of collaboration where you have a conversation with someone about an idea that one of you is chewing on. You bat the idea around for a little while, maybe hear about a technique you didn't know about or hadn't thought of, and then the conversation moves on. I've found that this kind of collaboration occurs with someone you know. Either you know each other's work, or you have a mutual colleague to bring you together.
Most of the time this type one-off micro-collaboration ends with a single conversation. Sometimes it results in shared data or tools. But given the right alignment of circumstances it can foster a more serious coming together. Usually just an extended conversation over email, or a phone/skype conversation, but if fate is really on your side, this can grow into a paper or a grant proposal. But by this point, you've switched categories and you're working much more closely.
I find that this collaboration is most available during visits to other institutions and at conferences. Frankly, this kind of collaboration is often the most valuable thing I take away from conferences.
"Public" Collaboration
If you're doing it right, people are going to know about your work. People will email you with questions and comments. You will get queries about how to use a tool you wrote, or (maybe more frequently) a bug report or feature request. Through this communication you are supporting other people's research. This rarely turns into a more substantial collaboration. But if it means that people will cite your work.
Here, the collaboration is somewhat lopsided. Essentially your prior effort of writing a paper or tool are supporting someone's current research. But this needs some additional support from your current self, either in clarification or amendment. The upside is that if the system is working, you can garner this support as much as you give it out.
Here, I find the challenge is to appropriately prioritize these interactions. More frequently than I'd like to admit, these are the emails that filter to the bottom of my inbox.
If you're reading this, and I still haven't gotten back to you, I'm sorry. I know these interactions are important. I'm working on it.
