Skip to main content

Time management for junior faculty

At SEAS this term we've been holding a professional development seminar for graduate students, basically an informal series of lunchtime talks in which faculty talk about issues like doing a job search, giving a talk, academic writing, and so forth. It's a great idea and touches on a lot of issues that I wish had been brought up in a more formal setting when I was a graduate student. Last week, Vinny Manoharan and I gave a presentation on time management, and this got me thinking about effective techniques for managing one's time, many of which I only learned as a new faculty member.

Of course, I continually struggle with managing my time, especially with distractions like e-mail and reading Digg while trying to get "real work" done. But in the last few years I've developed a few tricks that I find pretty helpful in terms of structuring my day.

The first is to protect my "deep thinking" time, namely, the mornings, when I get my best thinking (and writing) done. I generally disallow any meetings on Monday-Thursday before noon. (Fridays end up being my one back-to-back meeting day.) Not only does this give me a long stretch of uninterrupted time to work on papers or proposals, but it leverages the mental clarity and lexical eloquence that I only seem to manage first thing in the morning. During this time, I focus on writing and thinking, and avoid any kind of administrative distractions, preparing for class, or meetings. Those I save for the afternoon when I am generally mentally fried and the context-switch overhead is less detrimental.

The second is to carve out one full day of the week -- Wednesday in my case -- and have no meetings that day. Though I am only successful in this about 30% of the time, having a whole day with no meetings means I can really dig in deep into projects that I have been putting off, such as starting a new paper or -- gasp! -- actually doing some hacking. I really look forward to Wednesdays and they also give me a chance to catch up on things that pile up during the week.

The third big change in my schedule has been to think twice before agreeing to do something, whether it be to join in on a grant proposal with some colleagues, write a book chapter, or give a talk. Individually, these things might be great, but when I find myself with too many balls in the air my life gets really miserable and I end up thrashing just trying to stay afloat. Before I started at Harvard, Margo Seltzer gave me an invaluable piece of advice: learn how to say no. Although it's hard to imagine as a grad student, as faculty everyone wants a piece of you -- whether it be for sitting on university committees, helping to write a grant, serving on a program committee.... the list goes on. I've since learned that saying no is essential to keeping your sanity.

Lately I have been actively cutting back on my list of projects, and generally saying no to new projects (no matter how interesting they might be), unless they directly dovetail with something I'm already working on. I'm also saying no to any PCs at the moment since I'm cochairing Sensys 2009, and expect that to take up a significant chunk of my time from now until July. (Also, I somehow managed to find myself on five separate PCs at once not long ago, and that was a world of hurt.) It is very hard to do, since I don't like letting people down, and I actually really like having lots of varied things to work on. But having less on my plate means I can go more deeply into each project and hopefully keep tabs on everything without getting pulled in too many directions.

Of course, I told myself for a year or so that I wouldn't start blogging because the last thing I needed was another project... well, aren't rules made to be broken?


  1. It’s quite appreciable that such information is being shared through a huge network. Keep it up.

  2. I am quite sure they will learn lots of new stuff here than anybody else!

  3. Hi

    I read this post two times.

    I like it so much, please try to keep posting.

    Let me introduce other material that may be good for our community.

    Source: Time management systems

    Best regards


Post a Comment

Popular posts from this blog

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…