6 ms·
Been at Microsoft at the time they made the exact same transition (from "bell curve" to "goal/commitments"). Anyway most of these big companies just follow one
by Galanwe 11y ago
Been at Microsoft at the time they made the exact same transition (from "bell curve" to "goal/commitments"). Anyway most of these big companies just follow one another on subjects like compensation and review system.
Frankly, both systems are just a stupid loss of time... It always end up the same: you don't want/are not interested to fill in those lengthy and boring papers, so you just write pretty much bullshit in there. Your manager (usually) being a good guy will help you rewrite part of it so that it's "corporate". And that's it. Nobody really cares.
For those who did not had to write that kind of papers, it's just always more or less the same. You have to answer 5/10 lines on questions like: "What did you do this last quarter?" "What are your commitments for the upcoming quarter?".
90% of all the "commitments" of the department at MS looked like that kind of BS:
1. Describe your project and mention you're happy with it.
2. Say that you plan to work hard to reducing the technical debt (every single MS project has 20 years of debt)
3. Say that you will try to improve the overall quality of the project and work with QAs
4. Find some trait in your personality or skills that you will improve for next quarter. e.g. "I will try to spend more time studying component X so that I can help on that matter".
After some time you don't even pay attention to these reviews. Just copy/paste what was written for the last quarter, change the commitments as accomplishments, and create some new commitments depending on the trending problems in the team.
- InclinedPlane 11y agoIt'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.
- crdb 11y agoWhat 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?
- 1stop 11y agoYou would make the unpleasant-ness a metric you measure.
- rebeccaskinner 11y agoI'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.