What happens is that these firms accumulate a vast, stagnant layer of middle and upper management types who have no incentive to work any harder, take new risks, or develop talented employees. Instead, they're simply cashing in on a safe paycheck, riding a pretty cushy high horse, and fiercely fending off anyone they perceive to be competition for their sweet gigs.

Compounding this problem is the fact that mobility slows to a crawl, because the queue is full. This breeds dissatisfaction with the young, ambitious types, while simultaneously breeding resentment among the older, entrenched types who adopt the grumbly "kids these days..." defensive mentality.

Now, there are plenty of ways to screw up the up-or-out system: bad KPIs and standards, inept evaluation processes, etc. But no system is perfect, and at least a system that forces honest dialogue with managers about their future advancement prospects is better than a system wherein lousy managers can overstay their welcome.

The U.S. military has a similar up-or-out policy (especially among the officer corps) and the result is (more often than not I'd say) yes men who latch onto a strong leader type and ride his coattails into a senior officer position. The result is poorly informed and advised leaders, and senior staff who spend their time figuring out if what they're doing will be approved "by the old man" instead of actually promoting the function of the organization, fight and win wars.

The key difference between up-or-out and the alternative is that, in the alternative, a certain segment of the employee base plays the politics game, and a certain segment kicks back and stagnates in the middle, while the rest try to get ahead honestly. In up-or-out, at least the third category has a decent shot. In non-up-or-out, the people trying to work hard and advance on merit will run up against the entrenched slackocracy and the political Machiavellians.

In my post, "problem" was referring to the parent post's "politics organized around moving up." My point is that most corporate cultures have elements of that focus on upward mobility. Obviously its prevalence varies from company to company. But I'd rather take a culture with an over-focus on upward mobility and potential for upward mobility than a culture with even a lesser focus on upward mobility, but less potential for it (due to all the dead weight).

I'm not holding "focus on upward mobility" equal in that assessment.

This means during prolonged periods of peacetime, a form of regulatory capture happens where the metrics used to evaluate promotion become decoupled from actual fitness of purpose.

For example, since success in academics is usually the first requirement to even start in any position above the most menial, anyone who finds it difficult to toe the line and waste hours listening to someone drone on about a topic totally unrelated to their purpose in life, or enthusiastically embrace make-work homework assignments, will likely have a hard road, no matter how well qualified they might otherwise be.

One could argue that the U.S. military in particular has had a tremendous opportunity this last decade or so to conduct exactly the kind of wartime evaluation you're talking about. But I wonder if the evaluation metrics are optimized towards peace-time?

In many respects, David Petraeus is the perfect embodiment of these political principles. He published, he politicked, he maximized his media exposure, and he hobnobbed within the right DC circles. I'm not qualified to judge whether or not he was as good a leader as many believe him to have been. But he was certainly a top-notch political operative.

(Other government agencies, e.g., the CIA, have very similar internal political incentives. The game is almost the same. This may explain, in part, the fluidity between military leadership and Agency leadership).

For the medical corps, above O-6, they usually have commanded at least one smaller facility, before they get an administrative flag assignment. More than a few have flamed-out at O-5 and O-6 commands.

In a carrier squadron, being XO or CO is preceded by being a department head. Maintenance department is a good one to get a command, but there are other departments.

The Army Medical Command had the problem with senior staff, where they were a large number of senior officers, O-8/O-9, involved in the Walter Reed scandal in 2007, were either fired or retired. Covering over issues with memos and paperwork up the chain-of-command by "yes men" didn't cut it.

If they can't, they deserve to drown themselves. If they can, they will filter out most of the fakers, and collect a team that can get stuff done in real adversial situations - since a great commander with a sucky team will suffer, and an okay commander who is able to build a great team will get whatever achievements are possible.

In the worst case scenario, a large number of people go "up" to the point where they're no longer capable of doing the job they're in and then go "out" after a brief period of doing their job badly.

These people may well have been very competent at their previous level of authority and so the business as a whole loses out.

Additionally companies which state outright this is their policy often have quotas of people who should go "out" which I've seen, in particularly talented groups, lead to an almost random selection of people going out despite the entire group being so close together in ability than no meaningful distinctions can be made.

EDIT: re jonnathanson response below, agree completely that if up can mean a person is performing solidly and achieving good results while improving year on year then such a system can be very beneficial. My criticism is much more focussed on systems where up explicitly means moving through grades, especially where there are attempts to apply quotas to who goes up and who goes out.

AKA, "The Peter Principle."

http://en.wikipedia.org/wiki/Peter_Principle --

The Peter Principle is a belief that, in an organization where promotion is based on achievement, success, and merit, that organization's members will eventually be promoted beyond their level of ability. The principle is commonly phrased, "Employees tend to rise to their level of incompetence." In more formal parlance, the effect could be stated as: employees tend to be given more authority until they cannot continue to work competently. It was formulated by Laurence J. Peter and Raymond Hull in their 1969 book The Peter Principle, a humorous[1] treatise, which also introduced the "salutary science of hierarchiology".

When the PP is active, people "rise to the level of their incompetence", and then stay there indefinitely. In Up-or-out, if you stop rising, then (after some suitable attempts to help you get unstuck) the company starts encouraging you to leave (with increasing vigour). They get the benefit of your knowledge at every level that you can operate at.

In this case, "up" means improvement more than it necessarily and literally means up the ladder.

I realize this reponse could be interpreted as a bit of a no-true-Scotsman reply, but honestly, it's intended to be a clarification of my original post.

That was their deal: you start out as Junior Developer and when you are there for 5 or so years, you can decide whether you specialize into technical stuff or people stuff. From phone calls with recruiters I had the impression this is not an unusual model.

My company does this all the time. Didn't do well enough at the job interview or you're a total bozo and poor at understanding technical concepts/writing code? No problem! They'll appoint you as a project manager and you will get a team of developers to manage. At the same time, the brightest and the best engineers rarely get promoted because they are keeping their heads down and actually getting shit done. And there is little incentive for the company to promote such people because they lose a skilled and productive programmer if they do that (they don't care about anything except for how fast you can crank out code - one of the typical ailments of consulting companies).

It's a very sad state of affairs. Makes me want to quit really.

It was because their managment positions were so stressful and so communication heavy, that most developers were totally not suited for it, and just plainly quit.

The people that promote individuals into management roles are often just as naive. The individuals are expected to develop new skills simply by virtue of having been promoted.

A proper Manager who is coaching his staff, performing performance reviews, ensuring the team has all the resources needed to do their jobs as efficiently as possible, protecting the team from unnecessary bullshit meetings/interruptions, etc is a completely different story.

Being a technical person, I used to doubt this too. But having seen to many bad managers in such a short time, I believe it's true. When you are senior enough, in a small company, you don't need a technical supervisor. You just need someone you can trust, who gives you political backup and who will evaluate you on your results.

http://en.wikipedia.org/wiki/Peter_principle

This should be required reading: http://books.google.com/books/about/The_Essential_Drucker.ht...

If your job is that shitty, and you're that smart and good, quit and find a better job.

Now of course, some companies are better or worse than others, some managers are better or worse than others and so on.

Personally I don't see myself a manager because I lack the social skills. In some days I barely remember to do minor things like sending out an email to my team at the end of the day or ask about the status of some roadblock.

Ofttimes, what looks like meaningless corporate bullshit to a developer looks like valuable fertilizer to some other part of the organization, or to a regulatory body, or to something else that makes the company go. "looks like" phrasing was intentional here.

I was a damned good developer back in the day, and am working on being a good manager (of managers at this point). There is an insane amount of red tape that sprouts up over time in any large assembly of people. Some of it has some positive purpose somewhere; some of it has no evident purpose.

The best managers seek to protect their teams from unnecessary BS, but that doesn't necessarily mean eradicating it from the company. Shielding can be just as effective locally, at a tiny fraction of the cost.

In my experience, it's usually _not_ the line managers but the people above them. I've left several jobs, but almost always wasn't because of my immediate manager.

The challenge managers have to face is balancing competing priorities. If you're a manager, you have customers/users that you need to please to keep the money rolling in. You have an executive who often has very strong opinions about how to please those users. You have employees that each have their own career goals and interests, which may not necessarily be aligned with yours. You have cross-functional peers who you frequently need to rely on for favors, and yet often speak a totally different language from you. And you somehow have to make all of the above groups happy, or at least not totally pissed off at you, to keep the organization functioning.

I dunno what your job description is like, but mine (as a senior SWE at Google) is "Figure out how to make users happy". If you don't face similar ambiguities in your job description, it's because there's a manager somewhere up the org chart who did all the messy work of listening to what everybody else wanted and somehow harmonized it all into something halfway buildable. If you have a spec you're following, there was somebody out there who wrote it. If you're getting paid, it means somebody out there sold the product, and that usually requires listening to all the customers out there and figuring out what they want in common. None of these tasks do themselves.

That's the crux. If you really are that good, it shouldn't be too hard to leverage your skills somewhere better.

That assumes the Hogwarts Hat of random allocation doesn't land you with a stinker from the get-go. And I speak from personal experience that it occasionally does. If I had been able to change projects to something more relevant to my skills, I would still be there.

There have been far too many stories of arbitrary google managers both here and elsewhere to keep putting forth the story that if one goes to google, one can simply change projects if one doesn't like what they're doing.

Just one example from http://www.glassdoor.com/Reviews/Google-Reviews-E9079.htm

"For the most part, Google is held together by duct tape. Management quality is clearly below what's required for a company of this size. In a lot of cases managers are simply too junior and lack people skills."

Good! If you really like words and want to get some copy edited you should check out http://www.edithero.com/

Exactly.

It doesn't just hurt the employees, but the company (kingdom) as a whole. The managers (lords) concern themselves primarily with expanding their departments (fiefdoms), typically at the expense of other managers, rather than working to grow the company or improve the quality of life within it.

This leads to a mentality of collecting more rather than better staff, ass covering rather than innovating and all sorts of other bullshit.

Let's just say, I've heard rumor that my manager was asked to leave not too long after I was. And the circumstances of my leaving were not entirely unconnected.

The most important point making it like slavery was the fact that serfs couldn't leave their fiefdom.

That's where the analogy to a modern corporation breaks down - employees can quit whenever they want.

If they like starving, yes. Being subject to Morton's fork doesn't make for a great day.

Software developers are currently in a pretty great place in this economy. Not everyone is. It's pretty important to remember that.

Sounds like you don't have any ties to where you are and what you do. How is that working out for you? (genuine question)

I know the "flat" model is enticing, but I have yet to see an example that handles greenhorns well.

I have many solid arguments as to why the current system, which really is rather feudal, is broken and could not possibly represent the apex of management systems. I also have a few good ideas about alternate systems. However, that would make for quite too long of a discussion here, so I'll save it for some other time/place.

Nevertheless, I will point out that if there is a solid trend as it relates to the impact of the progression of networking technology and software in general it is that both have a tendency toward disintermediation. And if there is one intermediary who is oh so very ripe for being kicked into the gutter it is certainly the middle manager. How do we get along without him/her? To my ears such a question has the ring of "how will we get along without cholera?"

So, here's some bullet points: greater individual autonomy/responsibility/return (e.g. profit sharing & equity); more peer relationships and fewer superior/insubordinate relationships (though not the absence of such), note carefully that this is not identical to a flatter hierarchy; more freelance-style and partnership relationships (whether across or within corporate boundaries); more reliance on leads instead of managers; more mentor/apprentice style relationships. In general the "employer/employee" relationship being closer to a partnership that both have entered into freely and with respect for the other party with the expectation of mutual benefit resulting rather than a coercive, unequal, and authoritarian bond that employment often imitates today.

I guess it depends on your definition of slavery. Most serfs had some degree of autonomy and self-determination even if they were forced to pay tribute unfairly.

So that incites us to ask, how is it any different today, when we are also forced to pay a [quite hefty] tribute to the government simply for collecting money? We all have some form of autonomy, but the government has demonstration that only exists so long as we pay tribute and sacrifice the fruits of our labors. Same story as a serf, who would be granted a parcel and expected to pay a tribute to his lord or suffer serious infractions of basic rights to self-determination.

I don't know if this is common now or only applies to people coming off of the industry track instead of the university track, but it was not at all what I'd been warned to expect.

So far everything about Google has been generally fantastic. I'm hoping it lives up to it once I'm inside.

I do suspect it has something to do with your employee bargaining power, which depends both on your past track record and on how many people are being hired relative to staffing needs. Managers bid on Nooglers, draft-style; if many teams are bidding on you, you have a lot of flexibility in where you end up, while if only one team bids you're basically stuck with them. michaelochurch was hired in 2011 IIRC, when Google notoriously overhired, and it could be that many of the other teams were flush with Nooglers and not looking for anyone else.

Just my experience; I started at the beginning of 2012.

Add in the ability to occasionally submit votes that are statistically irrelevant and you've got modern Western democracy.

What you're discussing is the Credibility Drought. Companies define credibility so that only managers have it, in order to create an artificial scarcity that makes employees easier to control. That's what enables the managerial extortion that forces employees to serve local goals (the manager's own career) rather than the benefit of the company (or the growth of the individual).

Very few companies formally allow a manager to unilaterally fire. That's way too much of an HR/lawsuit risk. Instead, these closed-allocation dinosaur companies define credibility in such a limited way that managers can either support or not support the employee, and then if the person is not supported, that person's credibility is zero and the manager isn't firing that person. "The company" does it, after "careful review" of "objective" performance statistics. On top of this, they set tight headcount limits so that for anyone to get a good project requires a special favor, allowing the company to say "no" and appear consistent on the matter.

Google is aware enough of this problem to allow engineers at above a certain level to acquire independent credibility.

At Staff, you can pull a Yegge (quit your project in public) and be OK. If you're a SWE 3 and you try that, you're fucked.

So Google may be different from the full-on closed-allocation nightmare corporation, but you only if you either (a) start at a senior level, or (b) get on visible, desirable projects when you start, so you can get promotions quickly. The only time it isn't difficult to transfer to something better is immediately after a promotion (and there are some managers who withhold promotions to keep people captive; Google, to its credit, has a system that occasionally overrides managerial objections to promo).

The sad thing is that I don't doubt that Google is better than 95 percent of large corporations its size in terms of internal mobility, individual autonomy, and engineer-centric culture. It might be better than 98%. It's still pretty awful for a large percentage of people who work there, and the fact that it's so much better than most of what else is out there is a damnation of Corporate America, not an endorsement of Google.

But instead, I mistakenly emailed him, concerned that he was holding 1:1s with everyone else on the team except for me. He then hastily called a 1:1, apologized for forgetting my existence, and then immediately informed me that I was now behind on his expectations of my productivity.

My friends advised me to go to HR, so I did. Whereupon I found out he had already paid them a visit to inform them of me. At this point, the google immune system geared up to encourage me to leave of my own volition. I tried to get on to other teams. Friends in the company tried to get me onto their teams. These efforts were blocked.

Deciding this was a game not worth playing further, I left a month later when I got a compelling offer elsewhere.

Waste of 4 months IMO - but I also believe that if I had just been allocated to a more relevant team things would have turned out far better.

At the 3 month meeting, the manager openly admitted that while he managed two teams, he devoted most of his energy to the other one. So in his defense, he was overallocated. His other team was more interesting. But I think he already wanted me gone at that point so that wasn't an option.

My failing was explained to me that since I was a "Senior Engineer(tm)" I was supposed to arrive at google an expert in all their technologies so I could be a successful generalist and finish my starter project (in a brand new unfamiliar field to me) in <2 weeks. Whatever.

In contrast, I reached productivity <48 hours after starting my next gig, which did make use of my skills.

They make up those expectations after the fact, of course. Rather than have the decency to say, "I just don't like you, and don't want you on my team" your manager had to build an objective-looking "performance" case and it sounds like he was a total twat about it.

No one gets anything serious done in the first 2 weeks, and you're not expected to. That's what Codelabs (which are very good, and I wish more companies paid attention to that) are for.

One thing I disliked about the Google environment was that, because it's so hard to have a real accomplishment in your first year, whether you "succeed" depends on others' assessments (i.e. politics). I prefer to be in an environment where, after 3 weeks, I can reach the "so good they can't ignore you" state.

I like high-productivity environments better because I can prove, in the first month, that I'm actually worth a damn. Political issues always exist, but they're less threatening when you've already proven that you're good at what you do.

So they intentionally remove any element of choice in allocation, and throw people into the hopefully representative ensemble of all hiring teams at Google to test how one mixes with the average ideal spherical Googler. But if one ends up 2 sigma to the left of the mean, one is pretty much hosed. And that would likely have a 2-3% false rejection rate assuming this is a normal distribution and that most Google teams are sane. Not bad actually, but sucks for me.

Except that I don't think such a distribution is normal but more likely vastly oversamples the stinkers due to a twisted form of survivor bias because the stinkers have the highest departure rates, putting them constantly on the prowl for new meat oops I mean Nooglers (my small team lost several people during the short time I was on it and several Nooglers switched teams* hours before they would have started to avoid this allocation - I have a really funny photo of several sets of deflated welcome balloons next to what was supposed to be their desk after they had sat around for a couple weeks).

*The most important thing I learned at Google was that I should have secured my allocation before arriving as a condition of accepting employment. Failing that, one can sidestep the process on the first day if one has a friend on a team that is in need of people if one is insistent enough.

This is speaking as a comp eng. student who has gotten very little hands-on hardware experience. I've now worked two years doing pretty much exclusively software; the closest I got to real design was product verification and manufacturing support.

Google is one of the few companies where the 20% is a real thing for most people branch out, on either their own project, or another teams project.

As far as most companies, the side-project with other teams is simply not an option.

Thus, your manager decides if you have 20% time or not.

There are good managers at Google who value 20% time and will encourage you to work cross-hierarchically with other teams or on personal side projects, and there are others who are absentee so you can pull that off furtively. If you get a hard-ass with a lot of project-specific ambition, you're not going to get away with 20% time.

Google inadvertently makes it worse by conflating project leadership with people management, which means that your boss is also held responsible for the performance of a specific project. That creates a huge conflict of interest, because the employee might be a better fit for another project, but the manager has to eat a loss on the project where he is.

There's an escalation path if your manager is outright forbidding you from taking 20% time, and the manager can be disciplined by the Powers That Be for that.

Google also doesn't always conflate project leadership with people management (it depends on the team, and the org chart is explicitly setup so that this is not a given). There're pros and cons to both: if you're on a project where your manager is the tech lead, he'll know your work better (which can help you get promoted faster), but it also means that if you disagree with him on the technical direction of the project it can be harmful to your career. Out of my 4-year Google career, I've spent 2.5 years on teams where my manager was directly involved in the project, and 1.5 years basically doing my own thing or on loan to other teams with minimal involvement from my manager. I don't have a clear preference for one or the other, as I've found that my manager was always supportive of me as a person even when his primary responsibility was managing the project, and willing to let me move to another team when I'd outgrown his area of interest.

(It probably helped that I would work like hell to help my manager's project succeed first, and then transfer off once it launched. Most people are more inclined to help you succeed if you help them succeed.)

Seems what Valve does instead puts credibility on the open market. This makes sense, as that one term, credibility, actually encapsulates a complex panoply of things, and markets are good at regulation even when faced with complexity.

American corporatism is based on Original Sin (the so-called "Puritan work ethic"). If you're not "saved" by some rich institution (a job) then you're judged to be a leech and a failure. Most companies take advantage of this by continuing it into Credibility Scarcity-- you're worthless until told otherwise.

I've worked for "startups" that don't do this. You start out as an "idiot." The manager has to look over your shoulder every 30 minutes, and gets worried because you are programming using "blocks." You're dictated to in terms of which libraries you use. All this total micromanagement, yet the manager knows so little about iPhone development, he has no idea what "delegates" are or that they're the most common pattern in the SDK.