What Makes A Great Tech Team?

Posted by Amanda McVitty on 9 August 2011

There’s been an interesting debate raging over at the Harvard Business Review lately on what makes a great team (and I don’t use the word ‘raging’ lightly - check out some of the comments!). In short, the argument on one side says a team of good performers is going to achieve better over the long term than one or two stars. On the other side, from people in the tech industry in particular, the counter-argument is that one great performer - a star, if you will - is going to be many times more productive than a whole team of ‘pretty good’ people. The counter-arguers point to studies of programmers, in particular, that show ‘great’ programmers can be five-to-10 times more productive than ‘good’ or even ‘very good’ programmers. As Otago University head of Computer Science Brendan McCane pointed out in this week’s Computerworld, this sort of differential is even found amongst third year students at Yale University, where presumably just about everyone is already well above average before even getting out of the starting blocks.

Now, I’m not a technical person (though I work with many and I also live with a software developer), but it seems to me there are a couple of fishhooks in this whole productivity argument. The most obvious being, how is productivity measured? Is it simply the time taken to write functional code? The efficiency and elegance with which the code produced solves the given problem? Or even how well the software written fits the expectations and needs of its eventual end users? Human beings being what we are, on this last point in particular the programmer may think they have produced the best thing since sliced bread but the customer may still be disappointed in the outcome. It’s here, I think, where the false dichotomy of comparing individual brilliance to a great team becomes most glaring. Because in my observation, in the real world programmers very rarely work alone. Here at Optimation, the typical team on a client development project will include one or more developers, but it will also include a range of other skills, such as a solutions architect, business analyst, testers, and a project manager. The client - usually someone from the business side rather than the technical side - is also directly involved at various points (often quite deeply in the case of projects done using agile methodologies). Depending on the project, a variety of other skills, from data analysts to web designers, may also be pulled in at various stages.

For this team as a whole to be productive – that is, to deliver the outcome the client wants, on time and within budget - many more ingredients need to go into the mix than the pure programming productivity of a single ‘star’. (Reminds me of that old Crusaders ad, ‘A champion team will always beat a team of champions’. Something we Hurricanes fans know only too well.) Given the diversity of skills and personality types teams typically need to effectively deliver results, the stereotypical ‘star’ programmer who is utterly convinced of their own unchallengeable superiority [disclaimer: I’ve never met anyone with this level of arrogance in real life but there do seem to be a few chiming in on the HBR comments section] may in fact derail the team’s overall performance.

As I see it, as with any team, there’s a certain alchemy involved in building great tech teams. You need both the creative types and the number-crunching analytical types. You need someone with enough empathy to get inside the client’s head and figure out what they really want, and someone who can help them come to terms with the sometimes painful recognition of what’s necessary versus what’s a ‘nice to have’. When things go pear-shaped and everyone has to work late, you need that person who’s going to bring the music, the jokes and an endless supply of Red Bull. Occasionally, you need the misfit, the person whose first question isn’t ‘how?’ but ‘why?’, and who can radically redesign a business process by questioning its very existence.

From this perspective, are great technical teams really that much different from other great teams? And what does it take to create one?