# Altruism Kills!
Source: https://www.yegor256.com/2019/12/24/altruism-kills.html
Altruism means selflessly giving others more than you take back, while egoism means
selfishly taking more than you return. Modern theories of management
and social life tell us that altruism means prosperity for the society
and success to the project. In my book
[_Code Ahead_](/code-ahead.html) I claim the opposite: altruism hurts the
society and kills projects.
I truly believe that any group activity eventually collapses if it
encourages altruistic behavior among its members, be it a project, a company,
or a family.
This is why one of the core principles of
Zerocracy is [#NoAltruism](https://www.youtube.com/watch?v=vXUwE3FGfpg).
{% jb_picture_body %}
Have you ever heard about the [Equity Theory](https://en.wikipedia.org/wiki/Equity_theory)?
J. Stacy Adams, the inventor of it, was sure that
"employees seek to maintain equity between the inputs that
they bring to a job and the outcomes that they receive from it
against the perceived inputs and outcomes of others."
In other words, we feel motivated to contribute only when we
know that we take back an _equal_ amount of benefits.
{% quote Modern leadership is not about giving and taking, but about sharing and helping? I don't buy this %}
You may say that [transactional management](https://en.wikipedia.org/wiki/Transactional_leadership)
is in the past and modern
teams are all about _transformational laissez-faire leadership_, where
we don't do primitive piecework trade, but rather
share common goals, ~~kiss~~ inspire each other, and
contribute enthusiastically. You may say that
modern leadership is not about giving and taking,
but about sharing and helping.
I don't buy this.
By the way, neither do Anders Skogstad et al. in their article
[_The Destructiveness of Laissez-Faire Leadership Behavior_](https://www.researchgate.net/publication/6547331_The_Destructiveness_of_Laissez-Faire_Leadership_Behavior)
where they call it a counterproductive leadership style
associated with a stressful environment characterized
by high levels of role stress and interpersonal conflicts;
nor do Abdul Qayyum Chaudhry et al. in their study
[_Impact of Transactional and Laissez Faire Leadership Style on Motivation_](https://www.semanticscholar.org/paper/Impact-of-Transactional-and-Laissez-Faire-Style-on-Chaudhry-Javed/d7b2d986581910b5e1ce44899353cb1a2cb656a9),
where they confirm that workers are more motivated in those banks
where transaction leadership style is used.
Neither does Gary Yukl in his critical article
[_An Evaluation of the Conceptual Weaknesses in Transformational and Charismatic Leadership Theories_](https://www.semanticscholar.org/paper/An-evaluation-of-conceptual-weaknesses-in-and-Yukl/15adc8f497ed75ef4468e2b202864b5443d3f9d3).
No matter what we call it, a transactional management or
an inspirational leadership, team work is always about an _exchange_ of
value: 1) team members give their time and skills, and 2) the team pays them back,
either with cash, or appreciation, or a good office atmosphere.
There are two possible extreme attitudes: 1) the _altruistic_ one, when programmers
contribute and expect absolutely nothing back, and 2) an _egoistic_ one, when
programmers don't contribute at all, but expect their salaries to grow
every year ~~(also known as software outsourcing)~~.
Ever heard about the Fail Fast vs Fail Safe dichotomy? It is
[well known](https://martinfowler.com/ieeeSoftware/failFast.pdf) that
any process survives better if it is designed to Fail Fast, revealing internal
problems as soon as possible, instead of being Fail Safe and concealing defects
in an attempt to survive. Even though Fail Fast feels more dangerous, it
leads to higher quality, no matter where we apply it, whether in management or
software design.
If the team doesn't reward its members correctly, they (according to the Equity
Theory) won't contribute properly. If the team doesn't reward correctly, it's
a defect in the system. Just like a bug in source code, this defect in
the motivational system can either be 1) concealed (Fail Safe) or 2) revealed (Fail Fast).
{% quote Encouraging team members to contribute altruistically means concealing management defects %}
Encouraging team members to contribute altruistically means concealing the defect.
Programmers will keep working, slowly losing their motivation over a long
period of time. The quality of the project will degrade and nobody will
understand why it's happening. The team will fall apart, losing its best
players one by one. They will burn out without even understanding why. Eventually,
the project will die for no obvious reason, while the key failure factor
was the inability to discover the defect due to the very
altruism of the programmers.
On the other hand, if every programmer acts egoistically and demands
the project to pay them more than they deserve, the business will feel
the problem very soon---simply by running out of money. Egoistic programmers
reveal the defect in the motivational system and make it necessary for
the business to fix it somehow. Either by introducing measurable KPIs,
or by making requirements more strict and demanding, or maybe by checking
the quality of work more attentively. Something will be done immediately,
in order to save the business from bankruptcy. And the measures which will
be taken will help the project to survive and become _stronger_.
Thus, by letting the team pay us less than we deserve, we kill the team.
On the other hand, by letting the team pay us more than we deserve,
we help the team understand its issues faster and, because of that, become
stronger and survive.
If you are a manager I have a suggestion for you. Fire those who are ready
to work overtime without any compensation. They are the trouble makers. Instead,
work with those who are not afraid of putting their own interests on the
table and demanding what's theirs. They will make you stronger, ... if you manage
to configure your project to deal with their demands correctly. If you don't,
you will lose the money, the project, and your reputation. But you will
learn something.
If you are a programmer, I guess you already understand what to do. Demand
as much as you can and deliver as little as possible. This is how you teach
your manager to manage projects and help the business understand and fix
problems faster.