Competition versus Cooperation

byPawel BrodzinskionJanuary 13, 2007

I was asked a question during my interview in Wind: what do I think about competition in the team? I remember the question because it surprised me a bit. I guess I should have known something in that area would be checked and should be prepared to hear the question.

My answer was that I prefer cooperation over competition in the team. Competition can bring some good results, but in most cases teamwork can bring better ones. I reminded that because one of my teammates said few weeks ago that he didn’t like rat race. Message like message, but the context was important there. I’d just employed a couple of newbies within his very team and he was just after hard core architecture meeting when he was intended to learn, but didn’t really understood much (it was way too hard core I guess).

I can imagine he started thinking about competition in the team. Maybe I would too if I were in his shoes. Hey, maybe those new guys are here to get rid of me if I’m not as good. And maybe I’m not as good because I don’t get what this overweighed guy is talking about during last three hours. Maybe…

He couldn’t have been more mistaken. The team is a specific one – five persons but working in two different cities. Both groups have different tasks and quite different type of work. Newbies aren’t there to increase competition, but to help current staff. And they wouldn’t probably understand even one tenth of what the guy understood during the meeting. Have I mentioned that the meeting was a hard core one?

There’s one thing more – I’m strongly against building competitive atmosphere in the team. If you give me a choice I’ll always choose helpful and cooperative atmosphere. And as far as I know I still have the choice here.

Developing software is neither like run nor like race. You can take your half dozen of people and tell them to be on the finish line as fast as possible, competing with others. You’ll probably end up with a winner, who’ll perform better then usual, a challenger who’ll be fighting to the end and also will perform better and four people who soon will see they have no chance to win and will reject to compete. Your project will be finished really fast… in one third. Remaining two thirds will be completed significantly later. And because when project is 90% finished it’s also 0% succeeded you’ll wait until the very last person ends her work.

Developing software is like playing a soccer or basketball match. Everyone in the team should be conscious that the team performance is the key, not personal achievements of a single player. Sure, not everyone will do the same work. There’re stars, who are far better than average, and those who makes the hard work with no flashes pointed at them. People deliver different value to the team and their reward (salary) is also differentiated. However, the effect is judged by the result of the game (project): it was either won (successful) or lost (failed). You won’t be praised much when you scored 40 points playing selfishly and your team lost the game. You won’t be praised much when your piece of code is excellent but you haven’t found the time to help a newbie colleague.