I have a developer that is very important for an ongoing project planned to be finished Q2 2012. If he should decide to quit the whole project will be delayed and probably completed with lower quality.

I believe he is motivated but considering what is at stake I would like to give him something extra to motivate him and to make him stay.

The simple answer is a bonus when the project will finish but I would like to hear if someone has got other ideas or experiences from similar situations.


I think a bonus at the end of the project and perhaps smaller bonuses at major milestones progressing to the finish are reasonable mitigating actions.

However, I think your best mitigation to your threats of project delay and quality is to remove your single point of failure. To have this single point of failure where you rely on the heroic efforts of an individual or a few people is never acceptable and represents an immature project capability.

You have not done your job as PM if you have not set up an environment where everyone, including you, is replaceable. While I will likely get negative points for this, the cold, hard fact of being a manager/leader is that you can replace a person from his job with another as easily as replacing a part on an engine. Your soft skills, of course, will not make the person feel like that, but your hard skills says you can.

Your estimates, processes, and tools should be such that you can enable your capability with average to slightly above average performance by a human, because that is what you will most likely get. If those things require the superior performance of a human as you suggest, than your processes are broken. I'd fix that first before worrying about how to keep this guy on my project, if I were you.

  • +1 I would say:"preventation is better than cure"
    – Chris
    Jun 29 '11 at 13:06
  • Thanks for the response. I completely agree that everyone should be replaceable. In this case I don´t depend so much on a heroic effort as much as on knowledge, this is due to that the product manager has left and the other developers still are learning. We are a small company so my resources are limited. I expect that in 6-10 month the new product manager and 1 or 2 developers have enough knowledge but for the moment I am completely dependant on this single resource, therefore my question.
    – a2011
    Jun 29 '11 at 13:19
  • Yes, completely understand! Incent the guy to stay to a degree, but focus most of your limited, constrained resources on knowledge acquisition and mastery, i.e., fast track it. Jun 29 '11 at 13:30

I would like to provide addidtion support to the David answer, Motivation can never be a entry in Risk management plan and to be dependent on one resource might cost you heavy if that resource left the organization or may be not available due to health reasons. On the other hand, this could be the major threat to the project. As a PM, you can not be careless to ignore this risk and planning process is the right time to decide an alternate for the risk rather than seeking ways to motivate the resource.

But still if you want to motivate that particular resource there is no other policy works better than appreciation. Appreciate his/her work/creativity/task. Note that apprecation doesn't always mean to have a written mail communication/award, it could be a cup of coffee with the team member or may be by just keeping a big smile on your face and say him "you have done a fantastic job!"

  • Why do you say "Motivation can never be a entry in Risk management plan"? I can see huge risks around lack of motivation... is it because nobody can quantify the cost? (but I can qualify it...) Jul 4 '11 at 0:48
  • @Eric Willeke You are correct. It can be a huge risk and motivation should be there in the project. But I said it can not be a risk management plan, which doesn't mean that it should not be there at all. Lack of motivation or no motivation is, in my terms, known as dictatorship. Like Perry Wilson has mentioned in her answer about the smart strategy to motivate resources.
    – Chris
    Jul 4 '11 at 11:32
  • Why would you not put it in your risk management plan if it's a risk? Is this "a PMP thing" or otherwise written document? I've explicitly captured emotional and non-quantitative risks before and found it very useful in watching for symptoms appearing in the team and customers. "Customers lose trust in delivery cadence" is a common risk to discuss and mitigate on teams that are new to agile, for example. Jul 4 '11 at 19:55
  • I should not include that in the risk management plan because I count them in general practice, like every other thing which a project manager should do. Just like decent sense of accountability by PM can reduce risk factor but do we really need to include them in risk management plan for us or we should make it as a practice because that's what our job is all about.
    – Chris
    Jul 5 '11 at 6:40

One thing to think about - people are motivated by many things. Hertzberg theory states that money is not a satisfier. People will be motivated by money for only a short period. My suggestion is to ask the person what makes them interesting in staying on a long term project. Whatever they answer will give you an idea of how to motivate them. In the long run people move around and you need to have a fall back plan if this person leaves - what if they win a million dollars, you probably can't compete with that.

Another thought is that by giving a preemptive bonus to this employee, you may end up losing more of your team because they don't think you value them. You should be trying to answer this question for all the team members.


What Chris said: Appreciation.

And David, too: Ease your dependence.

And this: Ask, frequently, "What do you need from me? How can I help?"

Finally, if it seems appropriate: Put your engineer into contact with the actual people who will most directly benefit from the work. Nothing motivates me so much as knowing that some real person will benefit in some tangible way from the work I am doing. (But not everyone is as motivated by that as I am. And not every engineer plays well with users and customers. So: "if it seems appropriate.")


I think this is a really neat video that hits home to the point of motivation: http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=related

  • This is the real answer: I wish I could give it 50 up votes. Jun 29 '11 at 18:35
  • 1
    Video is great and is consistent with many studies about motivation; however, the scenario written by the OP is not about this type of motivation. The issue is not about his increasing his productivity or efficiency. Sounds like he is already a high producer. It is about his staying on the job. This comes down to a negotiated agreement, not about intrinsic motivators...IMHO. Jun 29 '11 at 21:56

One option you have to increase his job satisfaction is to reduce any distractions that are impacting his day to day work. It can be seen as a form of appreciation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.