The Achilles Effect

There are professionals that excel in everything they do. Except for some stupid detail that ends up throwing away their performance. I usually call this lack of care for details “the Achilles effect”.

These are professionals with high technical capacity and nor ocasionally they are extremely important to the company. They are the type of professional that every manager likes to have on his/her team, like an ace in their sleeve. But often this ace ends up not doing things that would be extremely important for their own development or to bring a sense of order to their work.

The Story of Achilles

Everyone already knows the story of Achilles, recapping:

In Greek mythology, Achilles (/əˈkɪliːz/; Ancient Greek: Ἀχιλλεύς, Akhilleus, pronounced [akʰilːéu̯s]) was a Greek hero of the Trojan War and the central character and greatest warrior of Homer’s Iliad. His mother was the nymph Thetis, and his father, Peleus, was the king of the Myrmidons.

Achilles’ most notable feat during the Trojan War was the slaying of the Trojan hero Hector outside the gates of Troy. Although the death of Achilles is not presented in the Iliad, other sources concur that he was killed near the end of the Trojan War by Paris, who shot him in the heel with an arrow. Later legends (beginning with a poem by Statius in the 1st century AD) state that Achilles was invulnerable in all of his body except for his heel. Because of his death from a small wound in the heel, the term Achilles’ heel has come to mean a person’s point of weakness.

Source: Wikipedia.

The relevant version for this publication is those that state that Achilles was unbeatable, except for his heel. Achilles won the Trojan war from other heroes, but died there by an arrow thrown at random.

Achilles Death

In the versions that I like, Achilles had a stupid death.

I would say that Achilles’ problem was not having a point of vulnerability. Everyone has flaws and everyone knows, or should know, the price they pay for being who they are.

Achilles’ problem wasn’t that. His problem was the total neglect of a detail. He could have protected his heel. But he did not. In this case, the detail was rejecting his own limits. Had he diligently protected the only vulnerable part of his body, he wouldn’t be stupidly killed.

But how does that relates to a career?

The Achilles Effect

About career? How many times as professionals do people act like Achilles? One important comment in the code… Missing or avoiding that commit… Tagging a version, maybe? A manager who does not manage his team and leaves developers to work as they please… Although brilliant during the Trojan war, an arrow in the heel can kill figuratively be just like loosing a promotion or rendering an image of undisciplined…

One of the best examples of profile that suffers with the Achilles effect is antisocial engineering genius. He/She might even finish his/her tasks, but will avoid documenting it and months later no longer remembers what he/she did and has to do it all over again.

I know a history of a manager who refused to use the standard company versioning system. I also know that a crash on the workstation of one of his subordinates ruined one of his projects. He was fired after a while. If that had to do with it I do not know, but certainly that was of no help.

Developers and Achilles Effect

For developers, have only one advice: do pay attention to details. In Autodesenvolvimento para Desenvolvedores (my book, here), I made it clear that such details may result on being promoted or not. Examples of important details:

• Are reports up to date? Expenses, tests etc?
• Is the generated code well commented?
• The amount of interim solutions … Is it too big?
• Is the documentation updated?
• Did the developer think about what was made? Can he/she explain?

It is as they say, the beauty is in the details…

The results of the Achilles Effect

Developers should worry about this sort of thing in their careers. I can immediately think of some problems and obstacles that originates in this type of attitude:

• Fell to good to perform important parallel activities;
• Underestimate all activities (and end up working by the double);
• Low end quality (final touch) of performed tasks;
• Deterioration of professional image.

Dealing with Achilles

Unfortunately, the Achilles Effect is an evil that affects developers at an alarming rate. Even the best minds are capable of being dragged by it. But before I delve into it, there is an assessment of the area manager in which Achilles works should do.

First, discipline exists only if there is a definition of a set of rules. I often say that no one takes parking tickets in a lawless land.

Consideration this and assuming that the manager actually manages his team, what to do when there is a colleague or a subordinate working as Achilles?

There are some possible reasons why someone does not do something in a company. When it comes to Achilles Effect it is usually seen:

• Lack of Knowledge. The professional really does not know what is important.
• Rebellion. The professional does not perform some task to somehow call for attention.
• Ego. The professional judges he is too good to accomplish tasks that he judged inferior.
• Necessity. The professional had no choice and had to break a rule.
• Boycott. The professional deliberately chooses to not perform something to cause some damage to the company, his team or his boss.

Lack of Knowledge: walking blindfolded.

I’ll included lack of attention here.

In my years as a manager, I have seen people fail to meet their obligations under ignorance. It is natural: the individual does not do something because of not knowing what was needed. Therefore, treatment is the simplest: once detected that the subject does not do it on purpose, the first thing is to educate the individual that some activities are important.

It should also be explained to the individual that his attitudes can cause problems or throw away good opportunities. It is also important to raise awareness that, without meaning to, he can pass an image of rebel genius or mad scientist – none of them is good for the career, totally contrary to what many may think.

Usually, the thing improves by itself. If it don’t improve, it is good to follow up until the professional develops the habit of performing such tasks.

Rebellion: it is not always bad.

Why? Because rebellion is a manifestation, in a way, unfortunately childish, to draw attention. To prove to the (usually absent) manager that the employee is there and needs to be heard.

I know of cases of people trying to warn their boss about something that they realized was wrong and, unable to make their point to the managers themselves or the area manager that something should change, they decided to let go only to be summoned to a meeting of improvement, right after that.

Therefore, I recommend that a manager, when realizing that a committed and capable employee is acting strangely, should talk to him/her. Perhaps some important message has gone unnoticed… But there is a very important warning here: care must be taken for a boycott attitude posing as a rebel act.

Ego: most common reason among top performers.

To fix this behavior the first thing is to identify whether it is natural or whether it is deliberate. If not intentional, the professional thinks he is the best and thought that he could leave details aside, then some lecture is recomended. But I doubt this situation even exists.

If it becomes clear that the professional does it on purpose (something that is much more common) and if he is really good, the only argument is to make it clear to what is preventing him/her from growing on the career. He can enjoy rebel life if not contaminating others into that sort of thinking. Eventually, he will see others being promoted and, if he/her is indeed that smart, he/she will change their attitude. By himself/herself.

This behavior is rarely problematic when isolated: one does this simply to be able declare to others that he is the best and the professional assumes that he/she must not comply with any rule to prove it. However, egocentric professionals bring in with their package several other problems: these professionals are the worst to exchange information, they mistreat colleagues and therefore have to be really, really good to compensate for all this.

Unfortunately to them, they rarely compensate.

Need: the most rare and usually nonexistent explanation.

I have a theory: only those who know the rules can break them. And if people understand the rules, they will break it only when needed, something that will occur really rarely. I like this sentence of Freeman Dyson:

“A good scientist is a person with original ideas. The good is engineer a person who makes a design that works with the few ideas of the possible. There are no prima donnas in engineering.”

~Freeman Dyson

Normally when he/she does this, the developer will have a very valid reason to do so. He/she will also have consulted some colleagues to actually conclude that such a thing is necessary.

To be fair, a break of rules will only happen in places where, of course, there are rules. At least here in Brazil, few are the development sites on which development is made on true professional way…

Boycott: An unsolved problem

Finally, I’ve rarely witnessed  noncompliance with boycott objectives among developers. I have seen many people speak against directors, owners and shareholders, complaining of surplus value, that are “sucking the labor of others.” And even among those I did not see any behavior towards sabotage. I never see any reason for someone to boycott the company that pays his/her salary.

To make clear the difference between rebellion and boycott, I like the analogy: you can deny a ride to a friend that has done some wrong to you, but you would still save him/her if he/she were drowning.

In these cases, a good tip is to question the supposed rebel what could change. If he has something to say, great, they just wanted to draw attention. However, if he/she just wants to destroy, you will not know what to say. This type of person just really want is to draw attention, mutiny with no constructive purpose and, most often, syndicating colleagues to, ultimately, do no work at all.

The Role of the Manager

Each developer must evaluate to not end up contaminated by Achilles effect. I usually make it clear: each one is master of his own career. Still, the role of team manager is full featured to sanitize this problem, because even the best professional is influenced by the quality of the team he is part of.

A good analogy is a soccer player. He does not score against his team only because it is in a bad team. On the contrary. But without a good coach, he will not show its full potential.

The role of the manager is essential to eradicate the “Achilles effect” of a particular group. Healthy groups tend to naturally eliminate this type of situation. A manager must detect a department plagued by such a situation, which usually manifests itself in a general lack of motivation or a sudden drop in performance. The most common vaccines are:

• Definition of a Work Plan;
• Definition of a working method;
• Professionalization: eliminate people who only act when they want to;
• Removal of  anti-professional members;
• Getting to understand rebel elements – to be fair, usually these are the first to adopt any change proposed by the manager;
• Education for the unaware.

The manager who does not understand these manifestations are taking a big risk of being in a short term, with a bad team:

• The unaware remain unaware;
• Rebels or those who acted out of necessity (the good ones) will find another job;
• The Egocentric would either convert to rebels (and go away then) or may boycott the company (in this case, they might get offended “because no one recognized their greatness”);
• Boycotters are going to stay forever.

And so the manager ends with a lousy department under his command. After all, he/she will suffer himself/herself with the  Achilles Effect…

Like? How about paying with a like? Leave your comment!