If you have been asked the following question during an interview. What would be your answer?

You have only 2 weeks before the deadline to fix 500 bugs. Since there is no more other programmers available to join your team, your programmers will have no other choice than to work overtime, including 2 week-ends.

How do you convince your programmers to work that hard?

  • Provide the keys of your speech to your team.
  • Provide some concrete ideas to keep them they motivated during the week end.

I am particularly interested in what key points would you give in your speech

  • 3
    I would answer, "I'm the Project Manager; my responsibility is to accurately predict the probability of success. Motivation of line employees is the job of the line manager."
    – MCW
    May 23, 2014 at 14:46
  • 5
    I would fire the executives and stakeholders who allowed the timeline to slip that far out of tolerance despite effective communication from the team and the project manager.
    – Todd A. Jacobs
    May 24, 2014 at 22:19
  • I suppose they would get paid for that overtime? If so is the payment negotiable or pre-defined in their contracts?
    – drabsv
    Jun 8, 2014 at 20:07
  • If that is an interview question, I would probably ask if we can cut the interview short. I don't want to work in such a failed company.
    – nvoigt
    Sep 21, 2016 at 9:28
  • "your programmers will have no other choice than to work overtime" there is always a choice. Like applying at companies that are lead by professionals.
    – nvoigt
    Sep 21, 2016 at 9:29

5 Answers 5


I'll answer as if I was a project manager actually in that situation. I'm also going to assume you're looking at a normal sized project team (4-8 people) rather than a programme of work spanning multiple teams (and perhaps 50+ devs).

Being in a situation where you have 500 bugs to fix in two weeks is a sign of a project in failure mode. There's no easy way out from here but giving a nice speech and smashing hours of overtime at the problem is likely to make it worse not better as motivation will drop and quality will likely slip.

Steps I would take:

Question the date

Find out what the importance of the date is. Sometimes hard deadlines are unavoidable but these are pretty rare. Perhaps you need to demo a product at a trade show. There might be a product launch you had loads of press coverage on. Maybe you promised a client you'd have things fixed on a date.

Whatever the reason for the deadline, understand the importance and if possible, negotiate some extra time. Ultimately, make sure it's communicated to the team. No-one gets motivated if they don't understand why they're doing something.

Assess priority

I'd run a workshop to de-prioritise as many of the bugs as I can. Gather the stakeholders needed and either create a linear list or use something like the MOSCOW technique to get an idea of what is absolutely needed and what could slip.

It'll be pretty much impossible to actually motivate people to work overtime unless they absolutely buy into the importance of resolving them.

Estimate the work

Starting with the most important, estimate the work with the team to get an idea of scale. Stop estimating as soon as you have 3 weeks of work (or deadline +1 week if you couldn't arrange an extention). There's little point continuing to discuss past that point as there is little chance you'll deliver further.

At this point you can set an expectation with stakeholders about what is actually achievable. Commit to getting the stuff you estimated as possible in two weeks as things you will fix. Show the additional week of estimates - you'll do these if some of the others are easier than at first thought.

Set a reward

I'd avoid anything financial and I wouldn't tie it to delivery. Simply saying 'we know the next few weeks is going to be tough, we'll go for a meal out when we're done' is likely to feel better than if you do this then I'll give you that.


Once you've started the bug fix period, make sure you're communicating with the team about progress daily. If possible, have a dashboard visible to the team showing progress towards the goal. Sense of progress and achievement is likely to spur people on.

Keep stakeholders informed of progress daily too. Encourage them to thank the team regularly, particularly as the really important issues get fixed.

  • 1
    Great answer Ben! In terms of key speech points to the programming teams before the work begins, what would you recommend?
    – Kraken
    May 23, 2014 at 14:28
  • 5
    Importance of the date, value of the work, reward at the end. Honestly though, I'd avoid even talking about giving a speech. If the interviewer pressed me I'd ask if they can give me an example of a time where they've given a speech to a team in a similar situation and that worked to motive the team... a ballsy response which they'll either love or hate. If they hate it, I'd be rejected for the job; safe in the knowledge I wouldn't have wanted to work for a company who believe a speech is the answer to a motivation issue.
    – Ben
    May 23, 2014 at 14:48
  • 2
    Very much to me (as a programmer fixing those bugs) I love the second point "Assess Priority". This has to be the most important step here. If you say "all bugs are equally important" you probably couldn't motivate me to spend a single hour of voluntary overtime... It would show me you don't even know the bugs and haven't studied them. (Not even triaged) For reward, ice-cream party for all steakholders and in the office area on a working lunch is grand.
    – ebyrob
    May 28, 2014 at 16:16
  • PS - I'd make the ice-cream party a forgone conclusion... 1 ounce of ice-cream served per 3 bugs fixed. Of course, someone creative would make it logarithmic. (my wife would make consumption a requirement and instead of icecream it would be on fear factor unless all 500 were fixed...) Got to make rewards a bit quantitative...
    – ebyrob
    May 30, 2014 at 15:13

My answer would be that, if I had to come up with a speech and find ways to motivate them with only two weeks remaining to recover from this type of an issue, I am already too late and have already failed.

Building a high performing team starts at day one. Motivation for success is a symptom of a high performing team. If a high performing team was faced with such an issue, no speech or key motivating phrases would be required. The team would persevere, find solutions, create workarounds, support each other, and implement its best efforts to recover from this issue without any unique intervention from the PM.

  • Agreed. I'd come at this with the mindset of someone coming into the team at this point, not having been on the team for a while!
    – Ben
    May 23, 2014 at 17:49

This is a great interview question, because it tells you a lot about the company asking it.

In particular, it tells you you don't want to work there, which means you can answer, "Thanks, but no thanks," skip the rest of the interview, and go get some ice cream.

  • This is spot on. Great "oh, that's how you guys do things here" question and an easy out. Jun 10, 2014 at 19:12

First and foremost thing is to prioritize the task, set the time frame for every task, distribute the tasks among the team members. And last but not the least, motivate team members to work hard.


I would focus on making a speech as my main means for conveying the news. I would make a short notice instead and then discuss the challenge with every single member of the team in person.

Different people have different motivations, different productivity, different energy levels, etc and this must be taken into account. Plus, only in a private conversation do they have the opportunity to share their views and concerns in an adequate way.

Then I'd retire to think what would be the best solution for each person against the optimal solution for the present circumstances. Once I decide, I'd announce my final decision publicly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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