I couldn’t care less about the most talented developers. They are quite often arrogant, unwilling to share their knowledge and rewrite other people's code constantly. Furthermore, they pull the team down, they create an air of unease. When someone who is immensely talented but hard to work with joins a team, it covers the team in a fog, much like a sleepy town in the early hours of winter. The team can’t see what’s in front of them, only this thick fog that clouds the vision of the project. I will always take a team of less talented developers over even one “genius” level developer. A poor team dynamic created by this “genius” is not one to wish on any team.

The San Antonio Spurs of the NBA, had almost two decades of consistent success. It helped that they had one of the greatest players of all time with the lowest ego of any superstar. The point is not the early years when Tim Duncan was at his peak, the point is the later years before he retired, when Duncan, Tony Parker and Manu Ginóbili were all reaching the finish line of their careers. They beat the Miami Heat with a prime Dwayne Wade, Chris Bosh and none other than LeBron James. Miami was heralded as the best and biggest super team of the last 30 years or so, with a star-studded lineup, how could they possibly lose? Furthermore, they had won the last two championships. Jumping straight to the conclusion, Miami lost 1-4 to an old Spurs team with only one young, rising talent, only in his third year. The Spurs won from a team effort, led by one of the greatest coaches of all time, with aging players but a team chemistry that was second to none. The ball movement, the team spirit and the equal load shared across the team is what put an old Spurs team above an in prime, on paper much better Miami team. Watching the Spurs play each game was a work of art, watching Miami was like waiting for the “genius” level programmer to finish every ticket. The team shouldn’t rely on one person to get everything over the line, not even 3 people in the case of Miami. The sum of the parts is greater than the whole, as they say, and it works the same for all teams. You can amass the greatest team of individuals, but the minute they don’t fit together is the minute the team crashes and burns.

Bear with me as I use another basketball example, the 2012-2013 Los Angeles Lakers. They had traded for at the time one of the best players in the league to pair with two other superstars in Kobe Bryant and Pau Gasol. Furthermore, they traded for an older Steve Nash, one of the top point guards in the past 20 years. They lost in the first round to the Spurs 0-4, not winning a single game. This team was put together without any thought to how the pieces would fit together. Howard and Bryant clashed, Bryant with his unending determination, hard work and brutal attitude towards anyone who didn’t put in 200% effort. Howard was a joker, a clown, someone who was immensely talented but wanted to have fun, he simply was not built the same way as Bryant. As a result, they clashed, and this took the team down with them. Yes there were injuries, key players missed time, but the moral of the story was that even if they all played every game they were going nowhere special. This is the same for software development. A team of individually great members will only get so far if they’re all fighting, rewriting each other's code and generally not playing nice. A team of developers with much less talent but can work as one unit will go much further. A team that is safe for each member, that allows everyone to learn and grow, is one that will stick together longer and produce much higher quality code. A cohesive team has less turnover, why leave the perfect team? Conversely, a team with awful cohesion will have high turnover. The more turnover you have, the more re-bonding the team requires and the more domain knowledge is lost. Each time a member leaves, it sets the team as a whole backwards. Each week that passes that a team sticks together is a week that the team gets stronger. As the team gets stronger, they understand how people work, what the strength and weaknesses of each member are. This allows people to be directed to areas of strengths and to take direct learning opportunities for areas they are weak at.


A team is only as strong as its weakest link and if that link is toxic, or doesn’t want to be there, then the team suffers. If people would rather not be there, then work isn’t done. If people detest being there, then the team falls behind. The feeling of dismay from the members who do not wish to be there spreads like venom through the bloodstream. The team is slowly affected until the toxin is removed. A team can’t breathe, can’t function under the tyranny of a “genius” programmer. Their constant need to do things their way, not sharing any knowledge, instead hoarding it will cause others to hoard knowledge. If a team doesn’t feel safe to ask for help, then people spend days in a state of confusion, afraid to ask their tyrannical senior developer for help. The longer this continues, the worse the team becomes. The worst place a junior developer can be is in one of these teams.

Team success is highly dependent on the team cohesion and the leadership. I will forever take a team of vastly inexperienced developers than have even one extraordinary developer that is a detriment to the cohesion of the team.