# Team Morale: Myths and Reality

Source: https://www.yegor256.com/2015/03/02/team-morale-myths-and-reality.html

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_]({% pst 2015/oct/2015-10-06-how-to-be-good-office-slave %}).
These traditional techniques turn employees into
speechless monkeys, programming under the influence of Prozac. Their existence
and [popularity]({% pst 2015/oct/2015-10-16-ridley-scott-and-joseph-goebbels %})
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]({% pst 2015/sep/2015-09-22-micromanagement %}).


{% jb_picture_body %}

**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]({% pst 2015/oct/2015-10-13-competition-without-rules %})
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.

{% youtube ibT5oKToMoQ %}

**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]({% pst 2015/may/2015-05-21-avoid-software-outsourcing-disaster %})
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.

{% quote 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]({% pst 2015/sep/2015-09-16-how-to-fire-someone-right %}) 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]({% pst 2016/may/2016-05-24-who-is-project-manager %})
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]({% pst 2016/jul/2016-07-11-mistakes-in-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]({% pst 2016/may/2016-05-24-who-is-project-manager %}).
Whether you succeed or fail, we all will see. Once you say we all have to succeed
[together]({% pst 2015/nov/2015-11-21-ringelmann-effect-vs-agile %}),
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.

{% youtube biE86esgFAE %}

**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]({% pst 2015/sep/2015-09-22-micromanagement %})
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]({% pst 2016/jul/2016-07-11-mistakes-in-agile-manifesto %})
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.

{% quote Give everybody an assurance that none of them will be terminated behind a closed door %}

**Don't Close the Door**.
Responsibility is personal,
[money]({% pst 2014/sep/2014-09-24-why-monetary-awards-dont-work %})
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]({% pst 2015/sep/2015-09-16-how-to-fire-someone-right %}) 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]({% pst 2015/oct/2015-10-13-competition-without-rules %})
of work that will define who gets what
when we succeed and who
[goes home]({% pst 2015/sep/2015-09-16-how-to-fire-someone-right %})
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]({% pst 2016/feb/2016-02-18-holacracy-autocracy %})
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.

{% quote Honesty is the best team morale booster %}

**Don't Rule; Make Rules and Plans**.
Nothing demotivates more than an unpredictable
[manager]({% pst 2016/may/2016-05-24-who-is-project-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.

{% quote 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]({% pst 2014/sep/2014-09-24-why-monetary-awards-dont-work %})
behind their monetary decisions. Instead of managing the money,
they let money manage them.