Software developers aren’t motivated by impossible goals.
Developers want to work on technically interesting projects. They enjoy the mental challenge. They also want to collaborate with like-minded, knowledgeable engineers. Most of them are highly analytical and work in a world of simple logic. Keeping developers motivated isn’t all that complicated; they just want to be treated fairly. When they go through the effort of providing estimates, it’s an honest, time-consuming exercise involving the analysis of every requested feature.
If upper management ignores that estimate and demands the work happen faster, it puts the engineers in an impossible position. The estimate was, after all, not a commitment; there are too many unknowns in software development to predict schedules with perfect accuracy. And typically, due to changes in requirements or external difficulties, development usually takes longer than the initial estimate. So demanding that all of this happen in a much shorter amount of time makes it an impossible goal.
If the development team’s estimates do not agree with the work schedule dictated to them, the project will be in trouble. The team’s morale will be low as they adopt an adversarial relationship with management. And, of course, management will be blaming the developers for not achieving the impossible goals. This is highly dysfunctional as the role of management is to support the team, not drive them into no-win scenarios.
Similarly, developers aren’t impressed by motivational speeches. I’ve seen sales organizations where the CEO gives an inspiring speech, with the sales and marketing teams cheering him on. Plus, there are trophies handed out with awards for the best sales leaders. In some companies, the crowd takes on cult-like behavior. In such organizations, setting impossible goals might be viewed as a motivational attempt to get the team to accomplish the impossible. But for developers, this behavior is viewed as dishonest and overly stressful.
Ultimately, unreasonable schedules lead to delays in delivery. It also leads to reductions in functionality and lower quality, all of which must be addressed later in the year – impacting all future schedules. It’s a short-sighted, ignorant approach that veteran developers have seen at other, lower-performing companies. Remember, they left those places for a reason.