The title of this blog post may sound authoritative but it is far from it. It's is just a set of observations which I have picked up from my own experiences and introspection when I felt motivated or demotivated on a project.
I have been in the software development industry for more than a decade now and having seen some highs and lows, one of the most important question that comes up is - "How do I make sure that the programmers in my team are happy / motivated / doing their best?" This question is by far one of the most important questions that a Product Owner or a Startup founder or an Enterprise CTO faces.
For me also it is a make or break question, if the programmers are not motivated then you can kiss the product / project goodbye. No process (Agile / Scrum / XP) and no monitoring can help you if the programmers lose interest in the project and are demotivated.
In fact, Scrum assumes that programmers are motivated so that they give honest estimates, report impediments in a timely manner and spend time wisely. Without motivated programmers Scrum is a failure before even being implemented. Even if the "carrot or stick" policy is implemented, programmers are smart enough to manipulate the system so that either they are not detected or do just enough to appease the management. Also, code quality takes a nosedive once you have demotivated programmers working on the team.
So how do we solve this problem. Let me share what motivates me and maybe it will ring true for other programmers as well.
###Autonomy, Mastery and Purpose If you are not in the mood of reading and find this article utterly uninspiring, watch this one video and you are done - http://www.youtube.com/watch?v=u6XAPnuFjJc. Essentially, the video says that knowledge workers (programmers in our case) work for three things - Autonomy, Mastery and Purpose. We will see how to apply these principles in software projects (and some other practices) in the points below.
One of the most important thing that the video says (which is easy to miss) is to "move money out of the equation". Enough said.
###Make the project the programmer's baby Allow Freedom
Personally, I have been very happy and motivated in project where - I have joined from the beginning which makes me have a say in the choice of technology / framework or even a library. This also enables me to understand why a certain decision has to be been taken / had been taken.
Essentially, what I am saying is that if the programmer understands the project well and feels that his opinion matters and is valued by the team, he feels motivated to work on it. In a project, each team member should be able to express his opinion freely, discuss the pros / cons of the choices he has made and feel comfortable when taking decision on their own because they know they will either not be questioned or they can make everyone understand. "Move fast and break things" is a motto Facebook adopts because they want to give everyone the freedom to do things on their own without worrying about consequences.
While is not possible to join every project from it's inception but whenever I joined a project midway I was happier when the team listened to my proposals even if they were stupid.
Explain Impact
Another way to make a project a project a programmer's baby is to make him / her understand the project's impact. If a programmer knows that the project has great impact for the organization / intended market they are automatically motivated to do it. From my experience I have that even silly projects can have great impacts. A Twitter clone for the enterprise can drive a cultural change, even an online poker planning game can improve the sprint planning session of numerous teams. Programmers always want to say "hey I built this!" and if they see value in their creation they will invest in it wholeheartedly.
Give importance
Also, programmers should have a say in the implementation of stories. I have seen many times that programmers lose interest when the user asks for something which they feel will downgrade the quality / experience of the product. As programmers are asked to implement features that they don't believe in they lose interest in the project, it is no longer their baby, it belongs to someone else and they are mere "workers". A good question to always ask is - "How would you do it". There can also be genuine cases where a feature is needed which the programmers really don't buy into. In this case, it is worth investing time to understand what the programmers think and reach a consensus.
###Team Formation I have seen "star teams" who are just happy to work with one another that the project quality and execution speed is boosted incrementally. One simple rule to build star teams is to keep them small (3-6 team members) and co-located (preferably), less people mean less communication overhead and ease of understanding each other. Star teams in my experience also diverse. One of the most important thing a team needs to have is mutual respect, senior developer should respect junior developers and everyone's opinion should matter. This makes a programmer feel wanted and committed to the team's goal. In essence treat everyone as equal and be good to each other, this will go a long way. Scrum also promotes this theory rather than the old hierarchical architect, team leader, module leader and team members setup.
###Release often and celebrate the release The title says it all. A good way to demotivate programmers is to not use their software. This takes out the "Purpose and Impact" out of the equation and the programmer feels like a headless zombie.
It is also important to celebrate releases, what is the point of releasing software if the team feels no change and just continues as normal. The human mind is motivated for "happy experiences" for example one can say let's release this week so that we can redo the amazing dinner we had last time. If you are on a tight budget, people can still be rewarded with some time-off to work on personal projects or a trip to the movies.
###Slack I am reading the book "Slack" from Tom DeMarco and it has some great advice. Over the years work places have become more efficient, we look for ruthlessly improving efficiency in even the smallest of areas. I have even worked in organizations which removed paper towels from restrooms to reduce waste and costs (let's not go there).
Anyways, Tom DeMarco says that Slack is important. If everyone is 100% busy all the time, decision making is slow because no one has the time to sit down or think. Without Slack there is no room for creativity, agility and other important things that are required in today's fast changing world (read the Nokia story of engineers not allowed to work on a touch based interface pre iPhone era).
I feel motivated in projects where I have sometime for personal learning and experimentation. If the project is always on fire the programmers will always be looking for exit doors.
###Let it flow and reward quality "Oh you need a server, please fill this 20 page form and give us one month".
"We have a half day meeting today on how to improve the recruitment process efficiency".
These are know productivity killers. We all know programmers work in a state of flow. Organization should aim for environments where "flow" is easily achievable and hard to break.
Finally, one things programmers crave is peer recognition. To motivate programmers I would reward great code and aim to share the knowledge within the organization. A programmer feels happy when is learning and when he feels that he is working with peers who match his intellect or are better than him.
That's it, I as a programmer will be extremely happy to work in organizations where all / most of these points are values. Hope you enjoyed reading this. Please share your opinion and what motivates you as a programmer in the comments below.