Hacker News Reader

Comment by jcheng | Hacker News Reader

I only worked there for about 3.5 years starting in 2006, but from my perspective, dead wood was a bigger problem than the stack rank, and the stack rank was the main force keeping dead wood from being an even bigger problem.

Are there better mechanisms to systematically force managers to make the tough calls to let people go or counsel them out?

View on HN

The stack rank is the _reason_ there's so much dead wood: managers have to keep mediocre performers on the payroll so that star performers don't get bad reviews and leave. You need star performance to get anything done, since Microsoft is not somehow exempt from the power-law distribution of programmer productivity. The accumulation of mediocre performers makes the organization "trust sparse" (the average employee is a low-net-value robot who exists only to absorb the bad reviews in place of the few who get stuff done), which seriously damages long-distance collaboration, since you can't tell in advance which employees are the bozos. The review system also creates a culture of extreme risk avoidance, as you can't trust the bozos you have on your team to actually code features properly, but you still have to give them work.

End user comment: I interact with the products of this system every day. I shall never look at Microsoft Office or Outlook in the same way again!

I can see how it would be a good way to rid the company of dead wood, but depending on the employees are grouped, it can work very poorly. When it was first implemented in an organization I used to work for, group A already had almost all dead wood (when compared with the overall company) and group B had almost all stellar employees (when compared with the overall company). Some of group A will ended up "at or above the curve" for their group, while some of group B ended up "below the curve" for their. So some of group B got bonuses while some in group A ended up on "performance improvement plans". Poor implementation? I assume so. But it was painful and infuriating to watch. I was in group A and did not end up on a performance improvement plan, thankfully. But my blood still boiled - for myself AND my co-workers.

You may wish to edit your group A and B descriptions unless you meant you were dead-wood!

This sounds terrible either way, but why did one group end up significantly worse?

There is the Cravath Sytem's "Up or Out" policy:

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

  In a hierarchical organization, "up or out" is the 
  requirement that each member of the organization must 
  achieve a certain rank within a certain period of time. 
  If they fail to do so, they must leave the organization.

It's one of those things that work well only in certain circumstances. Most especially a continuous stream of applicants, some of them above average, is needed.

At my not-particularly-good university they keep hiring faculty at assistant professor rank. Since the graduate school isn't impressive the applicant quality and publication record isn't great, and someone getting a grant is a rarity. After five years they won't get tenure, the position is re-advertised, more startup money is spent, wash, rinse, repeat. Under these circumstances it would be wiser for them not to shoot for the star performers they won't ever get. The research quality will be just as mediocre, but they can spare themselves the hiring process and save on startup funds.

Sounds awful. I work as a programmer, but the only way up at my employer is into management, where I would necessarily have to stop working as a programmer. That would be a step away from what I enjoy doing.

A healthy engineering company should have high level positions that are still engineering positions.

The challenge for corporations is to figure out how to keep senior technical staff in technical roles when they legitimately have worked their way into a product ownership role (this is for non-consumer-product companies with dev teams of only a few people) and there may not be a personal with people-manager skills who has the business knowledge to do that part for them.

That would be very difficult in a software development role. You'd either end up out of dev and in management or you'd have to leave.

Everywhere I've worked there's only a few levels where you actually code - right now we have graduate, dev, and senior dev. You'd end up moving your best people to a level where you can't use their skills any more.

Microsoft does have an up-or-out policy, but they take pains to try to avoid the problem you point out. Management is not considered "up" from dev, but a parallel track (whose bottom rung is a little higher than the bottom rung of dev). The top rung of the dev ladder is "Distinguished Engineer" and these people are spoken of in much more hushed and awed tones than any VP.

Also the up-or-out policy has exceptions: there are "stable" levels where you are allowed to stay for the rest of your career. IIRC the lowest stable level is Senior Dev (level 63) so if you are hired at level 59, the expectation is that you have the potential to make it to 63; if you earn promotions too slowly or not at all, you'll eventually be let go. This is true even if you do a perfectly adequate job at levels 59-62.

It's not a model that would work for every company, obviously...

The top dev ladder rung is Technical Fellow (promotion from distinguished engineer.) Except for Dave Cutler, who is a 'senior technical fellow' ... which is the exact same level with a different name.

Reply on news.ycombinator.com