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?
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:
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.
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.
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.
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!
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.
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.
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 :)
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.
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.
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.
