The Psychotic Task of Measuring Developer Productivity
Measuring developer productivity is a purely and utterly psychotic task. There is no better occupation than that of engineers and developers to game a system that is in essence a game to begin with. Set a metric, make it fair, make it reasonable and at some point it will become a game. The real question is, “are we moving steadily, reliably and responsibly toward our goal with the mission of the company in mind?” Can that even be measured? Is it even reasonable at a tactical level to measure these things? In almost every situation it is pretty insane, but endeavors are made every single day. Sometimes these endeavors are more successful than others, but in almost every situation but a few, these endeavors lead to turnover and odd levels of progress, unreliable software, and sometimes even a lack of responsibility in what is being built. However some have been exceptionally successful in retaining employees, progressing steadily, and endowing responsibility in the efforts to customers, those building it, and others involved in the effort. I’ve managed to work for a few of these companies, others have worked for a few others that I know of. For this article, I’m not going to name the names of the companies, because that will distract from the point as people debate endlessly their positives and negatives. Instead I will write about some of the specific tactical endeavors and how they achieved progress, reliability, and responsibility. Who has which weaknesses and who has which strengths? Find the strengths, pair them with the weaknesses. One of the most effective tactics in building and maintaining a strong team. Here are some of my observations on how to focus less on productivity and more on the overall strength of the organization.
- Pair strengths with weakness, weaknesses with strengths at least 20% of the time. If someone is really solid with JavaScript on the server side, pair a client side JavaScript coder to do some Node coding together. Flip them around, since all have strengths and weaknesses, and let the client side JavaScript coder lead the pair for the Node.js coding.
- Build character, especially in young and inexperienced developers. People need reminded when they do well. Merit badges and the like are great, but real rewards are spectacular too, such as monetary or otherwise. Especially if the feature is a million dollar feature, get them a cut of that real money. They won’t leave, and they’ll be damn proud of what they accomplished!
- Speak about failures as failures, bring them into the open, discuss them. But above all, bring a failure as a failure, not a person on the team as a failure. One failure is a failure for the team, not the individual. Attacking an individual is tantamount to disrespect – eliminate disrespect and remove it from any culture immediately.
- Be inclusive, find those that aren’t the mainstream person. Find those that can bring new thoughts, ideas or observations to the team. Help them help us all be successful in maintaining our efforts. Don’t leave out people because it seems they might be odd or different or not the standard “white male programmer”. This means leadership must actually talk to people outside of their circles, leadership must expand it’s personal networking, leadership must stand at the forefront of these efforts and set ideal examples – not just speak of lofty goals. To do otherwise is for leadership to fail, perpetuate that failure, and wreck any chance the company become something great.
- Stop being passive aggressive, it doesn’t help anybody assert themselves in a way that will improve their ability to code.
Being a developer or engineer has as many “productivity,” issues as any sales, operations or marketing job. And really, it’s still largely guessing game about what developer productivity really means. But one thing is for sure — be wary of the unwritten rules, the issues that come when a good guess only gets you so far.
Feature image via Flickr Creative Commons.