Competition between teams does not improve performance. In fact, the added stress may shift team members' focus from creating a quality product to self-preservation due to fear of failure. Johanna suggests managers emphasize collaboration between teams over competition.
“Jonah and Sarah, this next round I want to initiate a little competition to see whose team can develop the best product. Won’t that be fun?” Dave, the VP of engineering rubbed his hands with glee. “OK, what’s next on the agenda?”
Sarah looked at Jonah. “Dave, we’re not done with this agenda item yet. If you want the best product, why don’t we collaborate instead of compete?”
“Well, everyone knows that friendly competition makes the best products, right?”
“Well, I don’t know that,” Sarah retorted.
“I don’t know that, either,” Jonah said. “In fact, my team works really well with Sarah’s team. I don’t want to see us lose that ability to collaborate. What do you want to have happen here? A competition or the best product?”
Dave leaned back in his chair. “I want the best product, but I want it fast. I thought a little competition might speed things up.”
Sarah leaned forward. “Then let us collaborate. We’re really good together.”
Jonah nodded. “Our teams like working together. Sometimes, it’s like a super-team.”
“Well, why don’t we merge the teams and have just one team, then? Why do I need two managers, if your teams like working together so much?” Dave sounded confused.
“We need two teams, because between the two of us, we have more than thirty people. Jonah and I are already on the hairy edge of not being able to manage the people we have.”
Jonah nodded. “Right. We can manage them because, as agile teams, they are self-managing. We don’t have one team underneath each of us, we have several teams ‘underneath’ us.” He used airquotes.
“When our teams collaborate, they work on the backlog—sometimes the same backlog, sometimes different backlogs—all in service of the roadmap. Sarah and I have one-on-ones with our team members. We help remove obstacles the project managers or team members can’t remove themselves. We help the team members solve problems with intra-team communications. We don’t solve problems for the team members that they can solve themselves. We facilitate the work of the people in the teams.
“If you made one team of thirty-three people, neither of us could ‘manage’ that many people. We couldn’t have one-on-ones even biweekly. We couldn’t remove obstacles or solve problems, whatever you would like to call it. It’s just too many.
“Currently, we each have several teams of four to seven people doing the technical work. Many of those teams collaborate with each other to make products for the good of the company, and we encourage that.”
Sarah picked up the conversation. “If you want these collaborative teams to compete, we can’t stop you. But, it’s a terrible idea. Instead, tell the teams what you want—a great product—then let them decide how to do it. You might even say, ‘I thought about having a competition. Do you think that’s a good idea?’ then see what they think of that idea. But don’t mandate it.
“You hired these people because they can think and produce. Let them.”
“Now, did we convince you competition is not such a good idea?” Jonah wanted to make sure Dave understood.
“Yes, you did. I got it. OK, now can we go onto the next agenda item?” Dave shook his head. “What would I do without you guys?”
Sarah laughed. “You’d make mistakes. That’s why you have us.”
Dave, Jonah, and Sarah all laughed.
Management-Based “Friendly” Competition Never Is
When managers decide to introduce competition between teams, it’s almost never a “friendly” competition to create a great product. There are winners and losers. Those on the losing team often have a surprise waiting for them on their performance evaluations.
In software, we learn. In learning, we should expect some failures. The key is to fail fast, not slow.
When teams or people decide on their own to have a friendly competition, they learn together. That’s because it’s peer-based. Instead of a reward or a performance evaluation, peers improve their mastery of their craft, egging each other on. Everyone wins.
What Are Your Management Objectives?
If you think you want a “friendly” competition between or among teams, consider first what your management objectives are. Do you want a great product? In that case, make sure you haven’t asked the teams (and each person on the teams) to work on anything but this project, so that they can focus. Then, consider asking the teams if they want to collaborate. You might ask the teams to brainstorm ways in which they collaborate. They will have many ideas—more than just competition.
If you want to see which team is “better,” you are making a mistake. Each team will develop solutions differently. Since you will see a different solution from each team, it’s not possible to compare teams.
Ask the Teams for the Results You Want
Once you know your objectives, ask the teams for the results you want.
If you want a variety of solutions, tell the teams, and tell them why. Maybe you want to timebox possibilities. Maybe you want to see options for your clients. The more information you provide the teams about your objectives, the better the teams can fulfill your needs.
In any case, the more information the teams have, the better your outcomes will be.
You hired smart, capable people. Let them work in a way that proves how smart they can be.
If you are worried about seeing deliverables, ask the teams to provide solutions or interim solutions inside a specific timebox. Teams, especially agile teams, are often willing to timebox solutions for you, if you explain why.
Management-based competition does not help people perform better; it creates stress and anxiety. Instead, tell people what you want and let them decide how to deliver. You will get the results you want, without the false structure of a competition.
Read more of Johanna's management myth columns here:
- The Myth of 100% Utilization
- Only the 'Expert' Can Perform This Work
- We Must Treat Everyone the Same Way
- I Don't Need One-on-ones
- We Must Have an Objective Ranking System
- I Can Save Everyone
- I Am Too Valuable to Take a Vacation
- I Can Still Do Significant Technical Work
- We Have No Time for Training
- I Can Measure the Work by the Time People Spend at Work
- The Team Needs a Cheerleader!
- I Must Promote the Best Technical Person to Be a Manager
- I Must Never Admit My Mistakes
- I Must Always Have a Solution to the Problem
- I Know How Long the Work Should Take
- I Must Solve the Team’s Problem for Them
- I Can Move People Like Chess Pieces
- Management Doesn’t Look Difficult From the Outside, So It Must Be Easy
- I Can Compare Teams (and It’s Valuable to Do So)
- It’s Always Cheaper to Hire People Where the Wages Are Less Expensive
- If You’re Not Typing, You’re Not Working
- You Can Manage Any Number of People as a Manager
- People Don’t Need External Credit
- Performance Reviews Are Usefult
- It's Fine to Micromanage
- We Can Take Hiring Shortcuts
- I Can Standardize How Other People Work
- I Can Concentrate on the Run
- I Am More Valuable than Other People
- I Don’t Have to Make the Difficult Choices
- I Can Treat People as Interchangeable Resources
- We Need a Quick Fix or a Silver Bullet
- You're Empowered Because I Say You Are
- Friendly Competition Is Constructive
- You Have an Indispensable Employee
User Comments
Excellent article. Might be worth pointing out that the sort of competition described here is not the same as where there are two (or more) possible solutions to a problem and nobody is sure which is better (best), so a "fly-off" is arranged. That is just normal development, where the different options could in practice all be developed by the same team as part of exploratory development.
Keith, thanks. Glad you liked it.
When you have a "fly-off," everyone knows you're doing that. You're right, it's different than a management-mandated competition. A fly-off is when two (or more) teams compete among themselves to see if they can create the "best" solution to a problem. As Keith said, those teams could be small. I've seen teams be as small as tester-developer pairs. The difference is that the product developers agreed to the fly-off in advance.
When managers insinuate themselves, the game changes, and not for the better. That is the problem.