Who needs rockstars?

Tom Breur

30 March 2014

Building software is teamwork. Big teams may get a bit “sluggish.” They are difficult to coordinate, it takes longer to reach consensus, and in general you need to factor in more communication overhead, as Frederick Brooks pointed out so aptly in The Mythical Man-Month.

So when the opportunity arises to hire a “rockstar” programmer, should you go for it? A particularly gifted expert for your team? More skills require less headcount, and less headcount implies exponentially less communication overhead. Or so the reasoning goes.

But there is also a downside to having “rockstars” on your project, and not just because they might have a big ego. Working as a consultant, on several projects I noted how much more progress was made sometimes, when the “star” programmer as on holiday. And he really needs to go on holiday, because if your “star” just takes the day off, people will be much more inclined to “wait until tomorrow.”

When one person holds “the key” to progress, he becomes an obstacle to progress. Less people implies less communication only if information flows freely and evenly throughout the team. Not so in teams with a “rockstar” – he all too easily becomes a bottleneck to information flow.

David Anderson has written about this in Lessons in Agile Management (2012, pp 105). The dynamic gets even worse once you experience serious schedule pressure. The last thing you need on a late project is a "hero" (Rock star programmer) to save you. It might well be that the best thing that could happen to your project, is for your “rockstar” to resign…