Keeping 'Rock Stars': Plausible?

Now, I don’t necessarily consider myself a ‘rock star’ engineer/programmer/developer/code monkey, so this isn’t some arrogant post about how awesome I am. I am awesome though, just sayin’. I recently read an article by Joe Stump, HOWTO: Maintain a Rock Star Culture, which spawned some thoughts of my own. If you haven’t read his post, go do it, it’s a great read. I think it might be better titled: “HOWTO: Keeping Your Rock Stars”, personally.

I think what shocks me a bit is how much of his post seems common sense, yet still needs to be said. Maslow’s Hierarchy of Needs has been around since 1943, makes a lot of sense, and can be applied to just about any profession. Stump’s article mainly expands and focuses that hierarchy of needs specifically for software developers, and not just any developer but ‘rock stars’. Obviously, depending on your field the type of people you will employ will be rather similar, and thus have generally similar goals. Your ‘rock stars’ are going to focus the most on the ‘Self-actualization’ and ‘Esteem’ aspects of the hierarchy of needs. Love and belonging isn’t something as an employer you can always have an impact on, other than creating a friendly environment where you employees can get along and build friendships. Safety, not much of an issue in software development really. Other than some nasty PHP code making my head nearly implode, I generally feel rather safe at a keyboard. Finally, physiological isn’t entirely relevant, you’re paying them well, that covers that.

So, self-actualization and esteem are easily the most important bits with your typical developer. Yet, for some reason, these are so often overlooked. Stump points out a lot of items that helps his developers realize these needs:

  • Engineers should drive feature development
  • Allow flexibility on how/when/where your engineers work
  • Enforce reasonable hours
  • Encourage “I don’t know” as an answer
  • Make them comfortable (desk, chair, equipment, etc)
All of them make a lot of sense. Doesn’t take a rocket scientist to connect the dots to show that a happy, comfortable employee, makes for a more productive employee.

Here’s where my curiosity comes in though. All of his tips and tricks make a lot of sense, but how does that work over the long haul? If you truly have ‘rock stars’, then you have head hunters chasing those ‘rock stars’. Some would say that the person quitting is inevitable anyways, which is probably quite true (read: Up or Out: Solving the IT Turnover Crisis). How long can these perks actually keep the employee around? Perhaps the real point is keeping awesome engineers for a couple of years, and then recruiting new ones to replace them, when the original engineer inevitably quits.

Turnover is expensive though, especially when you’re shelling out $3000 to each new developer for them to purchase their own equipment. Hence, you never want your developers to really end up leaving you, which is sort of a no-brainer. I look at my current situation, where when I came on board it felt like there were a lot of awesome perks about working with Imaginary Landscape. To be fair, there are some awesome perks. I have an incredibly cushy situation. However, I also look into the past and see a graveyard of great developers (Ian Bicking, Chris Webber, Tamas CantRememberHisLastName), which has always been a bit of a concern of mine.

I think overall what I’ve learned recently from the two articles previously mentioned is that skilled workers are always going to a quit. It really is just a question of when, not if. The life of a developer is one where the proverbial glass ceiling will always exist. You’ll always reach the point where the company you’re with will eventually run out of challenges to offer you. Really, as a tech company you’re never trying to “keep” engineers, you’re trying to prolong the amount of time that they end up sticking with you.

I think Joe Stump’s idea of building a ‘Rock Star’ culture is a step in the redirection for prolonging the amount of time you get to hang on to a great engineer. I think ultimately though, the key is to never stagnate, always encourage innovation, and constantly move forward. Essentially, all the perks in the world can create temporary happiness, but challenging (reasonable) work always ends up being more important. Perhaps it’s because many developers grow up as introverts, that playing to their ego and making them feel important seems to work so well.

Oh well, enough mindless rambling on this subject. I highly recommend reading the linked articles though. They’re really good, and quite thought-provoking.