This simple paradigm can be applied to nearly everything in our world today. A calculator takes basic numbers as input and produces answers to mathematical statements as output if its user pushes the buttons just right. A dust mask takes in dusty air and produces clean air, if the user breathes in the right direction.
This paradigm can also - shock, horror - be applied to software developers. They take in vast amounts of coffee, V, Marvell v. Capcom movies and so on, and produce software. But what is the handle on this machine? What powers this somewhat-frightening caffeine-to-code conversion? The answer is pretty simple - their motivation.
Oh, but they do it because I asked nicely, I hear you say. Oh, I've got him by the scruff of the neck, I hear you say... well, perhaps not. As this codinghorror.com article suggests (but does not quite explore), most great developers have immense pride in both themselves and their work.
It could be said that by buying a developer better equipment, or by just throwing more money at him, you could be motivating him - sometimes this is true, but more often than not, it's not. Truly great developers take their motivation from their pride, and the weaker developers can be motivated by fostering their pride.
So, let's look at some of the common nuances of what makes a developer tick:
- The money. Yes, it has to be said - paying someone well is the baseline for making them feel like they are being rewarded for the contributions they make, and someone who makes great contributions should be rewarded greatly. However, this does not necessarily create motivation - as time goes on, what you are paid tends to matter less, so as long as a developer is being rewarded sufficiently, a salary can never be a motivation - it only serves to prevent discontent. This is not to be confused with the use of bonuses as motivation - see below.
- The pressure. As with money, a certain amount of pressure is needed to maintain life, as a certain amount of oxygen on Earth is needed to sustain life. Too much of it, however, does not necessarily yield better code, or faster delivery - did you know that oxygen is toxic?
Notice that, of the two common things that are seen to increase productivity, neither truly has a positive effect - at best, it just won't make your developers leave your company quite as fast.
Given what we have discussed so far regarding the source of developers' motivation, consider the following methods of motivation - if you keep that developer happy, he will continue to write excellent code at a good rate, and given how expensive they are per line they write, you want to keep them as happy as you can.
- Caring. This means involving your developers in the day to day running of the company. Make them feel a part of the action, as if they have a finger in the Pie of the Future. Involve them in meetings, even if you think they will have nothing of value to say. It will help them feel instrumental to the company, they will have been heard, and by truly feeling like an important component of the company, they might just care enough to work harder and to feel good about it at the same time. You never know - maybe the next great idea comes from the mind of a programmer who just happens to have a deeper understanding of the world than you think.
- Challenges. A healthy mix of challenging and mundane work will help keep your developers motivated. A programmer goes through a natural cycle, where he/she craves a decent challenge - once they get that challenge, on its completion they typically crave a few simple tasks; once they get far enough through those, they will crave once again for a challenge. Rinse and repeat. The important factor here is one of joy and success - once a developer gets the kind of work he/she seeks, they are happy at the prospect, and thus more likely to slip into a state of flow. A conquered challenge is its own reward. Simply by learning what your developers are desiring in terms of challenge vs. mundane, and cleverly arranging the workload to suit, you will get that work done faster and with less nonsense.
- Bonuses. When a developer accomplishes something great, reward them. Give them a cash bonus on the spot; take them for lunch; buy them that gadget or doohickey that they desire. If other developers complain about this, tell them that if they accomplish something great, the same will happen to them (See Competition below). Do note, however, that if you give them rewards like movie tickets, etc. instead of money, you must be in tune with what they desire in such rewards. Nothing sours a developer's mood faster than a pair of Sound of Music movie tickets after putting in the effort that turns that big contract into a success.
- Competition. This is perhaps the most powerful tool in the manager's toolbox. It may sound cruel, but by pitting your developers against each other, and letting them have fun in the process (don't be alarmed by the odd prank, though), you will let their productivity and output quality reach new heights. The reason why communist and socialist nations the world over have lagged behind their capitalist counterparts, despite having an abundance of resources, is simple - without competition, there can be no success. It is in our nature to try to be better than everyone else - see all those 4x4's on the road? - and in a development team, this kind of attitude mixed with a sprinkling of fun will let your entire team soar. Go through the source control system each Friday and put up the best piece of code, and its author's name, in a frame in the office. Buy the three developers with the least bugs per line of code some beers. In a company whose development team I managed, we all came together on the last Friday of every month for a Robocode tournament, and the winner had his coffee made for him for the next month by the losers (This led to some interesting results - a colleague of mine circumvented the security manager in the JVM, and used reflection to call the kill() method on every opposing robot. He had his coffee made for him for two months after that one). There may be one or two that struggle to keep up, but you should be mentoring them anyway - otherwise, what are you doing there?
- Atmosphere. Developers must have a good working environment in order to be productive. In unduly noisy, dirty, hot, cold, light, dark, etc. environments, developers' productivity can suffer greatly. Make sure they have an open space, with the correct light level, good equipment, with good climate control. Something that is very often overlooked as well is the developer's chair. You cannot play guitar with sore fingers, and you cannot code well in an uncomfortable chair. Take them along to try out some chairs in your budget, and see which they prefer. A simple $100 investment like this can repay itself many times over.
- Socialising. Developers are social folk too, despite their pasty white and often unsanitary appearance. Let them mingle with their co-workers, and let them have a good time. Buy the whole office some beers on a Friday afternoon, so they can all mingle together and foster their working relationships. Perhaps most importantly, make sure you mingle with them and get them to recognize you as one of their own. As the Afrikaans singer/songwriter Piet Botha once sang (translated), "The General rides around in his gleaming black car while he plays chess with the children of our land" - lead from the front, not the rear.
Now, your mission is to learn how to use your developers' pride in combination with these items to improve their productivity by a considerable margin. Developers see their work as an extension of themselves; see if you can figure out how to incorporate that into your management style to further improve their everyday productivity.
Hopefully these lessons will help you in building a great team who can accomplish nearly inhuman feats of software development, while having fun doing it.
