The Inverse Peter Principle

This article was first published in DATAMATION, April, 1974, page 123, 125. Although this article appeared in an April issue, which traditionally contained some humorous articles, this article is very astute and critical of upper echelon management in a tongue in cheek way. My experience as a systems programmer, software engineer in factory automation, chief engineer of a computer company and finally consultant have given me much insight and I have seen many cases where the Inverse Peter Principle applies. Since I cannot find the article in the internet today, I feel its humour and wisdom should not be lost on today’s “doers”.

The Inverse Peter Principle

A. Nonymous

AFTER READING The Peter Principle and its sequel The Peter Prescription it has occurred to me that Dr. Peter, astute though he undoubtedly is, got the whole process backward when he stated that an employee starts off competent, then rises through promotion to a position where he is not competent to perform his job. I have found that more often than not, the very opposite happens: those employees who demonstrate competence in performing menial technical tasks tend to remain at the bottom performing those tasks, since it is in the company’s interest to make sure those basic functions are performed with as little fuss and retraining of newcomers as possible.

Conversely, those who enter at the bottom and soon demonstrate an inability to perform their assigned routine tasks are promoted upward in hopes that they will make a greater contribution as supervisors, coordinators, administrators, and the like. In short, having failed as specialists, they become generalists. It would be satisfying to complete the reverse analogy with the Peter Principle by concluding that most such people go from a level of incompetence to one of competence, but I cannot in good conscience say that. What happens is that they move from a level where their incompetence is glaring to one where it is not so obvious. (It is more difficult to prove a generalist wrong than a detail man.) So we might formulate our “anti-Peter Principle” thus:

  • Incompetents rise to a level where their deficiencies are no longer obvious, while those who are truly competent at the bottom tend to stay there. 

Let me illustrate this revolutionary thesis with a hypothetical example, supported by three actual case histories, of how this applies to the field of data processing.

Hypothetical dp example

Back in the good old days, when jobs in data processing were plentiful, the typical career path went something like this:

  1. New college graduate enters dp field as a programmer-trainee. After six weeks of bits and bytes he is turned loose to write a program. At this point our hero learns his first great truth: programming is a hard way to make a living. It requires ingenuity, analytical ability, infinite patience and a high tolerance for frustration. His first project is over-budget, late, and won’t run right more than once in a row. Our hero decides to change jobs.

  2. Realizing his incompetence at programming, our hero decides to advertise himself as a systems analyst. (Our hero is no dummy; he is merely no good at programming.) After all, systems analysts have more prestige than programmers and are paid better. Also since no one really knows what systems analysts are supposed to know or do, or even what, exactly, systems analysis is, it is harder to spot an incompetent systems analyst than an incompetent programmer. Also it takes longer. Therefore an incompetent systems analyst can survive longer at higher pay with greater prestige than an incompetent programmer. Our hero needs only common sense and one or two disasters in programming to discover this. Eventually, though, after several years of “designing systems” a pattern begins to emerge. Our hero has a habit of designing systems no one can use, that are expensive to run (when they are run), and which need a full-time maintenance programmer to keep “up.” Time for the next “promotion.”

  3. Two possibilities present themselves:
    • go technical and become a “consultant”
    • go administrative and become a “manager”

    In either case, all that is required is a jazzed-up resume stating the glories (in the most obscure jargon, acronyms and abbreviations) of past systems he “designed” (technical side) or the number of “project teams” he managed (managerial side).

From here on, a curious phenomenon takes place: our hero, no matter how inept, will be protected by the “system”. Specifically, he will continue to rise, in spite of his incapability to do anything right, because those who hired/promoted him in the first place must vindicate their judgment by continuing the charade and heaping rewards on our hero. This is sometimes referred to as “promoting from with-in”. Sometimes it is called “career pathing”. Sometimes it is called throwing good money after bad.

In any case, once the manager/consultant level is reached, our hero is protected by the very strong self-perpetuating, self-preserving instincts of the upper-echelon hierarchy. It takes a major disaster of practically national proportions to reveal incompetence at this high level. Our hero started at the bottom as an incompetent programmer and simply kept rising until he came to rest at a level where the job requirements were so general that his incompetence all but disappeared from view. He did not become more competent but appeared to do so due to the changing nature of his job.

Case history number one

Jane Doe (name fictitious) was a competent programmer. She wrote programs which not only ran when they were told to, they could be understood, and (due to their modular design) could even be modified by other programmers. Jane was so unusual in her group that her supervisor realized his job would be in jeopardy if she stopped writing programs (for one reason or another). To keep Jane reasonably happy, instead of promoting her, he gave her annual salary increments until she was at the top of her “salary bracket”. It was not in her company’s interest to promote her because she was too valuable to be given a teaching assignment to train others in her skills. It was not even in her own interests to be promoted, since she would have to take a cut in salary to enter the next salary bracket in the middle, where everyone else did. She could not quit, of course, for the same reason: she was grossly overpaid for the job-level she was at. So there Jane stayed until the last 370 was shovelled out the door in favor of the new IBM 390/225 TVM, a totally virtual machine. Jane had never been sprung from her programming-tasks long enough to learn the ins and outs of programming for totally virtual machines. At this point she was early-retired at the age of 43 at 10% of her annual salary averaged over the preceding five years.

Case history number two

John Doe (no relation to Jane) was a medium-competent programmer, but, having more moxie than Jane, threatened to go elsewhere for a twenty percent raise (this was 1968) if he was not promoted to project supervisor. In this position he functioned rather well; he was highly motivated, and just arrogant enough to press those under him to get his first project out on time and under budget! Being highly motivated he was now ready for a quick second promotion to programming manager. But as luck would have it, the clients were so pleased with the new system they funded a second project, to add certain “enhancements” to the original system, but only on condition that John be project supervisor (again).

John did not like the prospect of sitting in the same old job for possibly another six months, but he had established a reputation as a “doer”, and it would be silly to go elsewhere and start again from scratch. Also he might not be so lucky a second time. So John stayed on and built on his reputation of competence. He delivered the “enhancements” on time again, using the same competent programming team, naturally. After this “follow-on” project came another “follow-on” project to soup up the system still further. In the end, the client was so pleased with John’s handling of the follow-on projects that he requested that John become permanent client coordinator. There John sat, at the second level from the bottom, until the client switched to a new time-sharing service and the system had to be rewritten to take advantage of the new capabilities. Of course John had been so busy holding the client’s hand that he had never had time to be trained in time-sharing. John was early-retired at the age of 45 at 25% of his annual salary averaged over the preceding five years.

Case history number three

Bob Roe was a semi-competent programmer who managed to stay out of trouble for five years and was finally promoted to systems analyst. As a systems analyst he managed to avoid disaster by judiciously hedging his bets and staying away from large, expensive, visible projects. But he could not be said to be noticeably incompetent, and managed to give the impression of knowing how to do things. (In fact, he spent most of his time giving advice to others, having learned that advising is safer and easier than doing). Bob’s trouble was that his immediate boss had achieved final placement (see The Peter Principle), having achieved a level where his incompetence was no longer apparent. Bob’s boss relied heavily on him to answer questions of the “what does your department do?” variety, since he himself didn’t have too clear an idea. (He could explain it in concept but people just went away shaking their heads and asked Bob the same questions)

So there Bob sat, one level below his boss, whose function no one was sure of since he hadn’t done anything in five years. He couldn’t be fired either, since he spoke so impressively that the listener went away convinced that whatever it was he did do, it must be very complicated and beyond the understanding of the average intellect. Bob was finally early-retired at the age of 47 at 35% of. . . .

I hope these examples have convinced the reader of the wrongness of the Peter Principle. People do not rise to their level of incompetence The competent stay put; they are too valuable where they are. Eventually they become overpaid for their rank and are thus locked in to low-level jobs. The generally incompetent (the vast majority of the business and technical population) move upward through promotion or through inter-company diagonal transfers to the point where their incompetence becomes invisible to all but the most discerning and cynical observers from below.

Dr. Peter was off the track again when he assumed that the rational employee would wish to avoid final placement. On the contrary, that is what we all strive for, rational or not. The method of achieving final placement is, amazingly enough, exactly the prescription advocated by Dr. Peter as a means of avoiding final placement: mask your competence behind the guise of mild incompetence! The reader should not be surprised at this curious negative reasoning, since we now realize Dr. Peter was 180° turned around in the first place. Remember, those who flaunt their competence will remain exactly where they are at the bottom of the hierarchy, since they are too valuable to be promoted. To move upward, exhibit at least the normal amount of incompetence, and, since you are not making a contribution where you are but have done nothing to warrant firing, the only choice is to promote you. This play can be repeated as often as you like, achieving constant upward movement. In fact, your security in doing this is directly proportional to your length of service, (“we can’t just let him go after twenty years with the company”), and your rank (“he must be good, otherwise how did he get this far?”). 1

I apologize to Dr. Peter for controverting his theory, but my humanitarian instincts lead me to publish my own theory before too many well-meaning people are hoist by their own petards. I have seen too many obviously competent people, striving to achieve final placement, frozen in their tracks due to their own competence, to keep the real truth a secret any longer. Dr. Peter was wrong on two counts: he saw both the criteria for advancement and human ambition bass-ackwards.

For a specific example of this type of reasoning, see “The Emperor’s New Clothes”.

Author: John E

Retired software engineer interested in real-time control systems and languages. I developed "immediate C", a language for high-speed control and robotics. This Blog also contains articles about early work in a 60-year career as a Software Engineer.

3 thoughts on “The Inverse Peter Principle”

  1. Fascinating blog! Is your theme custom made or did you download it from somewhere?
    A theme like yours with a few simple tweeks would really make my
    blog jump out. Please let me know where you got your theme.
    Thanks a lot

  2. Happy Father’s Day.
    I re-read the Peter Principle. It is with some bittersweetness that I realise that it is the story of my life.
    But I guess it’s ‘not over ’till the fat lady sings’. as I told our selling real estate agent the other day who has liverwurst legs. I’m glad you’re still working and hope your new venture works out well and woud love to see yoiu in a ‘pumpkin hat’.

    Love from daughter Barb.

  3. I must have read that article in DATAMATION those many years ago and thanks for bringing it up again. It came out about 10 years after I entered the field, and in fifty some-odd years I only worked for one company where it was not the normal case. It should be required reading for anyone entering the field.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.