There are plenty of books, articles, and blog posts about team morale. They will all suggest you do things like regular celebrations, team events, free lunches, pet-friendly offices, coffee machines, birthday presents, etc. All of these are instruments of concealed enslaving. These traditional techniques turn employees into speechless monkeys, programming under the influence of Prozac. Their existence and popularity is our big misfortune. Let me present my own vision of how team morale can be boosted on a software team—a team that has a good project manager.

Apocalypto (2006) by Mel Gibson

Fire Fast. The first and most important quality of a good manager is his or her ability to separate bad apples from good ones as soon as possible. Nothing will earn you more disrespect from your team than tolerance of under-performing team members. Your job as a manager is to help the best players play better, and they can’t play better if they see that management doesn’t understand the difference between excellence and mediocrity. It’s a severe demotivating factor.

Daily Stand-Up Meetings Are Evil (webinar #11); 3 February 2016.

Be Honest About Problems and Risks. Your team is following you and expecting you to be a smart manager. While they are writing Java, you’re talking to investors and customers. They want to be sure you know what you’re doing. The best way to show them you have no idea where the team is going is to tell them that the future is bright and cloudless. Everybody understands that’s either a lie and you are trying to hide risks or you’re stupid enough to not see them. In either case, the best people would attempt to quit before it’s too late. Thus, to keep morale up, regularly inform your people about problems you’re facing and risks you’re trying to prevent. They will appreciate it and respect you. A strong, professional manager deals with risks instead of ignoring them.

A strong manager isn’t afraid to look stupid in front of the team.

Failures Are Yours; Success Is Theirs. Always remember that when someone on your team makes a mistake, it is first of all your personal mistake. You hired that person, you trained him or her, you delegated the responsibility, and you controlled and monitored the job. Then he made a mistake, and the project lost money, disappointed a customer, or damaged the firm’s reputation. Of course you need to take necessary disciplinary actions and maybe fire the troublemaker. But first of all, you have to admit in front of everyone that it was your personal mistake. You didn’t control enough, you didn’t plan well, or you didn’t take preventive actions. This is what the team expects from you. Also, your people expect you to explain to them how you’re going to learn from this mistake in order to prevent a similar one from happening in the future. A strong manager isn’t afraid to look stupid in front of the team. A weak manager does look stupid when he or she tries to hide mistakes that have been made.

Responsibility Is Always Personal. The most demotivating word used in task descriptions is “together.” Don’t use it. Each task has to be personally and individually assigned (no matter what the Agile Manifesto says). Everybody is responsible for his or her own success or failure. How their results join together and lead to a mutual success or failure—that’s your business. Whether you succeed or fail, we all will see. Once you say we all have to succeed together, the team understands that you’re trying to shift responsibility from your own shoulders to theirs. It’s a sign of weakness, and you lose respect. Make tasks and goals strictly personal, and be prepared to be responsible for the group’s success. You, as a manager, break down an entire project into parts and delegate them to your people. If you do this job properly, we all will succeed. But don’t try to blame us if the parts fall apart.

Seven Enemies of Our Motivation (in Russian with English subtitles); 25 March 2017.

Don’t Mention Steve Jobs. Try to avoid global slogans and world domination speeches in the office and in front of the team. They demotivate. If we’re doing so good, why are our salaries not reflecting this success yet? If your vision is so global, why is it not yet implemented in reality? Don’t promise to become the next Steve Jobs. Instead, become the next good manager of a highly paid team that is solving interesting problems for real people. Your practical achievements, no matter how small and down-to-earth they are, will give you much more respect than many-hour-long speeches about our fantastic future.

Don’t Say a Word About Agile. Even though Agile is a great attitude-changing and mind-shifting concept, it is absolutely inapplicable in practice, mostly because it is too abstract. When you’re proclaiming in the office that we should value “working software over comprehensive documentation,” it sounds like you don’t know what you’re doing. The team doesn’t need such abstract slogans from you. It needs specific instructions and rules in order to follow them and produce results, money, and satisfaction. Agile is a set of abstract principles that you should understand and digest. But then, after you chew them properly, convert them to specific and very unambiguous rules of work. Don’t talk about Agile; be agile.

Give everybody an assurance that none of them will be terminated behind a closed door.

Don’t Close the Door. Responsibility is personal, money is personal, and results are personal. But their discussions should be open to everybody. Don’t close the door to that meeting room when you’re talking about problems or appraising someone’s results. You want your team to work together? Give everybody an assurance that none of them will be terminated behind a closed door. These pompous speeches about “us working together” usually turn into mush once the team sees that someone gets fired after a private conversation with a manager. Are we together, or is it you against us? To keep team morale up, you, as a manager, have to establish ground rules of work that will define who gets what when we succeed and who goes home first when we fail. These rules should be open to everybody. These rules should rule the team, not your personal decisions made behind a closed door.

Celebrate Achievements Instead of Birthdays. Team-building events are a great tool to boost team morale, but only when they are built around personal or team achievements instead of calendar events. A project team is not a group of friends or family members, even though some teams may feel like that. No matter how it feels, a team is here for one reason—to create the product and make money for its sponsor. This is the direction we’re going. Our goal is not to build a community and live together til the end of our days. Our goal is to achieve the business success of the product we’re developing, or in other words, complete the project. When the only events we’re celebrating are our birthdays, that’s a sign to us that our managers are trying to lie to us. They are pretending that we’re here to make a community of friends while in reality they are using us to build their business. It’s unhealthy and ruins team morale. Instead, celebrate achievements on your real path—to the success of the product under development. This will show everybody that you, as a manager, are honest with your people and ready to show them that their true role on the team is to develop a product and earn money for its investors. Honesty is the best team morale booster.

Honesty is the best team morale booster

Don’t Rule; Make Rules and Plans. Nothing demotivates more than an unpredictable manager. For the team, you are an abstraction of the entire world around the team. They see the reality through the prism of your personality. What you tell them about the reality is what they perceive. If you are unpredictable, the reality is unpredictable and scary for them. To avoid that, stop making decisions that are based on your personal and momentary judgment. Instead, make decisions that are based on the rules you’ve defined upfront and plans you’ve drawn beforehand. First, create a plan for team growth and announce it to everybody. The plan should include risks and their mitigation actions. The plan should say who will be fired first when or if the project goes down. The plan should give a predictable and measurable picture of the reality around your office. It should be a map of terrain you’re going to cross with your team. When it’s time to make a decision, everybody will understand why it’s made and will respect you as a manager who predicted the situation and managed it professionally.

Everybody should know everybody’s salaries, bonuses, and benefits.

Put Money on the Table. Discuss money openly and freely, right in the office, right in front of everybody. This advice is for true professionals. If you can’t do what is said above, don’t even try this one. But if you consider yourself a real pro in management and leadership, you should put money on the table and let everybody know who is getting what, when, why, and why not. Everybody should know everybody’s salaries, bonuses, benefits, and the rationale behind them. Each programmer should know what he or she should do in order to get a $5,000 raise to their annual salary. Also, he or she should know why a colleague is called “senior developer” while his or her title is still “junior.” This information should be public and printed on the wall right behind your chair. Why don’t most managers do this? Because they don’t have any rationale behind their monetary decisions. Instead of managing the money, they let money manage them.