Twenty years ago, I was a contractor at Lotus Development when they ramped up a huge new database product code-named No Comment (it didn’t ship, but that’s another story). The QA manager found herself with 27 people who didn’t know one another, who had no idea of each other’s skills, and who weren’t even sure if this was the right project to be on. Sandra didn’t know the difference between a database and a pogo stick, but she did one thing well: She turned us into a team.
Sandra got people to work together in small teams, praised publicly, and often worked hard to establish a “theme” that differentiated the No Comment QA team from everybody else. For us, it was a team affection for a particular noodle dish from a Chinese restaurant in Cambridge.
The result, at least for No Comment, was that everyone on the team really cared about one another. More important for Lotus, though, was that we each gave 100 percent, and we demanded the most from ourselves and from each other.
On such teams, it’s as though someone cast a spell of “these people work well together.” Everyone understands what each person contributes. The respect—it doesn’t always mean “liking one another”—causes you to deliver the best you have to give. When you look back, years later, you think of it as a golden time.
Some developers and testers responded defensively when I asked about the ingredients for turning a random bunch of people into an effective and joyful team. You can’t “manage” camaraderie, they said—you either have those sorts of management skills or you don’t.
I emphatically disagree. While it may not be possible to create business rules that generate a golden team, you can do several things to encourage its growth.
First, let the team’s dreams have power. Seek team input whenever possible, says Shannon Brown, senior manager, IT quality assurance, at Applebee’s International Inc. “I realize that some companies don’t always encourage a ‘democratic’ leadership style, but this style has helped me create some of the highest-performing teams,” she says.
Team input doesn’t mean anarchy, though. When Erin Stadler, a project manager at MA Metal in Edinburgh, Ind., started her job a couple of years ago, she had “a lot of smart people all working on their own in cubes,” with no processes in place. “We spent some time assessing how the groups communicated, and how we could extend the natural flow of communication. By bringing the group together, we were able to create a process that everyone felt they had contributed to, and that they could use to help control the amount of change that had been rampant on the projects.”
Anything you can do to encourage people to communicate—with you and with each other—will have a team management payoff. Much of this is making yourself approachable. Stadler spent time getting to know each team member, which made them feel comfortable about coming to her for help. “Many times, these guys stuck in their cubes forget how to call meetings or to get the right group members together to get things answered, especially if they needed help from outside of engineering,” she says.
There are also payoffs from the pairing programming methodology: two people sitting down and working together. David Saff, a Ph.D. candidate at M.I.T. and a former software consultant in Cambridge, replaced his hour-long weekly meetings with eight one-hour pairing sessions. “In each session, I would sit down, the team member would explain to me what they were currently doing, and we would work on it together. In the downtimes [compiles, tests, source code check-ins, database loads], there was plenty of time to talk about any organizational concerns,” Saff says.
Part of what’s necessary is honest feedback, and knowing when to give it—both praise and criticism. “My team knows I’ll come to them with the tough topics when necessary—always in private, of course. There’s nothing more demoralizing than having one or two team members who are slackers when everyone else is working hard,” Brown points out.
When you must pull someone aside to criticize, don’t do it in a way where everyone knows what’s going on, suggests one tester. Let people keep their dignity.
Divide and Concur
Successful teams argue, debate, ask tough questions and eventually reach consensus. To do this, they have to have unique viewpoints, and that requires people from different backgrounds. “At first, this is hard to do—you think, how can all these people with different backgrounds gel together and contribute,” says James O’Malley, senior tester at FileMaker Canada in Ottawa, Ont. But, he says, people who think differently motivate the team to realize that bugs can be found and approached from many angles.
One way to encourage healthy interaction is competition. “Dividing teams into smaller teams and setting up friendly competition among the teams reaps the benefits competition provides. Humans love to compete,” says Nick Morrow, Lt. Col. (Ret.), USAF, who has had responsibility for a few software projects.
Breaking people into smaller teams offers other benefits, O’Malley says. “Once a week, we would show weird or really involved bugs—and how the person found it.” Doing so allowed the person who found the bug to earn praise, “but you could see it turn some light bulbs on in other people.”
A golden team without anything to do is hard to tell from a gang. If everyone has a clearly understood, shared goal, it’s easier to form a great team.
But the priorities have to be understood. Given that the elements of a software project are its scope, schedule, cost and quality, each participant will focus his attention on a different element. The tester may have a quality goal; the developer might focus on scope; and the project manager thinks primarily about the schedule. If everyone tries to contribute only to his own goals, says Ainars Galvans, test manager at Exigen Group in Riga, Latvia, then “this can’t be a dream team.”
Rewards, too, need to be understood—both the big ones, such as career opportunities, and the small ones, such as internal team awards. When Brown first became a team manager, she found a miniature baseball ball-and-glove in a toy store. “I brought it in to the office, named it the ‘Good Catch’ award, and awarded it to one of the testers who had just found a defect that had been plaguing the developers for two months.”
I’ve grown convinced that the success of a team is somehow related to food. Perhaps it’s a reflection of the human need to break bread with one another; many issues are resolved when people take the time to eat and talk with one another.
Often, food is part of something larger: team activity outside work. “It’s amazing how the team gels outside of work, when they can do things together that are not work-related. You can also see strengths of people that you would not normally see in the office,” says O’Malley.
But while it’s fine, say, to take the team to a baseball game, never make it mandatory. At one company, management tried to build team spirit by having “socials” after work hours—an after-work buffet with drinks. But since it was mandatory, as one co-worker summed it up, “If you want to build my team spirit, give me some time back. Don’t take more.”
If you manage to create a dream team, don’t change it. The fastest way to dissolve the magic is a personnel change.
A tester from Latin America says that it’s easy to believe in friendship and equality until something threatens it. “We really think that everybody is our friend—this includes the boss, the management, everyone, until…a promotion.”
Is it all worth it? Absolutely. Elizabeth Ross, enterprise support manager, Tetra Tech Inc., says that although it hasn’t been easy, “I credit a lot of our success with our internal clients [the business units] to how flexible we’ve had to become to work with each other.”
About the Author
Esther Schindler