Two Peas in a (Dysfunctional) Pod

I’m a developer by trade and although I’ve been known to refactor code quite a bit, this tendency is somewhat self-limiting in my day job because of hard deadlines and the more concrete nature of “it’s done” as it applies to code. I don’t want to flop down on a blog version of a psychiatrist’s couch and rattle off why I’m like this, but suffice it to say that most of this behavior stems from being a perfectionist–I’m afraid that I didn’t get the work quite right or it could be better. Anxiety is the fuel that drives this crazy train.

After I “completed” my post about a certain style of bad management, I realized I had some related content that I could have included.

Uh-oh.

One of the most effective forms of treatment for anxiety-related disorders like phobias and OCD (and runaway perfectionism) is exposure therapy, e.g., treating arachnophobia by having someone drop a wolf spider across your upturned, softly-moaning face. So, rather than go back and edit my other post, I’ve decided to not touch it and simply create a new post.

Wait, is that something crawling on my face?

Deep breath.

I must not fear. Fear is the mind-killer. Fear is the little-death that brings total post revision.

OK, so most people agree: numbers are interesting.

What, you don’t agree? Give me a moment and you might think this one is.

The 80/20 Rule

This is a shorthand term for the idea that in any given work environment, 20% of the people do 80% of the work. In most of the places I’ve worked–and in most of the places my friends and other coworkers have worked–this has almost always been true. Now, before the fighting starts about who’s in the 20% group (and, trust me, you might not want to be in that group), let me hit you with a fact I didn’t know:

This “rule” has a more formal name: The Pareto Principle (not to be confused with Janet Jackson’s The Pleasure Principle).

The Pareto Principle

An Italian economist named Vilfredo Pareto first noticed the 80/20 connection as it related to land ownership in Italy where 20% of the population owned 80% of the land (see Wikipedia article). Later, management consultant Joseph M. Juran named the principle after Pareto and extended it to state that for a wide variety of subjects–not just Tuscan land barons and electronic sweatshops–around 80% of the effects come from 20% of the causes. There’s even a Pareto distribution in the field of mathematics that shows that the rule holds for many natural phenomena. That is extremely interesting.

I’d like to focus on the Pareto Principle as it relates to work distribution and task assignment in a development environment; specifically, what might be the cause of its expression in that environment?

(Note: there’s a second association of the 80/20 rule in computer science/application development, namely, that 20% of the code contains 80% of the bugs, but that’s another post.)

I’m going to put on my gently-used lab coat and describe what I think is the primary cause of this phenomenon while cleverly interleaving the second “P” from the post title:

The Peter Principle

Again, from Wikipedia:

The Peter principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to their “level of incompetence”. In other words, an employee is promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.

The book that popularized the idea, The Peter Principle, was written in the late sixties by Peter and Raymond Hull.

Since that time, corporate jobs have become much less stable as a career platform and the Japanese concept of a salaryman–where an employee’s entire career is devoted to a single company hierarchy–is pretty much non-existent today. But the principle also covers the case of an individual in one field being hired by another company into a higher position in the same or different field due to the employee’s previous success (or perceived success). The salient point is the individual has still risen into a position in which they are not fully competent.

So what typically happens when this occurs with a management hire; that is, someone who is responsible for coordinating the work within a team?

If higher management does anything, it typically involves simply transferring the employee around the company rather than demoting them into a position where they could be competent (an action hilariously named an inverse promotion). This creates some breathing room during the employee’s settling-in period when expectations are low, but usually upper management turns a blind eye to these situations. To do otherwise and attempt to correct the hiring decision risks having to admit that anyone involved may have been guilty of one or more of the following:

1. They were too non-technical themselves to judge the actual ability of the applicant.
2. (Related to the above.) They were bamboozled by the applicant’s technical jargon and sales blurb-speak and couldn’t detect when the applicant lied about exaggerated their abilities.
3. They didn’t care, i.e. they were asleep at the wheel and/or they just wanted to fill the position.

Additionally, the hiring process itself may be broken or inadequate.

None of these choices are good and no one is going to want to own them. The new manager also typically isn’t going to announce their incompetence and potentially give up the higher salary, company car, golden toilet, etc. So, who pays?

Arguably, the company and its customers, but the people who really feel the brunt of this manager’s skills gap are the direct reports. The manager–who has no idea what to do and is in survival mode–is going to quickly determine who the heavy hitters are on the team and attach themselves to those individuals like a tick.

And there we have it. The manager is not going to heavily task technical lower-performers because they would take longer to finish the work and the manager might have to provide direction, which they can’t. They also desperately want to be able to report that tasks are complete (and sustain the illusion that they were an effective hire). The best way to accomplish this is to overly-task the higher-performers. These employees may complain, but their work ethic and/or desire to maintain their reputations will compel them to finish the tasks.

And that is why the 80/20 rule is in full effect in most development environments.

Wait, is that something crawling on my face?

© mylevel4cache.com, 2019. Unauthorized use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to mylevel4cache.com with appropriate and specific direction to the original content.