Saturday, February 18, 2006

Motivating software developers

I've seen how a lot of people don't understand what motivates a software developer. What motivates them to do good work, to work extra hours when needed, to come to work each day, to even stay working for the company.

The problem I think is related to how different types of people are motivated by different things. People choose their profession by where they feel motivated to work. Sales people work towards getting their hands on as much money as they can, and these are people that are motivated by money. So for them incentive pay works well. To give them a percentage of what they bring in aligns their personal motivation with the interest of the company.

On the other hand, software developers are motivated by other things. They love solving problems. If you give me the choice between a highly paid but mindless job, and a medium paid job with interesting problems to work on, I will most of the time go for the fun one. (That is, the one with the problems.)

Many companies have a salesperson type of guy in a management position, and his money-focused approach to motivation is gossly misaligned with the interests of developers. Throwing money around for overtime work will apparently produce results in the short term, but in the long term this actually undermines the basic motivation. Developers need to be motivated differently from sales personnell in order to thrive.

So how is a developer motivated then? I am a developer, and I can tell you what motivates me. It is actually not hard to do, or even expensive. I'm largely self-motivating when I'm just allowed to be. I am a developer because I love to develop software, and if I'm not being held back I will do just that, and do it well. If developers seem unmotivated there is probably something in their way that needs to be removed. If I'm just allowed certain benefits there is no need to spend money on bonuses, I'll still be doing more than I'm paid for.

I'll present here a list of requests that, if granted, will let me work at my full potential. And these aren't costly things, these are just things that take a little bit of understanding and goodwill, and perhaps some small adjustments in the workplace.

Allow me to focus

A developer is best left doing what he loves. Anything else you put me up to is just another something that gets in my way of doing my real work. And when I get too much of this I feel like I'm not doing anything useful. And another thing: Allow me to work in a good working environment. Don't put me the same room with users or salesmen that will interrupt me with every dumb question they can think of, or be talking all day on the phone. I need to concentrate in order to solve problems. If I feel that I can get some work done during the day, I'll be motivated to do so.

Having people around me that work on the same problem as I am, though, is only positive. That's considered collaboration, not interruptions.

Allow me to feel that I am making progress

Building a system bottom-up, starting with backend systems and over time moving towards user interface functionality, makes it hard to see and feel the progress. All I've done so far is to create the building blocks that will later become real functionality. Looking at this isn't much to get excited about. It's not like "Oh my god, my unit test for this business object runs now! This is so cool!". It is much more motivating to implement some working function to completion, all the way from GUI. Something that I can actually see and show off.

This goes not only for the developers, but for everyone involved, from managers to customers. Everyone gets to see that the team delivers something functional, that the project is coming together. And I get to show off what I've made and feel that someone is actually interested in what I do.

A good way to achieve this is to have frequent small releases where a set of functions are chosen to be included each time. These functions should be made release-ready - as in coded, integrated, tested, bugfixed and documented. By demonstrating these releases, everyone sees exactly how far the project has come.

Allow me to make something I can take pride in

I take pride in making good code. Code that not only works, but that is elegant, neat, well designed and tested. Being allowed to finish one piece of functionality before starting something new is a good way to achieve quality. By letting me focus on one thing at a time, and by demanding that it must be both tested and documented before I can call it complete, I can make something that I can take pride in. I'll know I have done solid work. My spirit is high and I can stand proud to show what I've accomplished. So now I am motivated to take on the next challenge - the next release - knowing that I haven't left behind a complete mess that will haunt me with bugs for a long time.

Allow me to do it for me, not for the money

As I am taking pride in my work - my craft - I'm doing the best I can to make quality code and deliver on time. If I'm pressed on time I'll work overtime to deliver something good rather than mediocre. This additional effort is motivated by my commitment to the team, to the company, by my pride and by getting to do what I love. By tying cash bonuses up to the reaching of some goal, milestone or whatever within some timeframe I'll feel that I'm not trusted to be putting in that extra effort otherwise. It turns all that goodwill into greed, and before you know it I am not really committed to the work anymore. This is extremely dangerous. As hard as it is for anyone but the developers to tell what level of quality is being delivered, when my motivation is tied to the bonus I can get away with a lot of shortcuts and crappy code.

Also, bouses that are not distributed evenly between everyone in the team - or even between teams - will be grounds for envy and give root to discusions. It contributes to splitting the team, not building it. Also, if I got less than someone else I'll feel that my effort is not appreciated. And, anyway, how can management objectively and correctly determine what each person's contribution to the group is worth?

Allow me to work on interesting problems

If I am given a difficult task I will take it as a challenge, feel good about being trusted to handle it, and be motivated to show how good I am. Of course not all tasks are challenging, so I can't be given these all the time. But just make sure that there are at least some exciting tasks between the trivial and boring.

If the same types of tasks are assigned to the same people all the time - designers do only design work, testers to only testing, and programmers do only coding by a detailed spec - they'll all get bored quite soon. People are interested in more than just one thing. By rather putting all these people on the same team and letting them work together through all phases, they will challenge each other and learn from each other, and they'll be having lots of fun doing it.

Allow me to be part of a team

Solving problems together, bouncing ideas around, getting challenged on my own ideas. There are so many joys of working in a team. If I get to work in a team with people of all different fields, and we all focus on the same set of problems, we all will be having a great time. Motivation will be high, and we will be able to get some great work done. What's often done instead is to isolate everyone by having them work on individual tasks, separate them with walls or in cubicles, demand that they communicate through written documentation rather than casual discussions, and having them all so pressed on time that there is no room for collaboration.

There are so many benefits to teamwork I can't really list them all. Quality will improve as we get to discuss ideas, we solve problems together, and I get reviewed on my work. Social aspects improve for obvious reasons. Commitment to the team is high and everyone will notice if I'm not delivering. Knowledge transfer is high from constant discussions. Everyone's total overview of the product is better, and any potential problems or bad decisions will be detected sooner. It all contributes to increase motivation.

Allow my ideas to be taken seriously

I'm the one closest to my own situation, so if there's anything holding me back I'll be the first to know. Provide me with frequent opportunities to express any ideas or concerns that I might have, and let whoever I'll be talking to have the teams interests at heart. Listen to my ideas and concerns, I might suggest something that would improve the whole team's productivity, or point out something that is holding us back. It goes a long way to motivating me just by having me feel I am taken seriously - that what I do matter.

So, there you have my list. It's not too much to ask is it? There's nothing too fancy. Nothing that costs a lot of money. Just some simple requests to help me thrive in my workplace, to let me actually do my job. That's where my motivation comes from.

No comments:

Post a Comment