If you find that members of your staff aren't taking initiative and meeting their responsibilities, maybe it's time to take a look at your management style.
Ashok, who ran a university research lab, met his old friend Sara at a recent scientific conference. Because Ashok knew that Sara had successfully run a very productive lab for many years, he complained to her about the performance of his laboratory staff. No one in his lab, Ashok said, took any initiative. "I have to do everything for my group. I have to come up with all the ideas. No one ever does any creative thinking but me."
The next day, after a session at which a mutual friend gave a talk, Ashok told Sara that he had a great idea for some experiments for two of his postdocs, who were also at the meeting. Because the postdocs weren't in the lab, Ashok had already called his senior technician and told him to get started on the experiments right away. Sara asked Ashok whether he had discussed the experiments with his postdocs. He hadn't, he said, because it was too important: he wanted to get those experiments started right away. He would fill the postdocs in later, he said, when they all returned from the meeting.
In addition to starting his technician off in a new direction, Ashok had also set up a lunch meeting with the speaker to see if they could forge a collaboration. Had he invited his postdocs to lunch, Sara wondered? He hadn't, of course, for reasons he thought were sound. "I know how to get this guy to work with me, and it would be better if I met with him by myself."
That evening, over a beer with Sara, Ashok seemed exhausted. He complained about all his responsibilities, which ranged from revamping his department's graduate curriculum to reviewing data several times a week from everyone in his lab. He resented some of his colleagues, who seemed to have much more time than he did. He couldn't figure it out.
The day the meeting ended, Sara bumped into Ashok again in the hotel lobby and noticed that he seemed distracted. When asked what was wrong, Ashok said that a colleague had just seen one of those senior postdocs, who had been with him less than a year, coming out of the job-placement room. Ashok was livid; he considered it a personal affront that this scientist might leave just when he had mastered the techniques used in Ashok's lab. "It's probably for the best," Ashok said, resignedly. "He never had an idea of his own anyhow."
Problems of his own making
We cannot help feeling that Ashok's problems were of his own making. Ashok was a bright, energetic, and talented scientist. He was an acknowledged authority in his field. He ran a lab with 5 postdocs and 3 technicians, and he had several NIH research grants. There was a lot at stake in Ashok's operation; the need to publish and get his grants renewed meant that ideas and data had to be generated, that costly, time-consuming experiments needed to be done, and that important decisions had to be made daily. Ashok was good at all of this and had a track record to prove it. But he couldn't do it all himself.
Ashok needed the participation of bright, motivated scientists, and therein lay his problem. It wasn't that he didn't trust people in his lab; the problem was more nuanced than that. From Ashok's perspective, he just knew more than they did, had more experience, and knew that he could do things better. It seemed only natural that his lab members would look to him for guidance and direction.
Unsurprisingly, Ashok's staff saw it differently. About a year before that conference, Sara had visited Ashok's lab and sat in on one of Ashok's weekly lab meetings. She observed that Ashok was, in effect, trying to do everyone's jobs for them, and detected an attitude of resignation among the staff. Following the conference, Sara wondered if perhaps no one in Ashok's lab ever came up with new ideas or projects because Ashok always beat them to it. Sara wondered whether his postdocs might feel that it was futile to get excited about an idea they might have, only to learn later that Ashok had the same idea, or a better—in his own mind, anyway—idea that left no room for their own. This, Sara was convinced, was at least part of the reason for Ashok's correct observation that he was the only one person in the lab who had ideas.
Like many scientists Ashok wasn't adept at figuring out why people behave as they do. He interpreted the withdrawal of his scientists from the creative process as apathy and lack of motivation. Ashok had no clue that he was the source of the problem, creating a situation in which there was confusion for everyone about their roles.
Perspective of organizational dynamics
It is useful to look at Ashok's problem from the perspective of organizational dynamics. Ashok was frustrated because he was trying to fill two different—and, at times, conflicting—roles. The first role was that of manager: As a manager, Ashok needed to supervise and oversee the work of his scientists, and to use his knowledge and experience to direct and inspire the lab and to educate and train his staff. The second role was that of a scientist. As a scientist, Ashok's job was to use his knowledge to design, plan, and perform some of the work himself.
Ashok's problem stemmed from overemphasizing his role as a scientist at the expense of his role as a manager. Perhaps this was because, as with many scientists who become managers, Ashok felt most comfortable and confident in the role of scientist. Ashok was an excellent scientist, but he had never received any training in managing others, and over time he had developed a dysfunctional management style. Ashok's principle problem was that he did not appreciate the distinction between being a leader and being a worker. He was trying to do his job and his scientists' job at the same time, and he was better at doing their job than he was at doing his own. His scientists reacted by giving up, and Ashok went home exhausted every night.
So what should Ashok do differently? Lab leaders need to strike a balance between using their expertise and teaching expertise. They need to seek the input and ideas of other scientists on the team, involve them in the planning and interpretation of experiments, and teach them the skills they will need to become leaders themselves. Most important, perhaps, lab leaders need to learn to assess their own performance in their role as manager, and to assess the impact of that performance on the other members of the team.
About a month after the meeting, Ashok called Sara and asked if she could help him understand the growing dissatisfaction within his lab. During the course of several conversations, Sara shared her observations with Ashok and suggested ways in which he could be more inclusive in his planning and increase his staff's involvement in decision-making. Ashok acted on these suggestions and, over time, he saw that his staff's morale began to improve and that their sense of ownership of the group's projects increased as well.
With Sara's help, Ashok was able to take a step back, to observe himself and his interactions from a distance (see " Science at the Balcony"), enabling him to consciously monitor and balance his roles as leader and scientist. This delicate balancing act is especially challenging for those just starting to run a lab. In such cases, it is likely that the lab leader will also be a hands-on participant in the work. In such circumstances, it is certainly appropriate for a manager also to play the role of scientist, but not to the degree that she usurps or negates the roles of other scientists on the team. Learning to notice how others in your lab react to you in your dual roles is the first step in assessing how effectively you are balancing these roles.
Carl M. Cohen, Ph.D.
Suzanne L. Cohen, Ed.D.
Carl M. Cohen is Chief Operating Officer of BioVest International and President of Science Management Associates . Suzanne L. Cohen is a Certified Group Psychotherapist and a Clinical Instructor in Psychology at Harvard Medical School. Carl and Suzanne are co-authors of the book Lab Dynamics: Management Skills for Scientists, Cold Spring Harbor Laboratory Press, 2005.