I have always considered the summer brake as a good period for self-evaluations more than year-end when too many external factors blind your analytic skill.
Doing this i found very useful writing down the list of what i consider motivating for a developer trying to extract some boolean questions for auto test your motivation level.
As a project manager, or architect you don’t have the privileges to handle all the following factors that usually refer to managers and ceo, but it’s always interesting try to put on others’ shoes to better understand feeling and reasons.
Get rich or die trying
This is one of the most controversial point: money. According to the
Maslow’s Hierarchy of needs this is really a basic factor of everyone happiness. Point is that developers don’t want to be reach, they just want to be rewarded proportional with their efforts. Money is a good trading indicator. It is also the only attribute that let you objective compare your job with others’. Don’t think to your developers as people that just want to be rich exploiting your company, but don’t do the error to think them as volunteers. You must be sure to remove money as a developer problem. So CEO, consider the idea to compensate well your employers. This also let you decide to do benefits according to the singular developer effort inside the team. Also don’t try to standardize the salary with role categories against each one developer capabilities. Developers are different, with different backgrounds and different motivation, mimic false fair because you are just not able to say “A is better than B so A deserve more money” marks the fact you are not the right person for the CEO role (decision maker first). Also bonuses must always be motivated in front of the entire team, for at least two reasons:
- You can be wrong, discussing with team on reason why A gain a +10% this month can lead to better knowing if A really deserve the bonus due to the reason you have in mind or not. (Again this request a NOT-FALSE-FAIR team, that is, in this blog post, assumed as pre requirement)
- In case you are right, this let other see the Cause-Effects of bonus strategy. Sound like dog training, i know, but it works in the same way. The dog catch the ball and bring it back, the dog got the biscuit
Otherwise you know what will happen, even the most motivated developer in the world just take apart quitting your company and move to a greener garden. It’s simply, it’s not about work itself, or something against you, it’s just the inner happiness mechanism described by Maslow that subconsciously demotivate your employer
Stillness or excessive dynamism
A not so easy balance to reach inside your team is finding the middle between stillness and dynamism.
Stillness is the feeling that time is passing and the decision are not taken, the event just flow away, and you are somehow try to chasing that without success. Developers in general are not meant to takes decisions, project managers do, but they easily feels if the project manager is doing his work properly or not. A developers should not takes care of what happens with the customers except for technical reason, so in the case you are a project manager, be transparent and try to handle your dev team with a constant flow. Variations from outside are always dangerous and lead to uncontrolled changes.
On the other hands we have the excessive dynamism that is the opposite way to react to the main project management problems (lacks of requirements, unrealistic deadlines, etc). The behavior of an over excited project manager usually starts with an excessive number of meeting, a progressive relaxation of the team norms and a degenerative flood of useless questions like “What is needed? How long does it take? How big is this problem?”. You got where’s the problem: you can shift responsibility over the developer. Developer can take your work, once, twice, but really, no more than three times in an year. If you are unable to manage a project ask your developer to do for you is not the solution, especially if the additional effort required is not payback (see previous paragraph)
A poor work environment
This is not a physical matter, e.g. place where it’s too loud, there’s no privacy, you get lots of interruptions etc.. This is also about your digital environment: slow builds, slow unit tests, slow desktops etc. They suck productivity and reduce enthusiasm. A bad environment can destroy motivation or at the very least be a distraction.
If there’s something that stop your developer flow for more than 10 minutes you must find out where’s the problem and fix it or ask someone to fix. Tools are made for speedup process not for slow it down, so if you are using SVN please be sure that all know how to use it, if you are super proud of your new compilers suite be sure that all developers know the new tools and how to use it, etc etc etc.
The best way to do that is to keep an internal document where all this information is stored (yeah, consider doing this even if you are a solo) and start delegate to someone the role of administrator. Delegate means explicit the new role request, don’t just ask him to “fix this please” or “look into this issue, there’s something that doesn’t work”. Be clear and explain always the issue and why it must be fix. If you are a developer you must point it out sooner all the situations that stop your workflow. A good work environment is a necessary requirement. Developer are by nature “programmed” for not wasting time so why force them doing…
Passive and Active Learn
Unless your work can be done by a robot, i’m sure you are learning something from your daily work. There are two way in doing this, the passive way, while you iterate over the project problems solving, and the active way that include the awareness of the learning process.
Active learning must be sponsored somehow from the company you work for. As Team Manager you must include in the weekly timing few times for active learning. Developers love to learn – new languages, new tools, new frameworks even if not required by upcoming project. Soon or later you’ll need this knowledge. Don’t be so fool, developers can just survive with passive learning, it’s like put a newbie on a plane and ask him to pilot it. It success only in films, in real time you crash at the ground. It’s the same with developers. You can put them on a project if they have not the knowledge to effort it, there a small effort you can ask to them on the learning curve, and in any case someone must know where’s the parachute before the project crashes.
Make it fan
Developers in general love to solve problems in a controlled environment – whether it’s how to integrate a new features, which algorithm is better for a given situation, etc ..
Know your developers and align the challenge to their attitudes, team will learn from others’ skills. Set a monthly challenge and reward the winner. This will force developers take part while they are working on main project, enhancing their multitasking skill, it is also a good chance to learn from different solutions. Review results leads to a wider consciousness of team members.
Let them be proud
Have you ever listen how your developer describe their work to third person (not skilled in IT)? Are they going to say something like “I’m working on the new revolutionary application for …. ” or are they say something like ” Uhh, to boring to explain … ”
Developer must be proud of what they are working on, only in this way they’ll fell the work they are doing as a personal grow, not only as the boss bank account work.
Choose your project wisely, mix developers attitude with needs, try to underline the thing to be proud within any project ,and ask developers to find it out and abstract from the single project. Shift and focus the attention to the important thing
As a conclusion i’d like to add an additional point: listen to your developers.
“When a developer speaks, someone should listen. When several developers are saying the same thing, someone should listen and act . . .quickly”
Test your motivation
Ok now you know my personal view on the topic, following now some boolean question (this give a turin taste to the test). Note down the number of positive answer, and check your motivation range.
A) Financial (5pt)
A1. Is your monthly salary equal to the global salary?
A2. Are your salary including benefits in percentage of company year revenues?
A3. Are lunch and/or dinner included in your contract?
A4. Is there any perks including local activities (Gym,Swimming Pool,Parties)?
A5. Are additional hard time tasks payed back?
B) Project Management (5pt)
B1. Did you rarely face lack of requirements ?
B2. Did you rarely face unrealistic deadlines?
B3. Did you rarely face shifts in deadlines ?
B4. You never take decision that someone else should takes.
B5. Nobody takes decision you must takes.
C) Work Enviroment (5pt)
C1. Company provides you hardware and software needed for daily development tasks.
C2. Do you have your private working space ?
C3. You are not interrupted during your dev phases.
C4. Surrounding environment is quiet enough for your needs.
C5. There’s enough coffee for developers need (believe me, this point value is really high).
D) Personal Motivation (5pt)
D1. I take part of something i’m pride of.
D2. I’m part of a team, and my ideas are taken seriously
D3. I learn in the last year at least two fundamental skills i’ll include in my resume
D4. I was encourage participating in community developer events (user groups, code camps), blogs (share links across the team), books (monthly bookshelf anyone?) and conferences.
D5. Chance to develop personal project within working hours.