Several days ago, David asked how to evaluate an adviser and later Lance replied with his post of wisdoms.
David pointed out that he knew of relatively few resources on how to be an adviser. (His post has one link on this.) While I am not ready to write a post of experience like Lance did, I do have a thought to share.
Not long ago, CMU CS alum Scott Berkun gave a talk based on his book on project management. In his talk, Scott told us many interesting stories about his project management experience back in Microsoft. What struck me was his lists of items of “do”s and “don’t”s in management and his list of questions to ask the team members as a project progresses into different stages.
While Scott was focusing on software projects, I believe some of his ideas are applicable to academic advising. For example, he suggests that we should explicitly ask our team members (students) “Do you think you have all the resources you need for you to succeed?” and “Do you feel that this meeting is a waste of your time?” (Whether you get an honest answer back is another matter. And if you don’t expect you can get an honest answer, then you already have a complicated issue to tackle.)
In hindsight, I suppose it’s hardly surprising that academic advisers can draw experiences from software project managers. They are both managing smart people in a creative process. While the two fields have many differences, the human factor can be pretty much the same.
P.S. Scott’s background is in software project management and the book is not directly written for academic advisers. It takes some effort to relate his ideas with advising. So don’t rush out to buy the book and then tell me that you can’t find a short list on how to be an adviser. There isn’t.
4:40 on February 13th, 2006
Thanks for posting these links. I’ll have to take a look at the book. I’m curious, though, to know if you have found any major points of divergence between advice for grad school and advice for software projects. For example, in my limited experience with software engineering, a lot of the projects and concerns are driven by external factors (e.g. what does the client need). Doing research and picking a research direction seems to have less of that pressure, although it’s certainly present.
18:00 on February 13th, 2006
I note that the advices inside this book can be of different effectiveness to different areas of Computer Science. In particular, it’s more for Systems and less for Theory.
In Theory, as you know, it’s common to try quite a few problems without making significant progress and move on. It’s part of research. But you cannot hope to do that in Systems. In this regard, that suggests failure management methods in this book cannot be blindly applied to Theory projects.
The size of a team is also an important factor. Rarely do we have teams of over 5 people in Theory research. So perhaps we have an easier time to deal with the people dynamics than in software development.
18:07 on March 23rd, 2006
i think you’re too quick to conclude that trying several ideas and moving on won’t work for systems research. the difference might just be that you have to make the decision to drop a project more quickly. (because you’ll need a lot of time to finish the project that does look viable.)