Every researcher I know keeps a list of open questions and tasks that they want to get to next. This list is a best friend, and a worst enemy. This list is a hydra. Every time an element is taken off, two more appear in its place. To tame the beast, it takes a group effort.
It's no revelation to recognize that management is different from labor. I'm sure if I had an MBA instead of (in addition to?!) a PhD, some of these issues would be more intuitive. But I didn't, and most professors don't. We're self-taught.
When the research group is firing on all cylinders, it feels like my work is having a multiplicative effect, that I'm lifting more than I possibly could alone. When it's not, it's demoralizing. I try not to get sucked into this, but there are days when it feels like I could do more in a cave with a laptop, an internet connection and coffee.
These are some of the things about running a group that I didn't know before becoming a professor.
How to organize a research agenda
At my thesis proposal, Kathy McKeown asked me the hardest question: "What do you want to be famous for?" It totally blindsided me. I laughed uncomfortably, and looked to my other committee members for acknowledgement that this was an outrageous proposition. No help was coming. I have no idea what my answer was, but it's the only question I remember from my candidacy exam, proposal or defense.
A clear answer for this question, an organizing principle for the research that your lab will do, brings clarity and identity to the group. It represents a research agenda that guides the work. A clear research agenda serves a similar role as a mission statement and business plan. It communicates your goals internally and externally.
This also helps with recruitment -- if students and postdocs know exactly what kinds of questions you are interested in, you will attract people who are interested in these questions, and people who are capable of working on them. The same principle applies to students who are looking to do independent studies, undergraduate or master's theses with you.
I've generally under-appreciated the value of this focus. Personally, I've benefitted from broad research interests. I get a lot of satisfaction by working on a lot of different things. My most cited paper wasn't even cited in my dissertation. But I think I've also suffered from this generalist approach. I may have had greater impact on the questions I find most interesting had I limited my activities on the second tier. I may have made more progress in getting "famous" for something.
How to engender community and collaboration
Being a graduate student can be isolating. There are some classes. A weekly meeting or two that you need to show up for. But most of your work is alone.
How do you take a group of students who are organized only by you, the professor, and help them communicate, support each other, and become colleagues? I certainly had no idea.
Some things I've tried:
Taking everyone to lunch. this didn't work so well. it probably would work now, but at the time the students didn't know each other well enough and it was just pretty awkward.
Shared tasks. Inviting a group of students to work together on a short term project is the single best thing I've done to get students to trust each other and exercise their basic research skills. I use the interspeech paralinguistics challenges for these. I also invite other computational linguistics students to participate from the linguistics and cs programs. It's a really fun exercise and the students get a lot out of it.
Weekly lab meetings. One student gives a talk every week. It gives a safe space for students to practice giving presentations (and giving feedback on presentations), and it makes sure that everyone knows what everyone else is working on.
How to make and manage a budget
This is my least favorite part of the job. Making a budget is fine. It's just making puzzle pieces fit. But inevitably there is some wrinkle to sticking to it. Travel costs are more or less than budgeted. At CUNY tuition is highly variable based on what year a student is and how many courses they are taking.
And then there is interacting with admins, grants, financial officers and contract lawyers. These people are invaluable. When the relationship is good, your life is easy. When there are delays it can make sticking to the timing of a budget very very very difficult.
Having an eye for detail and the patience to use it really comes into play here.
Not everyone knows what I know
The next three observations are less about specific skills, and more about the personal effects of leading a group.
As a new professor with new graduate students, you know more than any other research group member. This isn't a "smartest person in the room" thing (though sometimes it is), but an experience thing. The professor has read more papers, seen more talks, (may have executed more experiments) and knows more about the topic.
The list of things that you want to work on next are based on your previous work, your thinking and your instincts.
In order for a student to pick up and work on a task, they need to get up to speed, and fast.
It is too easy to forget that the people working with me don't know what I know.
How to delegate
It became clear to me early on that not all CS professors still program. This struck me as a scary idea. First of all, I like to program, and I'm reasonably good at it. Secondly, it seems like distance between a professor and the nuts and bolts of research is a dangerous thing.
I was talking with Dan Ellis shortly after I had realized this. (Nevermind that Dan is a EE professor.) I asked him if he still coded himself. He had just finished a project over the summer and was happy with it and the process, but then he described it as "indulgent". why "indulgent"? because, according to Dan, he should be working on writing grants, papers and reports, executing the broad vision of the lab, while the students benefit from the programming experience. (Dan, if you read this, please forgive mistakes by paraphrase, and the fog of memory.)
The responsibility to delegate work to students is one that I haven't quite internalized. I still run a lot of experiments myself. I write a good deal of code still. And when we're under close deadlines, I have a tendency to tell students to walk away, and handle the final push myself. I'm not yet prepared to call this "indulgent", but it I'm ready to acknowledge it as a bad habit.
Internalizing the role of "mentor" is much more difficult than "teacher". Teaching is something that you do a few times a week, but it's a hat you take off. Mentoring, or advising graduate students, is an ongoing process.
I'm the most visible example of what a professor is for my students. How I do this job impacts how they will. (Just as my advisor is my first and best example that I draw from when advising students.)
My behavior as a mentor impacts how they'll behave as students. If I respond to emails at 1am, I will get emails at 1am. If I don't communicate what I expect from them, they won't know.
In addition to my advisor, I've had a number of important mentors. There are two lessons I've taken from those relationships.
Protect your advisees. There are plenty of external challenges -- defenses, negative paper reviews, job postings, evaluations -- that a student will participate in. They do most of the work. I feel like it's my job to make sure they're set up for success. (Only submit papers that you would accept. Don't volunteer them for too many responsibilities.) When things blow up, absorb the blow. Outwardly, take responsibility for mistakes, figure it out with the student internally. If the students feel safe, they'll be enabled to do good work.
Be a happy warrior. There are parts of the job that are difficult. It takes long hours and drive. And you're in this job for a reason. You want to discover, and share those discoveries. You want to contribute to Knowledge. As a student, I fed on the enthusiasm of my mentors. While it's easy and appropriate to feel a kinship with students, I feel a responsibility to set a tone that this is valuable, but also this is fun. And it is.
No comments:
Post a Comment