What to do when your (so-called) MVP is destroying team productivity.

Luke, the manager of the Rev 2.0 team, was walking on eggshells. He’d had another blow up with Shelly, the team architect. He tried to talk to her about the way she had treated the newest employee, Brent, in the design review meeting on Tuesday. But when Luke asked Shelly to be more patient, she exploded.

“Look, my time is too important to waste explaining the obvious to the stupid,” Shelly snapped. “It’s not my fault you hire unintelligent people who can’t understand this stuff.”

“But, Shelly,” Luke said weakly. “It’s important that everyone on the team gets along.”

Shelly snorted. “Hire some smart people, and we’ll get along just fine. In the meantime, just remember that I’m the one who was smart enough to figure out the algorithms for this system.”

She didn’t need to add “You need me,” but the threat was hanging in the air.

Luke’s face burned every time he thought about that conversation. He knew they needed Shelly, but her abrasive behavior was upsetting the team. They avoided her, struggling silently to support her code rather than risking her wrath by asking a “stupid” question.

So when Luke attended a workshop on giving feedback, he asked for some coaching on responding to difficult people.

“Describe difficult,” the instructor prompted.

“Well, I have this architect,” Luke said. “She gets defensive when I give her feedback, and she doesn’t accept what I say. She thinks she’s always right.”

“Tell me more,” the instructor coaxed.

“Well, she’s brilliant. And she’s an order of magnitude more productive than anyone else on the team—she really cranks out the code. But while most people can hold six or seven thoughts in their heads, she can hold fifteen or twenty. Everyone else has trouble following her code, and when they ask for help, she’s disdainful.

“When I talk to her about it, she gets mad. I can’t afford to lose her. I need to find a way to coach her to be more patient with the other team members.”

The instructor paused a moment, then said, “So the way she writes code and the way she interacts with the team make everyone elseless productive?”

“I’ve never thought of it that way,” Luke said on reflection.

“I wonder what would happen if she left the company?” the instructor asked.

“Oh, that would be a disaster. No one knows the code the way she does, and no one can figure it out.”

“That sounds sort of risky.”

“You bet!” Luke agreed. “But what can I do? We need her.”

“Do you really? Or are you being held hostage?”

Luke mulled that thought over during the rest of the workshop. Back at the office, he spent a week observing the team and examining metrics. He listened carefully in one-on-one meetings and probed to gauge both current morale and aspirations. As he listened and watched, he formed a new picture of the dynamics within the group.

The following Monday, he asked Shelly into his office.

“Not another sermon on manners,” Shelly sneered.

“Nope,” Luke said. “We need to have a talk about how your code and your style are affecting the rest of the team.”

Shelly sat across from Luke and glared. “I can walk out the door any time and find a new job in two days.”

“I’m sure you can,” Luke agreed. “I want talk about each issue separately.”

Luke described the behavior and work results that were getting in Shelly’s way. He described the impact her behavior and style were having on the team and the department.

“Shelly, if you make some changes, you’ll be successful in this job. And you’ll put yourself in the position to be even more influential across the company. Are you willing to work on these issues?”

Shelly thought for a while, then gave a quiet “Yes.”

She and Luke worked out new expectations for code maintainability. Then, he coached her about different ways to work with the rest of the team.

Shelly didn’t experience an overnight transformation. She’s still gruff and has to count to ten in her head to keep from snapping at less-experienced colleagues, but she’s working on it. She has worked to simplify the code and has explained it to the other people in the group. She listens to questions and suggestions, and even pairs with less-experienced programmers to help them learn the code base.

Six months after their first frank conversation, Shelly asked Luke what he would have done if she’d walked out the door as she’d threatened.

“I would have let you go,” Luke said. “The way things were going, I was putting the company at risk and denying the other team members the chance to develop. I was underestimating the cost of turnover with the rest of the crew and not considering how their productivity was suffering. In a way, I feel I owe you an apology for letting the situation go on so long.”

“That was a tough conversation,” Shelly said. “But looking back, I’m glad you told me. No one had ever explained to me that my attitude was hurting my prospects. And now that I’ve gotten to know the other guys better, they aren’t so dim—just young and inexperienced.”

Luke smiled and thought, “I sure did talk my way out of that crisis!” {end}

This article originally appeared in Better Software magazine in 2006.