How to manage a research team
Management may seem an alien — even odious — concept to many researchers, who enjoy neither being managed nor managing others. Researchers hold freedom and autonomy sacrosanct, and many idolize the icon of lonely geniuses. After all, Nobel Prizes are awarded to individuals, which impresses upon the lay public that scientific research is a solitary endeavor. In reality, however, research has become a team enterprise, and the majority of high impact research today is done by teams of increasing sizes. The average number of authors on physics papers increased from about 2.3 in 1900 to about 7.8 in 2000 (Fanelli and Larivière 2016); the paper announcing the first observation of gravitational waves listed 1015 authors. Sooner or later, a researcher — be they a starting faculty member or a newly minted group leader — will assume the inevitable responsibility of managing a research team. Scientists, however, are not necessarily scientific when it comes to management. Management skills, despite the myth, do not “come naturally to some”. Fortunately, such skills are not hard to learn, for anyone who cares to learn them. Here I will share what I learned from my experiences with all the willing ears.
Let me preface the following with the obvious: It is of paramount importance that you have your team work on important, interesting problems (heed Richard Hamming’s advice), otherwise no practice of management can lift your research out of mediocrity. The right objective is the core around which to organize your team’s energies. Good management increases the chance and shortens the time to achieve that objective.
First, I will recommend a careful reading of Andrew Grove’s High Output Management. It influenced me no less than The Feynmann Lectures on Physics, and its teachings are apparent in many of the ensuing paragraphs.
This is intended as a concise and practical guide to managing a research team. It suggests common sense management practices for researchers who are at different stages of management. Many are doing some, some are doing many, but few are doing all. I hope that in the following there is something useful for all. As a quick note: I will be using “they” and “their” as pronouns even for singular subjects, which I hope will not offend the sticklers of the English grammar.
I will discuss below three key concepts in management: Output, Leverage, and Performance.
Output is the sum of all production from your team. What, then, is the output of research? I propose that there are three primary types of output from research: 1) Hypothesis, 2) Evidence to support or refute the Hypothesis, and 3) Tool to generate the Evidence and, sometimes, the Hypothesis. A researcher may produce one, two, or all of these types of outputs, and they should be evaluated for the sum of all the outputs.
A drug discovery team developing an inhibitor of a protein target may consist of a computational chemist, a medicinal chemist, a biochemist, and a molecular biologist. The computational and the medicinal chemists conceive and design new molecules as candidate inhibitors (Hypothesis); the computational chemist uses customized computer simulations (Tool) to predict their inhibitory activities (Evidence) and to select more promising candidates (Hypothesis); the medicinal chemist synthesizes the selected molecules (Tool); the biochemist and the molecular biologist test the molecules in their bespoke in vitro and cellular assays (Tool) to obtain their inhibitory activities (Evidence) and rank the candidates accordingly. Here the computational and medicinal chemists produce Hypothesis, Tools, and Evidence, whereas the biochemist and the molecular biologist produce Tools and Evidence.
A manager needs to be mindful of all three types of output from the research team. There is an inherent bias for the managers to value more the type of output that they used to produce themselves: tool developers like tools, hypothesizers like ideas, and evidence seekers like data. Thus the transition from an individual researcher to a manager requires the shedding the personal, often subconscious, bias, so that the manager can evaluate different types of output fairly.
A good way to evaluate the different outputs is to assess their replacement cost: if a particular piece of output is unavailable or diminished, what do you need to do so as to achieve the same research outcome? In the above example of the drug discovery team, you may assess the value of the computational output by asking how many more molecules you will have to synthesize in order to identify the same number of viable development molecules, or the value of the biochemist’s output by asking whether you need a different assay if the biochemistry assay is omitted. If you want to evaluate different authors’ contributions to a research manuscript, ask what you would have to do to get the manuscript ready if one author’s output is missing. Bear in mind that even the central hypothesis can be replaced: the same team could have been redirected to test another equally, or more, important hypothesis; “Gravity is equivalent to acceleration” is a much more profound hypothesis than “If we screen 10 million molecules we are more likely to find an inhibitor for protein X than if we screen 1 million molecules”. Be honest and rigorous.
Once a manager identifies the three types of output of a research team, not only can they monitor the productivity of the team, they can also apply leverage to increase the productivity of the team.
Leverage is the amplification of the output generated by any managerial activity. The managerial activities with the greatest leverages are planning, meetings, and performance feedback.
Planning
Research is inherently fraught with uncertainties and surprises. But that is no excuse for a sloppy research plan. Although “no plan survives contact with the enemy”, a general would be foolish to go into battle without one. A research plan serves three main purposes: 1) to keep the team focused on the goal, 2) to allocate resources accordingly, and 3) to track the research progress and make necessary adjustments.
You start by writing down the specific aims you want to achieve at the end of the planned research. (Anyone who has written a grant proposal will be familiar with such aims, which essentially state the expected outcomes of the research.) A good specific aim should be, well, specific, such as “1) develop a small molecule inhibitor against kinase X and 2) test whether it can suppress tumor growth in the mouse model Y”. “Find a cure for cancer” really is not an aim. I suspect that most researchers worth their salt do write down the specific aims, but fewer — perhaps out of the excitement from the potentially transformative research ahead — bother to write down the concrete plan of execution.
Once the specific aims are set, work backward. For each of the specific aim, list the results that are needed to achieve that aim. Remember to include hypotheses to be tested, evidence required, and tools needed. Then for each of these intermediate results, list the results needed to achieve that. Continue until you have arrived at a list of tasks that you can perform immediately, now.
With this list, work forward again. Assign the suitable researcher in your team to each task and estimate how much time the task will take. Note any task that you do not have anyone in your team to work on; you should plan on hiring the additional person or approaching the right collaborator for that task, at this very moment of planning, even though the actual hiring or collaboration may wait until later. With the estimated times, you can make a Gantt chart of the project, which should reflect the execution order of the tasks, parallelizable items, and the end time of the project.
It typically takes about two hours to draft a 3-year research plan. These may be some of the most valuable two hours in your next 3 years. Your plan will be very detailed for the next 3 to 6 months, and the later parts will be in broad strokes, reflecting uncertainty of the future. Review the plan and see what items are most likely to fail, and what results will doom or provide proof-of-concept for the project. These will be the priorities.
Now you need to communicate the plan to your team. There is no better way of communication than meetings.
Meetings
Meetings have a bad reputation because too many meetings are bad. A meeting is bad when some of the attendants come to the meeting not knowing what the meeting is about. Every good meeting has its own clear function. There are three primary functions of meetings in research groups: exchange information, make decisions, and solve technical problems. Key to running successful meetings is to stay focused on the meetings’ purpose and prevent anyone from hijacking a meeting off course.
The meetings can be categorized by their attendance: whole-group meetings, project meetings, and select-attendance meetings. They serve very different purposes.
Whole-group meetings are regular meetings — no oftener than once a month — to update group members on the state of all research in the group. These meetings are purely informational. They inform all members of the goings-on in the group: projects and their progress, new hires and departures, change in funding, etc.. Answer questions from the group but schedule a separate select-attendance meeting for any emerging debate.
Group seminars are a special type of whole-group meeting. It is worth noting that these are not the right places for extended technical debates or problem solving. Exchange of ideas is fine. But once a small fraction of the audience — often two people — engage in an extended technical debate, stop the debate and suggest a separate meeting among the debaters (and follow up with them to make sure that the debated issue is resolved). Too often open public debates are show-offs of the debaters. They serve not to solve problems but supply fodder to the gossip mill.
Project meetings are regularly meetings — often weekly — to track the progress of specific projects and to prioritize different tasks. Allow time for every member of the project team to report their work since last meeting, inquire whether they have what they need for the next step, and based on the input, decide what the top-priority tasks are for the time until the next project meeting. Again, these meetings are not for extended technical debate.
Select-attendance meetings are meetings where a few people get together to resolve issues that are of interest only to them. There may be a series of regular meetings with varying attendances if the issue cannot be resolved in one meeting. These are typically offshoots of other meetings where the issues at hand arise. These are the meetings where extended — and technical — debates are appropriate. It is important to report the outcome of these meetings back to the broader audience who are aware of the issue. For example, if the issue emerges in a weekly project meeting, report its resolution in the next project meeting, or send a written summary to its attendants. Make sure you give a shout-out to the folks who solve the problem. You will be demonstrating the mechanism of issue resolution at work.
As a special type of select-attendance meetings, you should have regular one-on-one meetings with your direct reports weekly or every other week. These meetings are opportunities to mentor the researchers, to follow their personal progress and give performance feedbacks (more on this later), to hear the difficulties they are facing in work and — sometimes— in life, and to help them solve challenging problems.
One-on-one meetings are also the time to make individualized, short-term research plans and enforce their execution. Have the researcher prepare a short summary — 3 to 4 slides, for example — and share it with you prior to the meeting, so that both of you come to the meeting prepared. The summary should contain their key output since the last meeting as well their planned output to be delivered by the next meeting. This way, progress can be clearly tracked.
Here are some practical tips that help make meetings more effective:
1. Book all your meetings on the Outlook or Google Calendar.
2. Prepare a shared document (Dropbox, Microsoft OneDrive, Google Docs) for meeting agenda and notes. Use one same document for a series of regular meetings and add the latest meeting contents at the top of the document with the meeting dates as section headings.
3. Include a link to the above document in the meeting calendar invite. Do not include the document itself because you will be editing the document subsequently — such as adding meeting notes during the meeting — and you want all the attendants to be able to edit and view the same synchronized document.
4. Create a shared repository — a shared folder or a page on a web-based project management tool (e.g. Confluence), etc. — for the meeting attendants to deposit any meeting material, such as presentations and data, prior to the meeting.
5. Start each meeting by reviewing the action items from previous meetings.
6. End each meeting by reviewing the follow-up items, if any, for every attendant.
There will always be spontaneous discussions outside the scheduled meetings. But meetings are the most effective means of communication within your group. Avoid the dubious practice of “managing by walking around”. An unexpected “Hey, how is it going?” leads to not productive interaction but disruptive interruption.
Strive to save one no-meeting day per week for everyone in the group, including yourself. On this day, you are having a meeting with only yourself. Block it out on your calendar.
Planning and meetings are organizational activities that make the output of the team greater than the sum of the independent output from the individual researchers. As important is to improve the individual output. This is primarily achieved by performance feedback, a managerial activity that deserves its own section of discussion.
Performance is the measure of the total output from an individual researcher and their subordinate team. The purpose of the performance feedback is to improve the performance, which, in research, translates to bolder hypothesis, stronger evidence, and superior tools.
Autonomy is indispensable to a researcher’s creativity and productivity. Deviation from the plan is common, as new evidence may alter the priorities of different research items. Researchers should be encouraged to make their own adjustments in the execution of the research plan. Performance feedback must avoid curtailing such autonomy: a researcher’s output is not simply the number of completed tasks.
Instead, performance feedback in research should be primarily quality control. Specifically, the feedback should focus on the quality of the hypothesis, not the direction of the hypothesis, on the strength of the evidence, not the composition of the evidence, and on the applicability of the tools, not the parts of the tools. A manager should be particularly mindful when there is a clash of opinions with their team members, and they should not confuse the disagreement with unsatisfactory performance.
Quality control is substantially harder than task assignment. The former requires a genuine taste for good research and the mental capacity to follow someone else’s ideas; the latter only requires knowing one’s own stuff. Laziness and incompetence beget micromanagement.
Effective performance feedback should elevate your researchers’ quality of thinking. The manager should make it clear that a researcher is expected to always check their own work by asking themselves the following (incomprehensive) list of questions:
· Hypothesis: are the alternative hypotheses considered? Is the hypothesis generalizable? What are the ramifications of the hypothesis?
· Evidence: How much does the evidence affect the probability that the hypothesis is true? Does the evidence disprove the alternative hypothesis? Are the data presented in an easy to understand format? Are the standard errors and statistical analysis included? Are the labels descriptive, the fonts legible, and the colors easy to follow in the plots? (yes, these are the things that you should micromanage!)
· Tools: How are the tools validated and benchmarked? For instance, if the tool is a piece of computer code, ask what kind of unit tests are used, and whether the code has been validated by examples where the output of the code can be derived independently.
The reports delivered to you — such as the research summary for the regular one-on-one meetings — are a good mirror of your researchers’ quality of thinking. Two key aspects to watch are
1. the quality of information: Do they reduce the uncertainty in the research (e.g., by eliminating some of the competing hypotheses, by clearly ranking several experimental alternatives, etc.)? Do they affect the decision making (e.g., what experiments to run next, what data to collect next, what tools to choose, etc.)?
2. the quality of proposals: Are their proposed next steps the best choices given their current results (e.g., are they making necessary adjustments to their research plan when a hypothesis is disproven, or are they still beating a dead horse)?
Cultivate in your research group the skill to translate factual information into operational difference. For instance, they should not tell you that instrument A costs $1000 more than instrument B but it is of much higher quality; make them tell you how instrument A will enable your group to do things that instrument B will not.
A measure of quality in the thinking of your researchers is how difficult it is to decide between their proposals: the better they think themselves, the more difficult it will be for you to make a decision, when there is no obvious missing information. This seeming paradox is not. If your researchers have already analyzed their proposals thoroughly, they will have eliminated the obviously bad options, and the remainders presented to you will be difficult to choose among. Similarly, a clear sign of development in your researchers is that they are presenting you with increasingly difficult problems to solve.
One common mistake in performance feedback is to confuse input and output. Remember that performance is all about output; someone who works all the time but produces little is an underperformer, and they deserve a candid feedback on how to improve their productivity. Also remember that negative results are output too: strong evidence to refute a bold hypothesis is much better than weak evidence to support a meek hypothesis.
Rewarding good performance is an important component of performance feedback. The sooner the reward comes after good performance, the more effective is the reward. Rewards may come in many different forms. Some examples, in the order of decreasing applicable frequency, are:
1. A public shout-out (Slack/email/whiteboard) for a job well-done
2. Wine and dine
3. Send the top performers to a conference to present their work
4. More autonomy in problem choices
5. Retreat for the team when major milestones are delivered
6. Performance-based bonus
7. Pay increase
8. Promotion (I intend to write a special piece about this in the future)
The goal of good management in a research group is to create an environment where each individual researcher can thrive. Great managers are made, not born. Hard lessons are inevitable; knowing the basics may help prevent disaster. Happy research!
