It's not just bullshit, it's actively harmful. It encourages people to game the system, often by playing political games. Secondary to that it encourages work on short-term, easily measurable projects, which tends to be the least valuable work. If you spend a year cleaning up garbage code you won't get nearly as many gold stars as if you just built some useless shiny bolt-on feature that nobody will actually use in the future. Now you understand a lot of what's been wrong with software development at places like MS over the last decade and more.

Perhaps even worse than that, this sort of bureaucratic BS tends to be extremely off putting to talented engineers who are intrinsically motivated to do good work. So they leave. Because they have the most talent and experience and are thus the most able to find work elsewhere easily. Bad corporate culture has a tendency to cause talent to evaporate out of a company. It's been happening at MS for decades and has seriously damaged them, it's happening at a lot of other places too. The problem is that when the people in charge look at what's wrong they don't see these things because it's practically invisible on a macro scale. Individual people on specific teams could run you a laundry list of former heavy hitters in their part of the company who left for greener pastures because they got fed up. But at the highest levels the only evidence that tends to show up is that for some reason it's become more and more difficult to execute on challenging projects, which is easy to attribute to any one or multiple of the countless other changing variables.

What is in your experience a better way to subtract the effect of personal feelings from performance reviews? How can you scale, and make it fair? Is it even desirable, as an unpleasant but productive person may have an impact on the morale of a team?

I've never had to manage "at scale", but I've spent the last several years of my career with one foot in management and the other doing actual development. I've been the person reporting to the people who lack introspection.

Ultimately, in my opinion, I think that trying to create the perfect algorithm for evaluating performance is futile. You can't really remove the effect of personal feelings because they play a huge part in group dynamics and in the end you are not trying to optimize for a single person, you want to optimize your team (or organization).

My experience has been that if you just listen to your team and watch them it'll be very obvious who is adding value, who is neutral, and who is a net negative. So long as your team size isn't larger than a dozen or so people, the team will seem to naturally coalesce around people who get stuff done, and they will tell you (sometimes with honest words and a tone that implies sarcasm or joking to remove the feeling of guilt) when someone isn't doing their part. The entire thing can be very opaque- I know of cases where one person seemed to get far less done than everyone else on the team (completed fewer projects, committed less code), and yet was very highly regarded. One might think that she was simply well liked if unproductive, but after she left for a different position the productivity of the team declined significantly. She turned out to have been so well respected because while she didn't create a lot of code she had a knack for spotting problems early on (things that were never seen outside the team because they were fixed early) and coordinating decision making between different people and projects. After she left there was a brief surge in productivity, followed by a disastrous slog as development was mired in bugs and component rework because of poor communication of specifications. In the same team, much later, there was an analogous incident where a developer appeared to be one of the most productive developers on the team. He was well liked as well and often participated in team activities, etc. but there was a constant undertone of joking about how much difficulty and complexity the person introduced into the code base. When I stepped in and did a thorough code review and looked at his parts of the project I realized all the joking had been really telling of a very real problem. The code was nightmarish. After that person was moved away from development and back into devops the productivity of the team had a short slump as everyone worked to refactor or replace his parts of the project, and then eventually ended up being much higher even with one less person.

None of the anecdotes are really new to anyone whose done development before, we know about net-negative producing programmers and people who catalyze work more than actually doing it themselves. I really just bring it up as a reminder of why it's so hard to have any objective measure, but also looking at how the other team members react to a person is very telling.

Well, that works when you manage a small team, but if you were in charge of say, Google Search or Microsoft Excel how would you go about managing hundreds or thousands of developers? Knowing you can't even be around the several hundred team leaders, let alone every developer, so managing by feel becomes impossible. You have thousands of new, and leaving engineers, you need some kind of order to the chaos...

Personally, I only tackle problems where I know I can keep the team small and in constant contact. We work remotely, and prefer Haskell, both of which self-select for people who are capable of managing themselves and working in such a setup. But it wouldn't scale to Google or Facebook scale, I don't think. Maybe Whatsapp.

You would make the unpleasant-ness a metric you measure.

> Now you understand a lot of what's been wrong with software development at places like MS over the last decade and more.

I don't think that actually _is_ the main reason why MS had(ve) so many problems.

In the end, people have minds and brains, and they know (at every layer) that the system is bullshit. Whatever is written on you performance review, your manager will know what he will need to write (or advise you to write) to get you a promotion, if he thinks you deserve one. And the same apply for the manager of your manager, etc.

Don't forget that in places like MS (or other big corps), you cannot really climb the ladder faster that the others. Everything is more or less ruled by your years of experience, etc. At most, good performance reviews will help you get promoted a tiny bit earlier.

This clearly discourages very talented developers. Let me clarify this.

At most companies I've worked, there are always some minority of really bad developers, a majority of OK or good developers, and a minority of really talented one.

Very roughly that would look like:

- 10% bad - 80% OK/good - 10% very talented

The bad developers usually are there since a while (say 5/10 years). They learned to stick to _their_ little tiny project and don't do much aside from it. They just do the bare minimum so that they don't get fired and that's why they are here years later.

At MS things were really different. There were no bad developers..., and no very talented developers. It was, like, 100% of good/ok developers.

Why?

Because MS is not driven by technology. MS is driven by business.

1. MS thinks every developer is replaceable by any other one, given some warmup time.

2. MS thinks the technology is not important, only the final product/feature is.

3. MS lives in a completely isolated bubble.

Now let me explain how these two points made MS fall this low. Of course this is my personal view, and I guess some won't agree.

1. MS doesn't value developers as individual contributors. MS values "teams", as a workforce. You will never be valued individually. You team will, or you project will, but not _you_. MS won't try to understand how you feel, what you think, or try to make you stay. It's just too big of a company to care at the developer level. This means the turn over at MS is high, and the management is used to it.

2. This may be a personal view, but most of the time when I work somewhere, I don't give a shit about the business itself. You can build a rocket, a vacuum cleaner, or whatever, I don't care. I only care about the IT side of the project: are there interesting challenges? Do I like the stack? how old is the code base? etc. At MS, a developer is expected to think exactly the contrary. You should have no interest in the technological stack, and only care about improving the product. This means:

- most of the time you won't have the choice of the technological stack, this is demotivating

- you will have to use a stupid stack, because a somehow similar previous project used it and it worked (someone said so)

- you will never innovate technologically, that's of 0 business value.

3. Now this is a really funny one. At MS, management lives in an other version of internet. They read only MS friendly & specialized websites, newspapers, etc. This is absolutely insane. Guys are absolutely sure that the whole internet is super focused on what they do, deeply care of every single thing that they say, etc. They will send mails like "look at the awesome article that is on the front page of TECHCRUNCH! the whole internet talks about us", and link you to non technical, pure BS article written by a guy paid by MS to write it. Funny sidenote: When I relocated to an other country with MS, I had a girl from a local travel company show me the country. She was a contractor, and explained me that she had a training specially for MS employees, where they would teach her not to send mails through gmail, not to send maps using google maps, not to show her iphone, when talking with MS employees. The management of MS lives in its own bubble, they are 100% sure that bing is used by everyone, they are 100% that the new Skype is awesome, they are 100% that windows server rocks and all modern websites use IIS.

Sounds very, very similar to Raytheon, albeit for somewhat different reasons. I rarely saw actual bad developers. I also rarely saw really stellar developers. We had a good number of talented engineers (in all disciplines), but most were underutilized for political reasons.

As you said, it was all about the final deliverables to the customer. All about the product. Our situation was more complicated, though, given our customers. The US federal government customers exert significant, and IMO technologically unjustified, control over development programs. "Customer satisfaction" often meant doing things in a way that we knew made no sense, but where the customer refused to listen to reason and insisted that they knew best.

What sucks is that I love the domains that Raytheon, MS, and similar companies operate in. Something about those domains drives all the companies in them to be like this, though. It's really frustrating.