Software development is a team sport (Yes, I realize that lone wolf coders can accomplish amazing things, but that just doesn’t scale well). To succeed in a team sport, you need a good team. To understand how to build a good team, you may need to look to other team sports for guidance. Sports like basketball.
In basketball, successful teams often have a handful of stars and a competent supporting cast. Each group makes important contribution and a good team needs both to succeed.
In basketball, a player is usually considered a star when he can do two things well. First, he has to be able to get a good shot whenever he needs one, irrespective of what the opposition is doing. Second, he has to be able to get his teammates open looks at the basket. In other words, his value to the team is two-fold: he sets the agenda and makes his teammates better.
Interestingly, it isn’t always a great thing to have a lot of stars. Back in 2003, LA Lakers added Karl Malone and Gary Payton to a team that already had Shaquille O’Neal and Kobe Bryant. By all reasonable measures, all 4 players were super stars, each more than capable of being the best player on any NBA roster. Most people assumed that the Lakers would easily win their 4th title and they almost did. Except that they lost to the Detroit Pistons.
There are many reasons why the Lakers didn’t win the championship that year. Malone was injured, Kobe and Shaq were feuding, Payton didn’t seem comfortable in the triangle, etc. I too have a theory on what went wrong. It seems to me that having 4 out of the 5 starters wanting to set the agenda does not make for a very coherent team. Too many cooks, as the old saying goes.
Much like basketball, the star on a software team sets the agenda and makes others better. To be a star, one needs to have exceptional aptitude, creativity, and ability to mentor and help guys get “unstuck” when they run into a roadblock. Also like basketball, too many stars can be a liability unless they’re in sync and/or willing to put aside their personal preferences. After all, there is usually a million ways to solve a problem and more than one way of doing it “right”.
The Supporting Cast
Just as important as the star is the supporting cast. In basketball, you often hear certain guys praised for being “ultimate hustle players” or for having “high basketball IQ“. That’s basically shorthand for “He’s kinda slow, can’t jump very high or shoot very well, but he knows his role on the team.” Lakers’ Kurt Rambis was the classic hustle player back in the 80’s. He sure didn’t look like much, but he dove after every loose ball, took charges, almost got decapitated by Kevin McHale, etc.
A key requirement of a good role player is the ability to execute. Be in the right spot for the star to find you, make a basket when given the ball, don’t turn the ball over, hustle back on defense, and so on. I mean, if you’re not a star and you’re not executing well, you’ll be keeping the bench warm in no time.
Software teams badly need good role players. Role players aren’t necessarily expected to define the architecture or solve other people’s complex technical problems, but they’re certainly expected to excel at fundamentals. Write clean code, drive code through tests, follow standards, automate repetitive tasks, help test the application, document code as needed, set up servers, etc. Many things need to get done on a project and not all of them require visionary coding skills. You can make a great living being a competent role player.
You may also like:
Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!