Hygiene factors are the basic conditions a worker needs to work effectively. At best, hygiene factors create no dissatisfaction. At worst, their absence creates dissatisfaction. Adequate lighting is a hygiene factor because if adequate lighting is not present, the worker's ability to work effectively is impaired, and that hurts motivation. But adding extra lighting beyond a certain point does nothing to improve motivation. Good developers tend to gravitate toward organizations that provide work environments in which they can be productive—environments that meet their hygiene needs.

Here is a list of hygiene factors for software developers:

Aside from not meeting a hygiene factor adequately, management can damage morale in other ways.

Management manipulation. Developers are sensitive to being manipulated by management. Developers tend to deal with issues head-on, and they want management to deal with developers in a straightforward manner.

A few managers try to manipulate developers by setting phony deadlines, and most developers can smell a phony deadline 100 yards away. Management says, "We really, really have to have this project done by the end of the year." The developers say, "That sounds ambitious. If we really, really have to have it done by the end of the year, what features can we cut if we get into trouble?" Management says, "We need to keep all the features intact. We can't cut any of them." Development says, "Yeah, but what if we start to run out of time and we don't have any other choice but to cut features to make the schedule? What features should we cut then?" Management hems and haws and says, "We don't have a choice. You need to deliver all the features, and you need to deliver them by year-end."

Any particular manager might have good reasons to ask for such a deadline without giving a full explanation. Lower-level managers might not understand the reasons for deadlines they've been handed from someone higher up. The company might need to time a product's release in preparation for a public stock offering, and management might be legally restricted from explaining all the details. But answers like the ones described above appear to be evasive and manipulative—and developers respond poorly to that.

Barring extenuating circumstances, any manager who asks developers to commit to extra work on a project owes them a straight explanation. In Case Study: A Disheartening Lunch with the Boss, why did the boss move the deadline up 3 months? He didn't say. It seemed like he was moving it up just for the sake of moving it up. Managers who find themselves forced not to provide details about why a deadline is important should bear in mind that developers will probably find their explanations to be demotivating.

Excessive schedule pressure. If the deadline is real, it still might not be realistic. One of the quickest ways to drop motivation to zero is to present developers with an impossible deadline. Few people will work hard to meet a deadline they know is impossible, especially if they are MBTI type Ts (those who respond to logic more than to emotion).

Lack of appreciation for development's efforts. Ken Whitaker described a meeting his software-development team had with his organization's marketing branch. Here's what the marketing representative said at their meeting: "Marketing never gets off the hook! Why don't you give development half of the action items we get? Let's get products out dramatically faster—we all know that development `sandbags' its schedules…."

Whitaker comments that "[The developers] knew how to deliver software products to market and had established an outstanding track record in doing just that—delivering. There was no sandbagging. Development made incredible efforts to deliver on marketing's expected and (sometimes) unrealistic delivery schedule. In fact, we all thought we were part of a great team" (Whitaker 1994).

I think this is a common dynamic—people don't see how much work developers are doing, so they don't think they're doing much and therefore must be sandbagging. In reality, developers are extremely self-motivated, work long and hard hours, and find being accused of "loafing" to be very demotivating. If you want your developers to do more than merely show up at the office, never, ever tell them they're not working hard when they are.

Inappropriate involvement of technically inept management. Developers can be motivated by technically inept managers as long as those managers recognize that they are technically inept and confine their control of the project to nontechnical decisions. If they try to meddle in technical decisions that they don't understand, they will become the butt of the development team's jokes, and most people can't be motivated by someone they don't respect. The nontechnical manager in Case Study: A Disheartening Lunch with the Boss made a serious mistake when he ordered the development team to "cut the fluff" from its design.

Not involving developers in decisions that affect them. Not involving developers in decisions that affect them creates the impression that the manager either doesn't care about the development team or that management doesn't respect them enough to want their contributions. Here are some classic cases in which management must involve developers if it wants to keep their motivation high:

If you are a manager, you might find it necessary to make the commitment or the change described in each of the above cases. As a manager, you have a right to do that. You also have a right to drive the motivation of your team to zero. If you want to drive motivation to less than zero, try soliciting the team's input to whitewash a decision after you've already made it. That combination of failure to involve developers and manipulation is especially demotivating. If you want to keep motivation high, involve the development team in the decision before you make the commitment or agree to the change.

Productivity barriers. If the environment is set up in a way that thwarts developers' best efforts to be productive, you can be quite sure that their motivation will suffer. Try to remove productivity roadblocks so that your team can focus on the work rather than on overcoming distractions.

Low quality. Developers derive some of their self-esteem from the products they develop. If they develop a high-quality product, they feel good. If they develop a low-quality product, they don't feel as good. For a developer to be motivated by pride of ownership, there has to be ownership of the work, and there has to be pride in the work. A few developers can take pride in their response to the challenge of developing a low-quality product in the shortest possible time. But most developers are motivated more by quality than by sheer output.

If you as the manager insist that your developers shortchange quality in order to meet a tight schedule, you remove both halves of the pride-of-ownership motivator. You remove the pride, because the developers will not be proud of a low-quality product, and you remove the ownership, because you (rather than they) are making the decision to shortchange quality. With a low-quality product, some developers will feel terrible even if they meet their deadlines and receive bonuses.

If you feel that your developers won't be able to build a high-quality product in the time available, let the developers come to that conclusion themselves. They might choose to design a less-demanding product, or they might choose to develop a lower-quality product in the desired time frame. Regardless of what they decide, it won't do you any good to try to force them to develop a low-quality product. That's kick-in-the-pants motivation, and it doesn't work.

Heavy-handed motivation campaigns. With posters, slogans, pep talks, and other rah-rah! motivational practices, it's easier to insult developers' intelligence than it is to motivate them. With software developers, a light touch works best.