The Four Hundred

After writing the article on burnout a few weeks ago, several readers requested additional information on what managers and team leaders can do to minimize the effects of burnout on their organizations. Readers confirmed what the research cited in my article suggests: that burnout is widespread and is getting worse.

"We deal with it every day," one reader confided. Her experience mirrored that of others, who generally affirmed that, as budgets and organizations shrink, staffers are being asked to produce more with less. As a result, many organizations in the IT community are becoming frayed, tired, and discouraged.

It's hard to solve a problem that no one is encouraged to talk about. Given widespread economic uncertainty and growing unemployment, what possible motivation would an employee have to broadcast the fact that he is progressing through the stages of burnout? Few companies have either the resources or the inclination to address the problem. Burnout is considered regrettable, but is accepted as the business world's version of collateral damage. From an employee's perspective, exhaustion and waning interest usually result in poor performance reviews. And for companies lacking formal remedies, the solution to the problem of a burned-out programmer is, as one reader elegantly put it, to "hire a fresh one."

Given the many enlightened reforms in the treatment of employees, it is curious that burnout is still viewed primarily as a private, rather than a systemic, issue. But, clearly, if burnout is prevalent in an organization, both structural and process problems exist that must be addressed by management. Unfortunately, top managers are often themselves dedicated workaholics who view burnout as a personal failing. And if the problem is not perceived as being systemic, the company can feel absolved of responsibility for the well-being of its employees and can ignore the need to examine its practices. For the most part, our treatment of those who suffer burnout is a cheerless validation of the axiom that the more things change, the more they remain the same. Consider the policy exercised by the pharaohs of ancient Egypt, who used slaves to construct their after-life housing: Work till you drop, then we'll replace you.

Employees fearing for their jobs will understandably be reluctant to discuss their degree of personal depletion, but simply initiating such a discussion will have a profound impact on the system. Getting honest about what's going on will relieve pressure building inside the system and will provide a road map for remedy. A good place for managers or team leaders to start is to disclose their own experience. If your team is suffering the effects of burnout, you probably are, too. Self-disclosure makes it safe for others to speak and lets them know they are not alone.

Convene a meeting (preferably away from ringing phones and other persistent work pressures), express your concerns, and invite your staff to share their experiences. Ask your employees what they need and want, to manage and lessen their stress levels. Be realistic about what you can provide, and follow through with your commitments.

All of this assumes you have a good rapport with your staff. If not--if people are reluctant to open up to you--it may be prudent to bring in an outside facilitator and allow your staff to meet privately. Often, anonymous sharing, in a safe, consequence-free environment, will produce powerful and useful information on which a manager can act.

If the objective is to minimize the pressure and overload within an organization, there are several things under an IT manager's influence and control that can eliminate unnecessary work. I touched on a number of them in an article I wrote three years ago, and they are worth revisiting.

Much of the stress experienced by IT personnel is a result of unrealistic scheduling. I've seldom heard the word "schedule" in a development context when it wasn't preceded by the modifier "aggressive." There is a macho business ethic that doesn't tolerate things being easy. You can't just compete, you have to crush the competition, so it would be an admission of wimpiness to advocate for "realistic" schedules. But in my experience, the number-one reason why projects fail, why programming managers lose their jobs, why programmers quit theirs, why users gripe, and why IT personnel experience burnout is the imposition of unrealistic schedules.

The requirement that people work harder and longer hours is often a poorly disguised attempt to compensate for reckless expectations created by untenable deadlines. If individual heroics are the default substitute for sensible scheduling, reexamine your department's criteria for making commitments.

Avoid assigning tasks to your staff until each member has bought into the implementation schedule. It is cruel and counterproductive to force an unrealistic schedule on your team, then put them in the position of being targets of criticism and discontent when deadlines slip or work is shoddy. The feeling that your efforts are never good enough, and that more is always being demanded of you, contributes to both emotional and intellectual burnout.

Part of your job as a manager or a team leader is to give upper management a reality check on what is possible and what is not. There should be no conflict between the welfare of your employees and the welfare of the company.

One of the best ways to de-stress software development projects is to create rigorous specification standards. The more clarity and detail you build into the design specifications, the greater the probability of a successful and timely implementation, and the less stress on your staff. This becomes doubly important in a distributed environment, where distance imposes its own discipline on application design and development. But the degree to which any project relies on continuous direct communication as a remedy for lack of design precision is the degree to which the development process will be frustrating and exhausting for all concerned. As in manufacturing, the more quality built into the front end of the process, the less rework required. Constant rework and maintenance are draining and contribute greatly to mental fatigue.

As a project manager, beware of feature creep, which adds to the workload and increases frustration. Like the military's nightmare of mission creep, feature creep can make short projects long, and long projects endless. While most projects continue evolving beyond the requirements phase as users begin to fully explore the possible uses of their new system, excessive requests for new features should be handled as change orders, outside the scope of the main project. Feature creep is a schedule buster and the main reason projects drag on into the unproductive terrain of waning interest and dwindling commitment, the domain of intellectual burnout.

Another source of exhaustion for IT employees is technology overload. Everyone associated with IT rides a technology roller coaster that never slows. New hardware, new operating systems, new programming languages, and new development tools all come at a dizzying pace. Yesterday's experts become tomorrow's novices, and playing constant catch up can be exhausting. Although the process of vocational death and rebirth can also be engaging and exciting, over time it will become draining without periods of rest. If members of your staff are resistant to new projects that require learning fresh skills, they may simply be saturated. If possible, allow overloaded employees to rest and regroup by assigning them less demanding tasks.

Sometimes pressure comes from the outside, and a good manager will protect his staff from political fallout. Mistakes happen especially when people work beyond exhaustion. User complaints and top-management displeasure is prevented by agreeing to do only what is reasonable and prudent, given the size and strength of your team. If, as a manager, you've agreed to deliver the undeliverable, you should assume full accountability and ownership of the outcome.

It is easy to get swallowed up by the crisis of the moment and lose perspective. When external pressures mount, programmers are too often sacrificed on the altar of today's disaster. Habitually working dedicated people to exhaustion is a clear indication of systemic problems. Individual sacrifice should not become the answer to every crisis. Problems occur in context. If your staff is constantly fighting fires, you have a process problem. Employees are not empowered to create or change a process; they simply thrive or fail within established structures. Only management can change a process, and fighting for appropriate changes that support the staff to succeed, and not to fail, is an IT manager's responsibility. Employees, however, are a great source of information about what's working and what isn't. Ask them.

There are many small things you can do to de-stress your staff. A hospital I've worked with hires local massage therapists to make available 15-minute chair massages to all of its employees. Employees come on breaks or during their lunch hour and enjoy the relaxation benefits of a shoulder-and-neck massage.

Another company, where overtime is prevalent, makes sure that everyone gets to go home at five o'clock at least two days a week. Still another provides time during the workday for its employees to exercise. Learning simple breathing techniques, and slowing down to breathe deeply a few times each day, can be a powerful relaxation tool. Anyone who is chronically tired is almost guaranteed not to be breathing properly. Proper breathing is to the inside of the body what massage is to the outside.

The idea is to change state, to stop what you are doing and do something that is pleasurable and relaxing. Stretch, go for a walk, close your eyes for a few minutes, surf the Internet--anything that provides a pleasurable alternative to the things that are stressing you.

Finally, realize that, although work is inevitable, burnout is optional. Perhaps the most powerful burnout preventative is also the most simple. Anyone can use it when they are feeling overloaded, though it takes some courage, because it requires setting a clear boundary.

Listen politely to all of the unreasonable requests, the unrealistic deadlines, the untenable projects, the increases in workload. And then say no.