I work for a small web company that deals with a lot of projects, a few at any given time are development heavy for us (400-1500 hours or more) and I've been noticing developers get extremely burnt out on a project after 150 hours or so.

I've been toying around with the idea of working some form of rotation/rest so when someone reaches the threshold, they at least get some time off of working on that project. Is there an industry standard approach?

  • Unclear--is each developer working on multiple projects at a time? How many hours a week are they actually working?
    – Matthew Flynn
    Commented Nov 28, 2011 at 22:59
  • 1
    40-45 hours a week, and most developers work on multiple projects at a time. Some however focus on one project for months.
    – Shawn Dalma
    Commented Nov 28, 2011 at 23:27
  • 2
    do the developers that work on multiple projects want to do that? Do the developers that work on single projects for months want to work like that? No one right thing as different folks like different things. When it matches = happier.
    – Michael Durrant
    Commented Nov 29, 2011 at 2:31
  • 2
    Sorry to have to ask this, but are people actually doing 40-45 hours a week, or are they just putting 40-45 hours a week on their timesheets? Also, are they being given the time to do their project well, or are they rushed into completing it by a deadline? Often feeling like you are having to cut corners can be demoralising. Finally, are people going straight from one 150 hour job to another without a break? Often getting the time to do a retrospective of a project can make the difference between feeling that the project was a bad one or just flawed.
    – Mark Booth
    Commented Nov 29, 2011 at 11:40
  • Are they working solo or in teams/pairs? If they work in teams or pairs, what keeps them from rotating between projects now? Commented Dec 1, 2011 at 2:51

11 Answers 11


In every point below I aim to provide usable options for "How can I avoid team burnout?"

Although there is often no single cause to this, given "extremely burnt out on a project after 150 hours or so.", I would look at all possible areas. Make it a "project" and present it up (mgmt) and down (team) to get both resources and buy-in.

I have found that burnout does not so much happen "at" a specific point and it varies from person to person. For some it's 300-400 hours. For others it's 1000-5000 or more as you note. Regardless of the hours, burnout builds over time and reflects many things.
Without knowing the specifics, from both yourself AND (confidentially - hah!) your staff I would suggest the following as areas to examine and focus on.
A lot of the things that can make a different are subtle intangibles - but they add up.
The following summary is what I have learned from decades of development and would need to be tailored to your company/budget:

The Team:

  • Listen First ! Ask your team. Ask again. Ask every week "what can I do to help you - it's my job!". Seek first to understand and then to be understood. :)

  • Be honest. Programmers, like most folks, can sniff out falseness quickly and it's a very demotivating !

  • Don't focus on hours (long or short) focus on dedication and output.

  • Encourage, reward and promote developers who want to use best practices.

  • Give developers as much autonomy as possible. Allow mistakes (sometimes) when not critical.

  • Give developers variety in the projects they are working on concurrently.

  • Provide general training. Developers need to continue improving skills in a variety of areas to stay current.

  • Provide specific training. Developers need the skills to do the specific tasks at hand, or they are forced to learn on the job, reducing the time to do the job (let alone well) which is frustrating and stressful.

  • Send developers to conferences in relevant technologies. They improve their skills and you can benefit. Developers are often much more willing to work on 'boring, burnout; stuff if they also get to attend a couple of fun conferences a year and other get other forms of training. Travel here is good too as it can be a cool benefit itself.

  • Address Technical Debt. Understand it and acknowledge it publicly with your tech team and with management when it exists. Spread knowledge about why it is bad and better practices to address and avoid it. Technical Debt can be very discouraging to your best developers.

  • Encourage a good attitude and lead by example. Go to training YOURSELF on better management.

  • Acknowledge, praise and encourage good work by your team.

  • Use humor (carefully, considering the people) to defuse tense and difficult situations.

The Workflow

  • If there is a lot of bureaucracy or slowness in the organization, avoid boredom by compensating for 'downtime' with a variety of other work, education, etc.

  • Developers working with Users sometimes have conflicts due to different perspectives and areas of expertise. Encourage greater communication to address this.

  • Use good tools for project/feature/bug tracking, e.g. Pivotal Tracker. Pick a tool that your team find easy and helpful to use. Agree on the usage patterns and appropriate naming, categorization of issues (severity, priority), etc.

  • Define the workflow with clear meetings, communications, messages, etc. Make sure everyone is on the 'same page' as to what the direction is. Don't assume they are.

  • Address issues with regular scheduled meetings and never assume that everything is ok.

The Technologies:

  • Provide quality equipment. Don't pay a developer 70,000 (or a lot more) and then skimp a few hundred dollars on equipment.

  • Give developers variety in the technologies they are using to keep them fresh.

  • Provide quality tools. Quality work by craftsmen and craftwomen requires quality tools, as with all industries. Give people tools they they find a pleasure to use. Not a pain and frustration.

  • Keep a constant supply of cool tools, technologies and toys. The kind of developers you may want often love this stuff more than $$$.

  • Encourage developers to specialize in technologies they are most interested in and enjoy.

  • Seek out and implement technologies that automate repetitive tasks such as running tests, building code stacks.

  • Use tools that report on code quality and use the output from these tools to be guide and help on making better quality code so the case for doing so doesn't have to just be a conversation, stats can be powerful.

The Things (Physical Environment):

  • Provide a great workplace that encourages developers to come into the office (still best for groups working together) rather than work remotely with:- coffee, snacks, juice and a cool environment.

  • Provide quality workstations and quality chairs. Provide the option of stand-up desks which some enjoy. Cardboard ones (that work) are available.

  • Provide a building and rooms with good a/c and heating. Make sure there are good window blinds and lighting for all.

  • Provide multiple big screens for each developer and a Big Visible Charts screen to show rotating images of key indicators (build successes, project tracker tickets, New Relic Report, Google Analytics on site visits, etc.

  • Encourage breaks. Find fun activities both team and inter-team (outside IS).

  • Respect people's habits. Some folks need peace and quiet sometimes. Others don't notice noise ever.

  • Examine the team makeup, is one member (even if competent technically) consistently 'toxic'?

  • If possible, locate the development team in a 'geek' friendly location.

  • Encourage healthy habits with gym membership, on-premise site showers (if possible) for exercisable commutes, healthy snacks (granola bars, fruit, healthy cereal, etc. as opposed to pizza, donuts, baked goods. If people want other stuff they can still buy it anyway!) Healthy body = healthy brain & less sick time.

  • Support local User Groups for the technologies you use. Items like this can be subtle but they are basically like image marketing - you buy pizzas for a local user group, or host a meeting, your company looks good and supportive and people feel better working there.

Final comment: realize omg this a full-time job with little time for development and run out with your hair on fire. Oh yes, comedy and a sense of humor help A LOT. Best Luck!

  • 1
    IMO, this is the only answer so far that actually addresses the question at hand by providing support and ideas for moving forward. Good job Michael.
    – Jordan
    Commented Nov 29, 2011 at 2:56
  • Mark, thank you for the formatting ! I would +1 that! Commented Nov 29, 2011 at 13:25
  • 4
    @Michael Durrant - No problem, it's a good answer so I was happy to spend a few moments making the formatting a little better. Plus, it got me a whole two rep. Whoopee. *8')
    – Mark Booth
    Commented Nov 29, 2011 at 17:10
  • 1
    Michael- Increadible answer. I've copied it down in my Tips and Tricks folder for repeated and heavy future use. Commented Jan 27, 2012 at 4:51
  • 1
    @Michael Durrant - (+1) This is a great answer Michael. It's focused on the actual problem and very well structure. Thanks for your input :D
    – M0N4K0
    Commented Jan 27, 2012 at 9:04

Some common reasons for this may be (one or more of the following):

  • Developers are not fluent enough in the technologies used and they spend time learning on the job, so they have to work more to deliver as expected

  • Lack of good analysis and lots of re-work

  • The customer keeps changing the requirements

  • Unrealistic goals/time set by Project Management or in the project plan

  • Lack of a process approach to development, tasks are not streamlined

  • Under utilization of good tools

  • Insufficient re-use of common code

  • Lack of focus, with 1 developer assigned several unrelated tasks

  • Unlimited overtime pay - The more you work, the more we pay you

  • Management insistence on compliance to standards such as CMM without providing time in the project plan for the documentation effort

Resolving some of the causes should improve the situation. Examination of each developer's case would also help.

  • I felt burnout creeping up on me just reading the first several bullet points!
    – John Fisher
    Commented Nov 28, 2011 at 23:32
  • @John Fisher, this was not my intention John... :)
    – Emmad Kareem
    Commented Nov 28, 2011 at 23:43
  • 3
    This question doesn't ask what the reasons are for team burn out, it asks for how to manage it. Do you have anything to say about that?
    – Mark Trapp
    Commented Nov 29, 2011 at 1:52
  • Indeed, while this is a nice analysis, it's not always as simple as "do the opposite" or "don't do this" when you're already in the situation, since you have to do work to get yourselves out of burnout.
    – Jordan
    Commented Nov 29, 2011 at 2:55
  • @MarkTrapp to be fair it asks how to avoid burnout. Surely identifying the causes of a problem is a key step to avoiding that problem.
    – Kirk Broadhurst
    Commented Nov 29, 2011 at 3:08

As many have said, 1 month of work is, is too soon to for one to get burnt out.

My guess is you have an issue with low morale. Not a "Burnout" one.

I can't even begin to guess why that is, but i think it is something you should look in to.

  • This question doesn't ask what the reasons are for team burn out, it asks for how to manage it. Do you have anything to say about that?
    – Mark Trapp
    Commented Nov 29, 2011 at 1:52
  • 2
    Yes, I don't think the team is burnt out.
    – Morons
    Commented Nov 29, 2011 at 2:05

People "burn out" because they're getting "burned." As others have said, if they're only pulling normal work weeks (40-45 hrs) during normal hours (not any forced third shift goofyness, which has proven health detriments), then you need to find what's missing.

Since you have many short-ish projects, I'd suggest something as simple as one milestone party (lunch catered in), and maybe a end-of-project party (again with catered food) and the Friday of that week off. Food is good- you'd be surprised how far a box of donuts every Friday morning will go towards morale. Basic human psychology- if you have a full belly of decent food you start your day a couple points happier :)

  • 6
    Donuts = decent food now?
    – Kirk Broadhurst
    Commented Nov 29, 2011 at 3:02

I did my MBA essay on burnout, especially with managers. I did my research with a questionnaire and statistics in an hospital.

My conclusion was that when in a work place the expectations are most of the time higher than what people can give, you create a work environnement that in short term becomes more and more stressful. That is evident.

Unnecessary stress becomes rapidly unproductive. You pay for sick leave benefits for example. That is very costly.

What helps a worker to avoid burnout is social support from the boss, co-workers + autonomy in the decision making. In other words, if your employees feel in charge of their situation (empowerment) you will avoid many burnout case.

But nowadays, many high level managers do not simply care about if an employee break down or not (you just have to replace him or her). But if you do a tight cost inquiry, you will always find out that, in long term, it is much more costly to manage that way. Also hiring and training employees is the most expensive task in an organisation.


Clearly I'm not familiar with your company or its environment and policies, so only the most general suggestions are possible.

I'm wondering if there are some motivators other than a nice environment and perks, and maybe demotivators beyond 150 hours. In a lot of companies, people are happy working on the same product for months on end and 45 hours doesn't seem abusive at all. So, maybe this ia a good time for some five-whys root cause analysis.

In the meantime:

Have you considered the motivators in Drive (Daniel Pink)? Do the developers feel like they're making progress, or just churning out product? Take a few minutes to check this video: http://www.youtube.com/watch?v=u6XAPnuFjJc See if it speaks to you.

Maybe if they were able to spend time retooling to make future projects easier and more fun?

In the way of removing demotivators, consider this list: http://www.cio.com/article/123406/Stop_Demotivating_Me_

Theory X managers in the past have considered burnout a sign that they're getting maximum work out their resources. I think it's great that you're aware of motivation and burnout and interested in doing something about it. Godspeed.


Ship code. Developers can feel like they're in one long gym session that only ends when their code hits real users and they can move on to the next task.

People feel more demotivated and even depressed (burnout is depression) when their labour appears to bear no fruit.


Depends on how many hours they do in a week. Overworking because of deadlines often leads in stress for the developers.

  • 2
    s/developers/people Commented Nov 28, 2011 at 23:08
  • 1
    While the original form of the question did ask in part whether it was normal, it's asking how to manage a team of burned out programmers. Do you have anything specifically to say about that? We're looking for more than whether or not something is normal.
    – Mark Trapp
    Commented Nov 29, 2011 at 1:53
  • Really diagree with this one. I love programming 100 hours a week. Yes even boring business software. However working 4 hours a week in a supermarket would quickly lead to 'burnout' after 2 or 3 weeks.
    – Michael Durrant
    Commented Nov 29, 2011 at 1:59
  • I'm not sure it's overwork. 40-45 sounds like the number of hours most developers desire. I suggest it's probably not the work week. Agile teams famously work very little overtime, but still it is done from time to time (softwarequalityconnection.com/2011/04/an-agile-pace). Commented Dec 1, 2011 at 2:45

If you have identified a pattern, you should probably follow up on it. Pre-emptive time off to prevent burnout is certainly a viable idea.

That said, 150 hours does seem to be a pretty short amount of time to start burning out, and 40-45 hours a week is not excessive, so you might want to examine what it is in your work conditions that is causing the burn-out. @Emmad Kareem suggests some good possibilities.

Go out and listen to what the developers are talking and/or complaining about--are there any patterns there as well? Are the ones who work multiple projects complaining about constant context switching? Is the management driving them nuts? Good, constructive communication is the best preventative for burn-out.


Try creating a standard process for the way things are done -both technically and workflow-wise.

This will increase their confidence in leadership (they'll see someone is steering the ship) and let them focus on doing their work/getting projects done rather than reinventing the wheel each time.

Also, improve the communication channels. Spend time talking with people. It lets them vent and you can learn ways to make their lives, and therefore your projects, better.

  • stop counting hours, hours don't matter, software does,
  • ship only software developers can be proud of,
  • don't buy into illusion of "people working on couple of things at the same time", context switching hurts and costs - I bet the developers who work on one project for longer periods of time are less complaining about "burn out".

Some great points about environment, gyms etc. above but key is: make sure people love the code they do. And don't drive them too hard for a couple of bucks more.

Your Answer

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