The subtle art of managing a research group

One thing that you rarely learn before starting a faculty job is how much work goes into managing a research group. During my pre-tenure days, this meant squeezing the most productivity out of my students and making sure they were hitting on all cylinders. Now that I have tenure, my role is more like a bodhisattva -- simply to make sure that my students (and postdocs and research staff) are successful in whatever they do. Of course, productivity and success have a high degree of overlap, but they are not exactly the same thing.

There are many subtle things that one needs to know to make sure that a research group is functioning properly. A lot of it has to do with making sure that the personalities mesh well. For a while, I tried to get all of my students to work together on One Big Project. We would have these big group meetings and write design docs but over time it became clear to me that it just wasn't working. It finally dawned on me that a couple of the students in my group (including one who had developed most of the core code that I wanted everyone else to rely on) were not that interested in working with other people -- they were far better off doing their own thing. I've also had students who really work fantastically in a team setting, sometimes to a fault. Those students are really good at doing service work and helping others, when they really should be more selfish and pushing their own agenda first. In general it's good to have a mix of personalities with different strengths in the group. If everyone is gunning to be head honcho, it isn't going to work.

Of course, most junior faculty go into the job with zero management training or skills. One's experience in grad school no doubt has a big influence on their approach to running a research group. My advisor was David Culler, who is known to be extremely hands-off with his students (though he can do this amazing Jedi mind trick -- to get his students to do his bidding -- that I have never quite mastered). I took after David, though I find that I am much happier hacking alongside the students, rather than only discussing things at the whiteboard. I also see lots of junior faculty who live in the lab with their students and have their hands all over their code, so there are many different paths to enlightenment.

All along I wished I had more management experience or training. Early on, I was given a copy of Robert Boice's Advice for New Faculty Members, and frankly found it to be fairly useless. It is unnecessarily cryptic: the very first section is entitled "Rationale for a Nihil Nimus (Moderate) Approach to Teaching" -- I am still not sure what the hell that means, but it certainly wasn't any help for someone starting up a big research lab.

It turns out that MIT Professional Education runs a short course on Leadership Skills for Engineering and Science Faculty. (I signed up for this a few years ago but they canceled the course due to low enrollment! I certainly hope to take it one day.) Another useful resource is the Harvard Business Review Paperback Series, which is a collection of (very short and readable) books on management topics, some of which are germane to science faculty running a lab. For example, the book on motivating people gets into the various ways of getting your "employees" (a.k.a. students) to be productive, and talks all about the pros and cons of the carrot versus the stick. Synopsis: If you can get inside the head of an unmotivated student and figure out what they want, you can motivate them to do anything. This must be the key behind Culler's Jedi mind trick.

First week at Google

I started work at Google this week, and did orientation at the mothership in Mountain View. It was an awesome experience, and I had more fun than I have had in years. I certainly learned a hell of a lot. A bunch of "Nooglers" -- more than 100! -- were starting the same week, including Amin Vahdat, who is taking a sabbatical there as well. I've been asked a lot what I will be working on a Google. I can't provide details, but my job is a software engineer doing networking-related projects out of Google's Boston office. I won't be doing "research"; I'll be building and deploying real systems. I'm very excited.

Clearly, I haven't been there long enough to have any informed opinions on the place, but first impressions are important -- so here goes.

First, it should be no surprise that I'm blown away by the scale of the problems that Google is working on and the resources they bring to bear on those problems. Before last week, the largest number of machines I'd ever used at once was a couple of hundred; on my fourth day at Google I was running jobs on two orders of magnitude more. It is a humbling experience.
Having worked on and thought about "big systems" for so many years, being able to work on a real big system is an amazing experience. Doing an internship at Google should be mandatory for students who want to do research in this area.

The place is very young and energetic. There are few people over 40 wandering the halls. I was also impressed with the fraction of women engineers -- much higher than I was expecting. Everyone that I have met so far is incredibly smart, and the overall culture is focused on getting shit done, with a minimum of bureaucracy.

Orientation was a little chaotic. The very first presentation was how to use the videoconference system -- this did not seem like the right place to start. Of course, there is so much to learn that they have no choice but to throw you in the deep end of the pool and point you at a bunch of resources for getting up to speed on Google's massive infrastructure.

Google is famous for having a "bottom up" approach to engineering. Development is driven by short projects, typically with a few engineers with a timeframe of 3-12 months. Rather than a manager or VP handing down requirements, anyone can start a new project and seed it in their 20% time. If the project gains momentum it can be officially allocated engineering resources and generally the tech lead needs to recruit other engineers to work on it. (GMail started this way.) Inevitably, there is some degree of overlap and competition between projects, but this seems like a good thing since is rewards execution and follow-through.

Figuring out what the heck is going on can be pretty challenging. Fortunately Google has an internal search engine of every project, every document, every line of code within the company which helps tremendously. Internally, the corporate culture is very open and with few exceptions, every engineer has access to everything going on within the company.

I hope that I will be able to continue blogging about my Google experience -- their blog policy is pretty reasonable, though I won't be able to share technical details. But from now on I need to include the following disclaimer:

This is my personal blog. The views expressed here are mine alone and not those of my employer.

Cocktails for Computer Scientists

One of the keys to success in academia is being able to make a good cocktail. Many a night I have slogged through a grant proposal or stack of recommendation letters for students with a Sazerac or Martinez in hand. One might think that regular imbibement of cocktails and the demands of faculty life are not exactly compatible, though I disagree. Moderation is important, of course; but not nearly as important as the requirement to stop working once you've finished off your third drink. It is a nice timeout mechanism.

Most of my friends know little about cocktails, or their idea of a cocktail is a boring old vodka martini or a margarita. (On the other hand, Michael Mitzenmacher is a fan of the Long Island Iced Tea, which essentially involves dumping whatever booze you have laying around into a glass.) Any time we have friends over I am in instant bartender mode and pushing new drink discoveries on them. So, I give to you, Matt's Guide to Classic Cocktails for Computer Scientists, or how to become a cocktail geek in four easy steps.

Step One: Use good ingredients. High-quality ingredients make all the difference in cocktail making, just as in cooking and any other endeavor. It was an absolute revelation the first time I tasted a proper añejo tequila -- sweet, smooth, not at all like that harsh stuff that you use to do shots. Those bottles of Jack Daniels and Bacardi you have left over from your college days? Chuck 'em. Stock up on a good, proper bar. At minimum, you'll need a nice bourbon or rye (Black Maple Hill or Hudson Valley); gin (Junipero or Plymouth); rum (Zaya or Ron Zacapa 23 Años); and sweet vermouth (Carpano Antica or Dolin). Vodka is totally unnecessary and best left for "fauxtinis". Other important ingredients for making real old-school cocktails include absinthe, maraschino liqueur, brandy, and the occasional exotic boondoggle like Batavia Arrack or Creme de Violette. If you are just getting started I recommend holding off on these extras until you need them.

Bitters are one of the most important components to a bar. My favorite, by far, are The Bitter Truth Jerry Thomas' Own Decanter Bitters. You should always have a bottle of Angostura on hand, and Peychaud's as well. Orange bitters are used in many classic drinks. Bitterman's Xocolatl Mole Bitters make a great conversation piece. I have six or seven kinds of bitters at my bar and my theory is you can never have too many.

Make yourself a batch of simple syrup: two parts sugar to one part water, boil in the microwave, put into a glass bottle in the fridge. You'll use it all the time. Spike it with a stick of cinnamon or a handful of whole black peppercorns and you can produce a masterpiece. Fresh lemons and limes should always be on hand. I tend to eschew olives and those gross nuclear-fallout colored "maraschino cherries."

Step Two: Get a decent cocktail book. Most of these are utter garbage. The worst are those that simply list a zillion cocktails in alphabetical order by name and don't tell you anything about the ingredients, history, or variations on the drink. The best classic cocktail book is Imbibe! by David Wondrich, which is a modern interpretation of Jerry Thomas' original cocktail guide from 1862 . (Reprints of the latter can now be found on Amazon!) Wondrich's writing is superb; the book is heavy on lore. If you want to make cocktails the proper, 19th century way, this is a good place to start. Online, CocktailDB is fairly comprehensive and makes it easy to search for recipes, but I find this approach overwhelming. Better are cocktail blogs such as Cocktail Virgin and spiritsandcocktails.com (among many others), which are more focused.

Step Three: Make some drinks. Now that you have your ingredients and your handy guidebook, what to make? I recommend starting with the very basics and go for an Old Fashioned: muddle bitters with a sugar cube and a little bit of water; add a couple of ounces pour of good bourbon or rye; stir with ice. That's it. This is not the Old Fashioned you will get at a typical bar (which loads the drink with a fruit salad).

Variations: Improved Rye (or Bourbon) cocktail: same as above, but add a dash of absinthe and maraschino liqueur, stir with ice and strain. A Manhattan made with proper bourbon and Camparo Antica vermouth is to die for. Substitute Fernet-Branca for the vermouth (and add a dash of simple syrup) and you have a Toronto Cocktail, probably my favorite drink these days. Flame an orange or lemon peel over the drink and you are gettin' really fancy.

A good gin martini -- with dry vermouth and orange bitters -- is an excellent thing. Use sweet vermouth instead (again, Camparo Antica) and sub Old Tom Gin instead of dry gin and you get a Martinez, the precursor to the martini, very 1880's. That one needs a lemon peel rubbed on the rim of the glass for full effect.

If you want to show off, make a Trinidad Sour -- a full ounce (!!) of Angostura bitters, orgeat (or sub simple syrup), lemon juice, a bit of rye. I guarantee you're not going to find that at Applebee's. This is for advanced cocktail drinkers only.

Step Four: Research. You can never go wrong by leaving it to the pros. In Boston, the best places for classic and modern craft cocktail making are Drink, Eastern Standard Kitchen, Green Street Grill, Craigie on Main, and Deep Ellum. Don't just order a drink that you already know -- talk to the bartender, get to know them, learn about the craft, get their recommendation. Drink encourages this by not having a cocktail menu; they expect customers to discuss what they like and don't like with the bartender. Usually when I go there I just tell them to make me something good, and they do.

Off to make up another Jamaican Ginger Cocktail #3...

Working for The Google

I am about to take a one-year sabbatical from Harvard to join Google. If you haven't heard of them, Google is this little startup company with this really neat website that lets you search for just about anything on the Internet. It is very cool.

I'm going to be at the Google office here in Cambridge (since I can't move my family right now) but expect to work with folks at the Seattle and Mountain View offices. This way I can also keep tabs on my research group at Harvard and hopefully keep things moving along here. But largely I am going to be stepping back from my academic responsibilities -- I intend to fully dive into the Google job and immerse myself in that environment.

A lot of people have asked me what I'll be doing at Google. I can't say much, but I will hint that it has to do with using high-energy lasers to digitize real objects into a computer system called the MCP. I am sure nothing can possibly go wrong with this project.

Seriously, I only have a vague idea of what I will be working on, but the high order bit is that my job title is simply "software engineer." Essentially, I'll be writing code. Not leading a project or doing "research" or anything like that. To be honest, this makes me extremely happy -- I miss hacking on a daily basis and look forward to being a grunt in the trenches, so to speak. As far as I can tell, this is how most people come into Google, regardless of their level of experience. Craig Chambers, who left a tenured position at University of Washington to join Google, told me that he came in as a software engineer, hacking on someone else's project, and it wasn't until he had been at it for a while that he started defining his own projects and leading his own teams.

The way I think of it, being in academia is a lot like building toy boats and playing with them in your bathtub.

From http://www.flickr.com/photos/timothymorgan/522553650/

Of course, this has many advantages -- you get to completely define the experimental environment, don't need to worry about aspects of the boat design that don't interest you, and can explore radically new designs without much concern for legacy approaches or "making money." At the same time it can get pretty disconnected from reality, depending on how you approach it.

Whereas being at Google is like working on an aircraft carrier at sea.

From http://www.naval-technology.com/projects/cvn-21/cvn-211.html

In my case, my job will be to polish the portholes on the poop deck, and I won't have much influence on the overall design or direction of the ship -- but hey, I'll learn a lot in the process. There is also something very attractive about writing code that will actually be part of a running system and potentially used by millions of people every day. Of course, I'll have to get used to things like writing tests and doing code reviews, and working under a vast number of constraints that we tend to ignore in academic settings.

Keep in mind I've never really worked as a software engineer. In a lot of ways I feel totally unqualified to teach my students about writing good code or building reliable systems since I've never actually had to do it myself. (That's not quite true -- the research systems I build are subjected to rigorous stress testing, but certainly aren't mission-critical the way Google's code has to be.) A stint at Google will hopefully make me a better programmer, system designer, and researcher.

I'm not yet sure whether Google is going to let me continue blogging while I'm there -- hopefully they will let me blog about non-Google-related topics, but we'll see. Maybe I just need a pseudonym -- if you see a blog pop up called "Final and Centralized" you'll know it's me...

Editor in Chief

In a bout of temporary insanity, I've agreed to serve as Editor-in-Chief of ACM Transactions on Sensor Networks, which is probably the top journal in the field. Feng Zhao, the Assistant Managing Director of Microsoft Research Asia, has been the EIC since the journal's inception some six (?) years ago, and has done a fantastic job building up the journal and putting together a fantastic editorial board. I've been on the editorial board for a while and overall the quality of the submissions is pretty high. It's an honor to be selected for this role and I hope to keep up the great work that Feng has started.

Systems people tend to eschew journals in favor of conference publications, but I still think that TOSN has an important role to play in the sensor nets community. We need a place to publish longer, more thorough papers than what you can typically cram into a 14-page conference submission. We need a place for papers of high quality that just won't make it into a decent conference -- retrospectives, position papers, surveys, and so forth.

Of course, a major problem with journal submissions (and TOSN in particular) is the very long review cycle. It's just not acceptable for papers to take a year (or more!) to get reviews back. Having served as an associate editor I know how hard it is to corral reviews from good people and get things done in a timely fashion. Of course, some AE's are better at cracking the whip than others. We also need more regular turnover of the editorial board membership to avoid burnout.

Coming into the job, I have three main ideas for how to improve TOSN's standing in the community. Of course I'm open to any and all suggestions beyond these:


1. Improving the connection between TOSN and sensor network conferences. I think it's important that we formalize a process whereby the best papers from SenSys, IPSN, and other venues are fast-tracked to TOSN. We should be more proactive about this and give authors a chance to use TOSN as a venue for publishing a "journalized" version of a good conference paper. This has been done informally for a while but I plan to make the process much more overt.

2. Encouraging submissions of survey papers, article versions of PhD dissertations, and retrospectives. We need more outreach to the community to make it clear that we want these kinds of submissions. Again, this is mainly about being more proactive about soliciting these papers and getting the word out.

3. Introducing special issues. Feng made the decision to avoid special issues in the early life of the journal, for the good reason that it was important to establish TOSN before branching out to specialized topics. Now that TOSN is well established, I think the time is right to have 1 or 2 special issues a year, especially on topics that may be difficult to publish in a conventional manner. One example would be a special issue on industry experiences with sensor networks. If you have suggestions for special issues (or better yet, would like to serve as editor for one!) please let me know.

Margo Seltzer is blogging

My colleague Prof. Margo Seltzer has started blogging at http://mis-misinformation.blogspot.com/. She is joining the ranks of such distinguished Harvard Computer Science faculty who maintain blogs, including Michael Mitzenmacher, Harry Lewis, and Stuart Shieber. (Apparently, we have nothing better to do than stuff the interwebs with our crazed ramblings.)

Margo, welcome to the blogosphere. It's a lot like real life, only weirder.

How to get tenure at Harvard

There is an old joke that says that at most universities, you have to write a book to get tenure, while at Harvard, they have to write a book about you. I am not sure who wrote that one, since I recently found out that I've been promoted to full professor with tenure. (Unlike most places, at Harvard, full professor is the only tenured rank. I've actually been an associate professor for three years now and the total clock is seven years.) So my time as a disgruntled junior faculty member is drawing to a close - on to the far more entertaining life as a (presumably) gruntled senior faculty member.

Harvard has a notorious reputation for not tenuring its own junior faculty. Indeed, some departments have not promoted from within for decades -- so long that they probably don't remember how to do it if they wanted to. In the math department, for example, junior faculty treat the job like an extended postdoc, with the goal of getting tenure somewhere else -- Yale or Columbia perhaps. You'd have to win the Fields Medal to get tenure in math at Harvard. Such departments treat the end of a junior faculty member's contract as an opportunity to scout out the best person in the world to fill the position, and typically the best person is 20 years more senior and at another school.

This is the classic Harvard model, but in recent years Harvard has started to use the term "tenure track" for the first time in its history. Since I joined Harvard in 2003, we have tenured six CS faculty from within, and turned down tenure to two people. The CS faculty here (and, more generally, the entire School of Engineering and Applied Sciences) are extremely supportive of junior faculty and we work hard to ensure that everyone has the best shot at tenure.

Unfortunately, this attitude is not pervasive, and often rubs against the antiquated culture found elsewhere in the university. For example, it was only recently that Harvard's request for tenure letters explicitly stated that candidate X from Harvard was actually under consideration for the job. The letters still request explicit comparisons against a set list of other faculty who are typically expected to be *full professors* at other schools, and respondents are asked to rank the candidates. To be promoted you need to be ranked first or second consistently across the letters. It is a very daunting process for a junior faculty member.

At many universities, tenure decisions are made at the department or school level, with the university essentially rubber-stamping those decisions. Not so here. The final step of the Harvard tenure process is the mysterious and fearsome ad hoc committee meeting, which is presided over by the President of the university, who has the final say. For this meeting, three senior faculty from other universities come and grill the internal "witnesses" that may support or oppose the case. I am pretty sure the meeting also involves a ritual with a human skull and a goblet of blood, but cannot confirm as of yet.

Now that I've passed the trial by fire, there is one last step. Harvard does not tenure anyone without a Harvard degree, and I've never been here as a student. So next fall, they will grant me an honorary Master's degree to clear that burden. I am not making this up.

From then on I hear it is just smooth sailing, lazy days with few responsibilities and just raking in the paychecks and use of the private parking space. Right? Right?

I'd like to thank all of the people who really made this happen. More than anything else, my tenure is a reflection on the hard work and vision of my amazing students and postdocs -- who took my wild-eyed whiteboard ramblings and turned them into reality. More often than not, though, the best ideas came from the students themselves. I have learned so much from them and have been extremely fortunate to have such an amazing group. I'd especially like to thank Margo Seltzer and Greg Morrisett for their tremendous effort in marshaling my case through the process. Thanks to Michael Mitzenmacher for the puff piece on his blog today. Finally, great thanks to all of my faculty colleagues for their encouragement and willingness to put up with my crap in our weekly lunch meetings.

(Once I've had a chance to digest it, I'll post a more personalized account of what it took to navigate Harvard's tenure process.)