The Peter Principle Revisited: A Computational Study (2009) | Hacker News Reader

The Peter Principle Revisited: A Computational Study (2009)

arxiv.org

101 pointssejtnjir50 comments

> in order to avoid such an effect the best ways for improving the efficiency of a given organization are either to promote each time an agent at random or to promote randomly the best and the worst members in terms of competence.

Too funny. Ever think your company was promoting without thought or reason, or promoting the worst people? It turns out the corporate HR/Management system has evolved to defeat the Peter Principle.

Genetic mutation, evolution.

It's a natural consequence of making the promote decision only available to higher ups, who have already found their level of incompetence.

Ideally this study would have included this effect too.

The Dilbert Principle: The most ineffective workers will be systematically moved to the place where they can do the least damage — management.

https://www.amazon.com/Dilbert-Principle-Cubicles-Eye-Manage...

I wonder about a possible opposite principle: a person best suited for a role in leadership is stuck at the bottom of the hierarchy, because he's not fully competent at this current role, so he has no way to climb up.

How far up in the hierarchy do you have in mind? It's hard for me to believe that you could be a good senior engineer without having been a good junior engineer.

A mediocre individual contributor could be a competent project manager.

I'd agree with this, there is some overlap, but mostly these are distinct skills (people skills vs. technical skills).

That could be the reason for it. Mediocre engineer finds that they have a better head for managing people and schedules than lines of code. Either they talk to management, or management notices and offers the transfer.

> these are distinct skills (people skills vs. technical skills)

I believe most people here will agree with that statement; nonetheless the problem is the ludicrous situation some people view the world through and consider that "junior techie moves to senior manager" as a fact of life†.

There is real social pressure on that front and lots of belittling of tech. Basically every time I meet some new person and say that I'm a software engineer, I get asked "But you still code at your age? Surely you'd rather manage people! What have you even achieved in life?" or any variation thereof and have to explain, justify even, that designing, planning, architecting, maintaining, and developing software is a real expertise domain in and of itself. The situation extends even in the workplace, where it is mostly expected of you to raise to management positions, and you won't get any raise if you don't "move past" "coding", as coding is largely considered a menial task by many, a sort of weird heritage of/transposition from an industrial culture.

† This has a vicious side effect of creating an ecosystem with mostly zero-quality software, since somehow only juniors and unskilled seniors code, because either skilled coders raise up the management hierarchy to get some raises, just leave for places/countries with a better mindset, or are overwhelmed by their unskilled peers.

You cant manage project on people skills alone. That just don't work all that well and is likely to lead to crappy product and massive crunch. You cant manage project without at least some technical skills. You don't need to know all details, but you need to know enough about tech to understand general concepts, what is possible, what is risky, what technical debt means, when people lie to you about tech. In order to be good project manager you need both, but you don't need to be super genius in either.

And there are also skills (or attributes) that makes you both better programmer and better manager: being organized, systematic, being responsible, willingness to do also boring tasks, understanding what people say when they talk to you, ability to explain yourself, good memory, etc.

Sure, but mediocre does not imply "not fully competent", at least not to me. Maybe it was just bad wording in the GP.

But I also don't consider a product manager higher in the hierarchy, at least not explicitly. Does a PM get paid more than a mid-level engineer?

I believe project managers/product owners get compensated better than engineers in my environment. They may or may not have a technical background. I'm not sure if this is generally true.

More thoughts on the semantics of mediocrity (the author was also referred in a sibling comment) https://www.ribbonfarm.com/2018/04/24/survival-of-the-medioc...

I'm not sure "project manager" per se is necessarily the best example because that's at least in part a different task. But there are certainly individuals who are good people leaders, protecting their reports from distractions, giving them opportunities, etc. who aren't necessarily particularly brilliant engineers.

Isn't that the point of the Peter Principle, you're good at your current tasks so you get promoted to do other tasks that you're not good at; as you're not good at those then you don't get promoted further, but you also don't get demoted to the tasks you excelled at.

The problem is viewing the company as hierarchical. Just because less managers are required doesn't mean it's a more important role.

The Peter Principle would be if a good engineer, in order to be promoted, had to become a manager--even though they didn't want to manage people and aren't good at it. It is rather based on traditional hierarchies which good companies offer ways around, e.g. individual contributor advancement tracks.

What I was saying was that just OK engineers can get promoted to management and actually be quite good at it.

I had a boss that worked in Continuous Improvement. As a manager he was great because he was very good at coming up with the nucleus of an idea. He was terrible about implementing the idea, but had a crew that was great at implementing his vision (think George Lucas).

Left to his own devices, he had some horribly implemented ideas that really messed with our manufacturing floor. He was then moved to supervise a couple of manufacturing departments, which also resulted in disaster. He was moved to another facility shortly thereafter.

It's hard for me to think of an opposite to the Peter principle as formulated in the article:

"Every new member in a hierarchical organization climbs the hierarchy until he/she reaches his/her level of maximum incompetence"

Every new member moves down in the hierarchy? That doesn't happen in the real world.

"Every new member rises to their level of competence" is also an opposite.

As would be "every old member is demoted in the hierarchy until they reach a level in which they are competent".

Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid. - Albert Einstein

There's no evidence Einstein ever said that: https://quoteinvestigator.com/2013/04/06/fish-climb/

And some fish can climb trees: https://www.thesprucepets.com/some-fish-can-climb-trees-3969...

he misattributed - it was actually Mark Twain :) :) :)

Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid. - Albert Einstein - Mark Twain

(How Twain predicted Einstein to say this, I'll never know.)

This is why horizontal movement is necessary in an organization. Also, changing to a management role should not be considered vertical movement in some cases.

I recall that I first learned about the Peter Principle at the same time that I was reading Lee's Lieutenants by Douglas Southall Freeman, and there was a weird synergy between the two.

As the war continued, attrition took its toll on the Army of Northern Virginia's officer corps, notably after Jackson's death at Chancelorsville. The two generals that replaced him, Ewell and A.P. Hill, were very good divisional commanders, but poor corps commanders. That tome is littered with other examples of officers excelling at one level of command, but being ill-equipped to perform at the next level.

It's really interesting just how rare those skills are, even at the top. Napoleon made 26 marshals of the empire, and only 3 would have been remotely capable of stepping into his shoes: Davout, Massena and Suchet. (Murat, Ney and Soult are all hype, don't @ me)

A lot of comments here are using word like "promotion", starting at the "bottom", powers reserved for "higher ups", etc. following the standard framing of hierarchy as a vertical pyramid, which I think possibly encourages the view of promotion as status.

My favourite reframing of team hierarchy is to change the language to make it horizontal or fully inverted.

In the horizontal case, promotion might be 'stepping back a rank to help co-ordinate'.

In the inverted case, promotion might be 'stepping down into a supporting role' (although that particular language bumps into confusing euphamisms left over by the pyramid framing).

I'm sure some better language can be found but you get the idea.

But promotion is one of the incentives to be best - so unless the other incentives are stronger - promoting randomly or promoting the worst performers will remove a strong incentive and will pull down the productivity of the organization anyway. Or there should be an explicit test for the skills needed at the next level.

Exactly my thought too. There is one more missing element here other than competence, namely Performance. The performance at a particular level depends on how the agents perceives the promotions are made. If randomly promoted or worse, promoted even without best performance, there is no incentive for people to perform even if they have the best competence.

Moreover, there is a reason why worst performer in terms of competence is the worst. The performance of people under his leadership is pretty much guaranteed to go down, as they are forced to fight his bad ideas or adjust.

Just handwaving here, but taking the best developer out of a team (to put them elsewhere) also makes the team's overall performance go down.

Yes. And he or she may also completely suck at new position. And also, if you have one superstar surrounded by weak people, someone is already doing bad job.

But, worst performed (which is not same as normal average performer) is very likely to suck at leading the thing he or she was unable to learn. Or unwilling to learn. If it is latter, you can expect unwillingness to learn new position too.

Of course, revolutionary idea would be to identify traits that are necessary for new position and look for those.

> But promotion is one of the incentives to be best

Is that because many organizations tie together the concepts of higher pay/benefits and moving up in the managerial hierarchy?

Considering there is evidence that the Peter principle holds to a certain extent, that has always seemed odd to me. A person being best at one job is not a strong indicator that they'd be best at another. Personally, I have no desire to be promoted into roles that don't suit me.

Yes - pay/benefits are mostly related to hierarchy unless someone is a tech star mostly.

And even if not - the folks higher in the chain also get to decide what gets to be worked on.

My idea for a solution would be to offer better pay/benefits opportunities for your good developers, at the same time giving them also more creative freedom when they rise the ranks in a technical role.

Making management the only option for having a "career" is the issue.

Another option to avoid the downsides of the Peter Principle is to test drive people in their new roles. Basically you slowly add responsibilities that look more like the post-promotion job, if they do well they get the promotion and they've already proven to be able to do these things. If at some point you notice it isn't working, well then you don't promote them, or promote them to a different position.

This was famously discovered 60 years ago:

https://en.wikipedia.org/wiki/Skunk_Works

> The designation "skunk works" or "skunkworks" is widely used in business, engineering, and technical fields to describe a group within an organization given a high degree of autonomy and unhampered by bureaucracy, with the task of working on advanced or secret projects.

One of the key findings of the Skunk Works project is that you unlock potential, a company needs to be willing to pay individual contributors more than their managers.

Most people are probably not incentivized by promotions that give them a completely different task they might not even be good at, but by the increase in salary and status.

You can certainly have the latter kind without promoting e.g. the best programmers into mediocre managers.

The paper's suggestion to promote randomly or the worst is a bit silly. It only appears better than the alternative because they assume that there is no information about someone's competence at anything except their current job, and promoting someone is equivalent to firing them in favor of a fresh hire in their model.

In theory, yes.

I’d love to see a randomized trial of random vs “skill” based promotions for people management.

I’ve worked in civil service environments where promotions were driven by core management skills like reading/writing ability, analytical ability, and various management topics. In other positions there’s evaluation of project management ability, and others were appointed to positions by political process.

Although I didn’t study it, observationally, I saw no correlation between method of promotion/appointment and my ranking of them as a leader/manager.

Depending on role, even low skilled people can be excellent depending on EQ and circumstances.

What is best? If I ignored all my coworkers I’d write a lot more code but it would be the wrong code.

Instead I work on a team and I act like it.

There are two different sorts of promotion. The first is a promotion in rank, where the job you do is fundamentally the same, but you are paid more for it because you're better at it.

The second is a promotion in office, where the job you do is fundamentally different, but you are paid more for it because your responsibilities are wider.

We get in trouble when we try to use the same mechanism for both. Promotions as incentive in the first case are fine. Promotions in the second are what this paper deals with, and are where the incentive aspect is more problematic.

Why not just have a configurable threshold (say, 2 years) where if the promoted person is determined incompetent in their new role, they are bumped back down to their previous role (keeping their same pay) where they are more efficient/competent.

If I think that's likely to happen to me, why would I stay around to find out? In that situation I'm far more likely to apply for other jobs with my nice shiny job title while I've got it. Plus, with a mechanism like that, you'll see anyone with impostor syndrome (which would be... lots and lots of otherwise competent folk) making evacuation plans that really aren't needed.

There's a cult myth among even the "enlightened" rockstar companies that it's better to fire a person than demote them. Not sure why this holds root. Something to do with the idea of "trajectory" and that employees are paid and retained for their future potential performance, not their current performance.

If I were running the company, I'd just masquerade the demotion as a promotion:

1. Promote from principal engineer to technical manager

2. 2 years later -> this person sucks at management but they were a great engineer

3. "Promote" from technical manager -> principal engineer level 2

moving backt o high level IC isn't usually considered the same way. You just move the person to work on something else as IC, and they say it was their choice because they like being a Principal engineer better.

View the arxiv paper as a webpage: https://www.arxiv-vanity.com/papers/0907.0455/

It should also be standard practice that a person's promotion is accompanied by expectation setting and training. Otherwise, no one could ever grow out of their current shell.

The gervais principle is more interesting than the peter principle.

https://www.ribbonfarm.com/the-gervais-principle/

> Sociopaths, in their own best interests, knowingly promote over-performing losers into middle-management, groom under-performing losers into sociopaths, and leave the average bare-minimum-effort losers to fend for themselves.

HN discussion (2009): https://news.ycombinator.com/item?id=881296

which is why you shouldn't promote by the numbers and instead have a look for who is best at the qualities required for the level above. A good manager shouldn't find that hard to figure out and can also probe at it by changing responsibilities more gradually.

Reply on news.ycombinator.com