Wednesday, May 21, 2014

Things I didn't know before becoming a professor: #3 How to run a research group

At this point, I've figured out my classes and secured a little bit of funding.  Now it's time to staff up the group and get to the work of research.

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.

How to be a mentor

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.


Monday, May 05, 2014

Things I didn't know before becoming a professor: #2 How to Write a Grant

To get tenure in computer science, you have to secure external funding.

I don't know how important this is in other disciplines.  I'm sure there are administrations that will say that external funding is only one of a number of criteria that determine tenure decisions.  I'm sure they're right.   But without funding, you're at a severe disadvantage. You can't work with grad students (as easily -- some programs provide student funding through other means).  Travel to conferences -- where you present your work and solidify relationships with important people in the field (who may end up writing letters in support of your promotion) -- is expensive.  And then there's the brass tacks.  Depending on institution and some uninteresting details, the administration receives somewhere in the ballpark of 1/3 to 1/2 of the funds that you secure.  

Before becoming a professor, I hadn't written a grant proposal. I had read a couple of successful proposals that I had worked under as a student, but I hadn't been a part of the preparation of any.

A little bit of context before I share what little I've learned about writing grants.
I've been pretty successful in securing funding over the last five years.
I don't expect this trend to continue forever.
I recently received an NSF CAREER award.
But my previous two proposals were not funded.
I'm hardly an expert, but I've gotten better since starting.

Here are a few things I didn't know

How many funding opportunities there are? 
I knew about NSF and NIH. I knew about DARPA because I worked on a grant as a student.  I didn't know how many programs NSF has (there's no way I know about all of them).  I didn't know about the other DoD agencies that fund basic research.  I still don't know about all of the foundations and industrial grants and awards that are available.   I'm sure I'm still missing some, but each of IBM, Google, Microsoft offer programs to support faculty.  On top of that, there are institutional awards -- CUNY has a handful of them, and if we do, I'm sure everyone else does.  This doesn't mean that it's easy to find funding.  But by keeping an open eye, asking around, and being lucky enough to be asked to join grant writing efforts, I've been surprised by how many opportunities are available (in this field).

How to tell the difference between a good proposal and a not-good-enough proposal
Friends and colleagues will offer to share successful grants with you.  Take them up on it.  But learning from only positive examples is challenging.  It can be challenging to figure out how to translate structure and presentation cues from one grant to another.  Also, it's not always clear what made these examples impress the reviewers.   If you're so bold, ask these people to share the reviews along with the grant.  I haven't tried this, and I'd have to trust a person quite a bit to share my highlighted flaws with them, but give it a shot.

Still better is getting to look at unsuccessful proposals and their associated reviews.  Everyone you know has one or two of these kicking around.  Funding rates are pretty low, say 20% or so, so most people will have a stack of failures for each success they have.  But again, it takes moxie to ask someone for this, and a lot of trust to offer it.  (I don't know if this happens ever, but I'd love to hear if other junior faculty were able to read unfunded proposals as they started writing themselves.)

The best way to see a lot of examples of grants, both positive and negative, and their reviews is to get on a grant reviewing panel.  NSF Program Managers like to include junior faculty in their panels.  Call one who funds work like yours, and have a conversation.  I was invited to one in Spring 2010.  It was an opportunity to closely read about 5-6 proposals, and more casually review another 12 or so.  Seeing all the ways a basically good idea could not get funded was eye-opening.  Generally, the quality is high, so the differentiation between successful and unsuccessful proposals can be the depth of their weaknesses rather than the height of their strengths.

That writing a grant is writing science fiction
It's believable, near-future science fiction, but still in the genre.   You're describing something that doesn't exist, but will in the next few years.

This perspective has made the process of grant a lot more entertaining.

Science writing has a narrative arc.  The introduction and motivation of your work should be exciting.  The feeling I want to leave a reader with is somewhere between, "Of course that's what will happen", and "Wouldn't it be cool if that's what the world was like."  Balancing these two extremes is the difference between the Scylla and Charybdis of incrementality ("boring") and overreaching ("i don't believe you can do this").

How to keep it together after getting a grant rejected
It's only natural to be offended, embarrassed, insulted, frustrated, and sad when a proposal that you spent months of your life on is not funded.   The panel was clearly full of idiots who didn't understand your genius.  There was some mistake, if only they had read more closely they would understand how important this work is.

Here's what rejection has taught me:

Take a deep breath.

Most proposals aren't funded.

The folks who review your grants are almost universally qualified to do so.

If a proposal is funded, you are not a genius.  If a proposal is not funded, you are not an idiot.

The sooner you get over it, the better. Remember, it's the work that's being reviewed, those crammed 15 pages of science fiction, not your identity.

And there's a silver lining: almost always they will include a stack of written reviews. These reviews are a gold mine.  Treat them as a genuinely helpful consolation prize.  If you don't understand what they're saying, you can probably talk to a program manager about them.

When revising a proposal, I take all of the reviews, and cut out everything positive that they had to say.  It's too easy to be comforted by that.  What I really need to know is what didn't work.  That's what needs work.

How to find writing advice
I still don't have a lot of confidence in my grant writing.  But there are a lot of people who do, who will share their advice with you.  Almost all institutions have grant writing workshops.  NSF hosts workshops.  There are posts like this, and this, and this, written by people who are truly qualified about the process to really steer you right.  Writing with a group of people helps.  Collaborative proposals come with their own logistical challenges, but it can be helpful for getting feedback on the writing.

Some graduate students write applications for fellowships, internships and other sources of funding.  This is great practice, but this is different from the grant process.  Maybe the best way for students to get exposure and experience at grant writing is through their advisor's proposals.  I think some professors work with their students on their proposals.  If the student is a strong enough writer, and far along in their dissertation, I could see this making a lot of sense for both the professor and student.