One major thing I learned from 360 reviews is how bad developers are at judging each other or their manager.
I've had employees on probation for lack of productivity judged as excellent by their peers because of their ability to socialize their "abilities". I had the best developer on my team (a 10x developer if ever there was one) get slammed on technical ability rankings because of his prickly personality.
My VP and I used have quite the chuckle at all my "strengths" identified by my team and peers ... because they liked me and I was effective they attributed positive characteristics to me that I did not have.
I once had a similar experience - in an interview situation. (I can be likeable in person, just not in comments...)
The guy was attributing statements to me, from the conversation we were having in that moment, that i had never said. He would even say "what you said, or what you were going to say..."
I found it extremely bizarre. I am a pretty precise person, and I wanted to correct him but i realized it is pointless. the lesson i take away was powerful - if people "like" you there is almost no level they won't go to make it work out.
one thing we can do about this is cry about it. the other thing we can do is to figure out how to "hack" likability. i think my mother taught me most of the basics already.
of course - much easier to do this for one hour in an interview, than for an entire year at a job. but there is something to be said for smiling, a few kind words, and then ... graceful evasion of everything else when you want to do real work.
Oh but you can. The unfortunate thing is that keeping on faking it, while possible, is very hard.
People's ideals generally move into conformity with their actions, not the other way round. That's one of the myriad reasons being a spy sucks. If anyone reading was following the police infiltration of left wing groups scandal in the UK, with added sex and dead babies identities the unit involved had a policy of only using married men after one guy never came back. Probably gone native.
Likability is underrated. Someone who is easy to work with, improves workplace morale, and makes other developers feel comfortable at work is a valuable asset. Certainly, it shouldn't be a substitute for technical ability, but it can be a very significant complimentary attribute.
The problem is when likability affects how someone reviews your technical abilities. It should be a separate category, but most people would have significant trouble disassociating the two; more so if you're friends with a coworker.
Is it so important that the individual components of a person's performance be evaluated individually? What about someone with exceptional technical abilities who uses those skills to ensure that blame for potential failure is always assigned to other people, rather than focus those impressive skills on the success of the overall project? Is it so important that person receive recognition for their technical skills?
If someone's social behavior jeopardizes the success of projects they work on, then perhaps it doesn't matter how technically competent they are.
I understand your point, and I agree that cooperation, friendliness, humility, etc. are all extremely important skills in any engineer or developer, but I think there is some value in looking at the two things distinctly (technical and social).
As a counterexample to yours, what if someone is very friendly, witty, and amicable, but is severely lacking in technical skills? Perhas they are not even remotely pulling their weight in projects, resulting in friendly coworkers essentially doing their work for them and covering for them? In such a case you'll want to know that their technical skills are below what they should be.
The answer to your question is probably "no". However, most of the discussion was in reference to the stack ranking at Microsoft, where people's pay was being determined by how well they were ranked by their peers. If you were generally likable, people might also say that your coding skills were better than they really were. So, I think that you're right, and it's a good reason why the stack system didn't work very well.
Except Microsoft doesn't stack rank people based on peer feedback- it's based on all the leads getting into a room and stack ranking their directs.
It's very possible to have a bad stack ranking but excellent peer feedback.
With this system, someone who delivers very well, but undermines other people or projects they work on would likely receive a high stack ranking, but poor peer feedback resulting in private discussions. People in charge of managing said employee may ignore the problem, attempt to place the employee under people who will help them address social problems, or quietly find a way to move them to a different org. It's quite likely none of this shows up in stack ranking.
You can't dissociate parts of an individual just like you can't say that this part of the clock is so so but the alarm bell is great. What counts is the overall, if I may say holistic proposition of what you are evaluating. Does the person fit well in the team? Are they bringing value in one way or another ? It shouldn't be that important to evaluate the specific skills of a said person, but at least recognize what they achieved (or missed) and try to understand why, and then make a picture out of that. Likability cannot make up for actual results (or lack of), or at least not very long.
Agreed. Team work is critical, but likability should affect the soft rankings only but instead had an overall positive or negative effect, even on technical skill rankings.
How would you feel about a team of only eminently likable people, none of whom could produce anything of value but all are very well liked, because this is the end game to rating likability.
360 isn't perfect but it's better than the alternative.
You're basically saying that those who worked daily in close interaction with the 10x developer and had to work with the code that developer produced, had lower regard for his technical ability than a manager who presumably is further removed?
You can't ignore the social aspect. A team with social frictions isn't going to work as well as a team that enjoys working together. Obviously just being social isn't enough but a strong team needs a combination of the social and technical aspects. Also 360 should mean going beyond the team, so the manager should be evaluated by his peers, his managers and his team and technical people on the team should be evaluated by members of other teams they work with.
Yes, I know what a 360 is, I've participated in them.
In the situations I indicated I was also a developer on the team so I knew how productive and skilled the 10x prickly developer was. His peers ranked him high on technical skills but only as high as more amicable and lessor skilled peers.
I'm not saying I ignored the social aspect, in fact that is why I called him "prickly". I'm just saying that, while his teamwork related areas were properly low, his technical areas were improperly low because of this halo effect.
I swiped the Roman Evaluation Method from Luke Hohmann. During interviews, a No from one is a No from all. Self selecting teams is one of those agile advices.
If your prickly superstar was chosen collectively, he would have been given a lot of latitude. Eyes wide open kinda thing.
The only sticky interpersonal problems I've had is when some higher ranking genius assigns people to my teams, mostly unwanted and unwelcome.
And sometimes just plan bad soup. People good individually, bad together. Like when the boss assigned an outspoken Lebonese and an outspoken Israeli to my team. They got along as well as peanut butter and lug nuts.
Self-selected teams while good from that perspective actually have a huge downside: politics and pleasing your friends.
Next thing that happens is people start choosing members based on how much comfortable they are (which doesn't translate into technical skills and delivering stuff) or start talking to each other, trying to convince people.. this sucks!
While it might work for small companies with not much variation in technical skills and sociability between employees.. for anything else it's kinda hard.
Plus, that initial list of 2-3 employees that start talking and picking others was selected by someone, wasn't it? And the list that they can pick from was also selected, no?
I think if you need a team of 10 and you have 30 possibly good candidates within your company (and they are all available to move to your team).. sure, why not. You as a manager already pre-selects a bunch of people and then let your team members filter it even further.
But putting that responsibility from the beginning solely on the team members.. I guess that's risky. But anyway, how often does that happen?
If we are talking about selecting 1-2 people for a already formed team than fine.. of course other team members should do it (but that's mostly the norm in a lot of companies.. the manager/tech lead runs the resumes through people he/she trusts, ask them to participate in interviews.. no big difference there).
No, but I know exactly what you mean. Years ago I was on a team where the "super star" was assigned all new work. The rest of us had to fix the bugs in their code.
At the finale, 5 people were doing nothing but fixing bugs in the "stars" previous projects. That's when senior management finally clued in to the problem and fired both the manager and the "super star".
Yeah, this is why I kind of like project ownership even though it's now considered out of fashion. If you create technical debt, you own it and it's your future productivity that takes the hit. Eventually your productivity grinds to a halt as you fix problems in the crap you wrote before.
I look at it as technically informed product ownership - merging business and technical domain knowledge to make the right tradeoffs. How else can you execute effectively?
I've always been highly sociable compared to my other coworkers and have also noticed I get attributed things that weren't really accurate. Notably non-technical coworkers seem to think I work at break-neck pace when I really just work at pace with everyone else, most likely because I actually talk about what I'm doing with them more often.
What makes you think that your judgements are any better than theirs? How do you judge performance? Do you look at code? Or do you simply go by how many feature check boxes they get through in a given time frame?
edit: and I don't ask this to be insulting, but judging performance is a very difficult task and I've never seen a reliable methodology for doing it. Thus, I'm naturally extremely skeptical when someone claims that they can do it better than others. Especially so when it includes broad generalizations about a group of people.
I'm usually one of the strongest developers on my team, even when I'm managing. It's one of my strengths and why I stay with small companies. It also means I'm qualified to judge the technical skills of my developers, I know how long it should take.
People who think judging performance is hard have a broken development methodology or no technical chops.
That's also why I included the comment on my own rankings; I have some pretty serious weaknesses that were ranked as areas of strengths by my peers and reports.
>People who think judging performance is hard have a broken development methodology or no technical chops.
And this is exactly why I asked the question. Here you have judged me, since I said judging performance was hard, on both my development methodology and technical chops. Yet you know nothing about me at all.
The problem of evaluation is an important one, and one I'm always interested in reading more on. Unfortunately the strategy of taking one's self as a gold standard isn't exactly what I was looking for. It does seem obvious that being an expert in your domain is a necessary trait to be able to evaluate others, but it's not at all obvious that it is a sufficient trait.
The idea of multi-source feedback seems intuitively good, despite the conflicting research on it. That more input will expose biases or inaccuracies is a decent hypothesis. On the other hand, judgment from a single person seems highly error prone. Whatever faults that one person has will never be exposed and reviews seem almost guaranteed to have bias.
In the end, I'm left with no idea why you so quickly discard the reports of your peers.
I've never had a problem judging performance when I was doing my job right. Any time I've been unsure it's because I was either not managing the team properly or did not have enough technical knowledge to evaluate the estimates and claims (e.g. this took longer because of X and Y).
I know you can manage performance in a way that allows evaluation even if you don't have the technical chops to evaluate it technically, because I have seen technically weak peers do a good job of it.
I didn't discard the reports of my peers. I noticed a trend of the peers who liked me rating me higher in areas of weakness (as perceived by both myself and my boss) than my skills deserved.
Data that contains some bias is not useless if you can adjust for the bias.
Most managers are unable to adjust for their own biases, though.
I'm especially skeptical of managers who evaluate themselves as having above average technical ability after they have asserted how poorly most people evaluate their peers. The necessary conclusion of such an assertion is that people therefore haven't a rational basis on which to judge their own skills relative to others.
People who think judging performance is hard have a broken development methodology or no technical chops.
I suggest you reflect on this. It seems to me that you've convinced yourself that you are good at certain things but there isn't really any evidence supporting your beliefs.
When I was younger, I actually used to think like you - that perf evaluation is easy and a good engineer (e.g. me) would be able to evaluate others easily. Over time, I've realized this is an incredibly complex and nuanced issue because everyone's strengths and weaknesses are so very multifaceted. I am more or less convinced that people who think they have all the right answers simply have a lot of blindspots.
I've been managing teams for more than 20 years. Performance evaluation is easy, somebody is either performing well or they are not and a good manager can tell. One of the reason I like Agile is that if it's done right, the whole team can tell who isn't performing.
Performance analysis is incredibly complex and nuanced. Judging if somebody is performing poorly because they are unskilled or not managed properly or having marital problems is hard. Improving performance is even more difficult because it requires the analysis and a remediation plan.
This kind of thinking throws me into infinite loops. I think I'm not such a good developer, which makes me think that I must be a good developer because I recognize my limitations, which makes me think that I'm not such a good developer because I think I'm a good developer, and so on.
HN has a real problem with people who self identify as good programmers ... there is always a bunch of "no you're not" and "you only think you are" and "people who say they are good usually suck" type of responses. It's pretty weird reaction for a tech site where many good programmers hang out.
The problem is companies are looking for engineers while you are talking about this in terms of programmers. In most companies, it is about shipping and making a difference to the bottom line. It doesn't really matter if you are a good programmer if you are not getting things out of the door / ensuring future dev/maintenance will be pain free. For this programming is a tool, just like planning / estimation / design skills / being likable which helps with mentoring new developers etc. The % might differ, but the net evaluation has to be on the whole. Net results are also based on the big picture - what is your impact on the product? If we go by programming abilities alone, then managers must make base pay, which they don't. Also as you grow senior, the requirements change too.
And I don't know your scale of 'good' programmer either: What do you mean by that? Are you saying you are as good as Linus Torvalds or are you saying you are better than your current peers? I am assuming it is the latter - which probably means zilch in a site like this. Many folks here receive that recognition and over time they come to a conclusion that it doesn't mean much. Which is why you get a lot of naysayers. They aren't doubting you, they are just doubting the general feeling as been there, done that.
I don't think that is it. If you self identify as a good engineer/developer/progammer you get the same response. It's the self identifying thing that's seems to be the problem.
Look at this thread, there are several who are very explicitly doubting me in no uncertain terms. Even doubting the idea that I'm good compared to my current peers.
It's a good description that goes in both directions. 360 reviews are popular because they reduce single-source bias (a subclass of Common Method Variance). Different perspective of an employee can helps account for unique variance in the employees' true performance. From my perspective Ensorceled's comment demonstrate their value rather than their shortcomings.
What's the point of doing a 360 review if you're going to attribute away all the results you don't agree with to bias? Why not just do the reviews yourself and save everyone else from wasting their time :)
I'm not sure why everybody is assuming I toss all of these reviews. They are not useless even when biased.
The reason you do 360's is that you have to take every individual review with a grain of salt. When you have 7-10 reviews the biases start to average out.
Thats a fair comment, but in a similar vein; do you trust your own ability (as manager I presume) to evaluate the work output and business value of the employees? Or otherwise do you trust a / your manager with this?
One thing that is true, is often times the manager has more information about the various reasons for certain choices and goings on in the business, and thus is in a better position to evaluate people.
The question then is just, how do you make sure that manager do not discriminate based on soft indicators (personalities match / clashes / favouritism etc.).
It's very hard to separate emotional liking of people with being able to rate their abilities, since rating for most white collar jobs is so subjective. This is why forced stacking can be so insidious, and also why ratings frequently seem unfair. It's also why office politics creep in to the process. People trade on their likeability because they're not confident that their skills will be properly weighted.
This was seemingly inevitable whether this is actually useful or not. Microsoft has been getting increasing heat about our stack ranking system, both from employees and from external people.
But I don't think stack ranking is our problem. I think our problem is that we value this notion of the brilliant and excellent individual contributor instead of valuing employees that value teamwork and team problem solving. I suspect this is an institutional problem, having been started by exactly that sort of person.
It's this that causes the backstabbing and the mess that people attribute to "stack ranking". Until we put value in changing this culture, I don't see too much changing.
(Disclaimer: my team at Microsoft is sort of odd - we're not in Redmond, and I don't see a lot of this backstabbing that is oft-reported. I do see our managers overvaluing the brilliant IC and I do see my organization undervaluing teamwork, but at least we're not doing that stupid game playing like joining weak teams to get great reviews.)
I haven't seen much backstabbing either, but what I have seen is plenty of people acting way differently than they would if the stack ranking curve doesn't exist.
People are constantly doing stuff to make them "visible" instead of doing what is best for the project. How many features do people fight nail and tooth for, that should be cut, just because if they aren't in the product they won't have anything to show for their work when review time comes around?
People are terrified of making decisions, because if they make a bad one, it's going to look poorly when they're ranked. I don't know if you've noticed this, but our managers tend to give "guidance" rather than outright telling us what to do. That way when something goes wrong, it isn't their fault. They didn't say we had to do it the wrong way and it's our fault for not bringing up that it was wrong sooner.
The first year I was here, I didn't think anything of the stack ranking. It was just one of those evils of working at a huge company. Then I started to notice that people were just doing weird stuff. Calling pointless meetings, making big stinks over small things, and just doing weird things just to create more work for themselves. I realized all of that was just so people could have more bullet points on their list of accomplishments at the end of the year.
Sure, killing the curve won't solve everything and I think there is a lot of truth to what you're saying about not valuing teamwork. I just think that killing the stack ranking is a BIG step in the right direction.
The visibility thing is an excellent point: I've been told before that I need to work on more visible projects. But when I work on very visible projects I get feedback like "provide more leadership".
Isn't it the case the stacked ranking exacerbated the backstabbing issue?
I see this move overall as a positive one for Microsoft - without removing the perverse rewards to screw over your teammates and other teams, the actual cultural fix can't take place.
I think the culture will shift soon - Microsoft, for more than a decade, had no real competitors. They made more money each year whether they executed (see Win2k) or not (see Vista). Consequently, their biggest threat was actually internal. Stacked ranking enforced this, and prevented internal response.
Now that situation is changing (or has changed). Microsoft is looking at actual competition in the form of Apple and Google as mobile and search erode the desktop. On the datacenter side, Amazon and other cloud provider are threatening Microsoft's server profits.
When the heat gets strong enough, there will be a unifying force within the company (or it'll just crumble - personally don't think that's the case).
My point was that no, I don't think stack ranking provides a greater impetus to backstabbing your coworkers than this sort of vague compensation model. In fact, I think a continuous model may lead to more backstabbing than exists now.
Currently, I go into a bucket - let's say I'm a two, for instance - and all the twos get the same compensation. Can I backstab somebody so that I get a two and they get a three? Maybe.
But if we remove the buckets and we have some continuity, where now if my coworker outperformed me and we were both twos... now this coworker just straight up outperformed me. I'm more inclined to want to stab that person in the back so that I'm better, since being almost as good isn't valuable anymore.
Now, it's possible that we'll end up with stack ranking all over again. The previous compensation before the current stack ranking system put you in a bucket from 5-1 where 5 was good and 1 was bad. So... it turns out that we don't change this very much even when we do change things.
In the world outside of stack ranking, you aren't winning/losing against your peers, you are being paid what you are worth. Backstabbing somebody else does not change your worth, it just makes them less valuable than you. So your salary does not change, theirs just goes down.
Far more importantly, I have spent my 25 year career in non-stack ranked companies, and I have never seen the behavior you describe. Yet just about everyone at stack ranked companies report back stabbing behavior. I think empiricism wins over speculation.
It doesn't really matter. Most of the time you don't know which bucket you're going to end up in, so constant back stabbing is the modus operandi to stay on top. I'm more curious about the absence of the formal review cycle in the new model.
I'm saying that: there is a fixed bonus pool for employees. All of this bonus pool will be allocated. Said bonus pool will be allocated in a merit-based way such that those who are deemed "better" get more than those who are deemed "worse".
So yes, employees will indeed be sorted from 'best' to 'worst' by some metric. This is pretty much true of every performance-based evaluation system, no?
Removing the "stack ranking" system refers to removing the 20%/70%/10% buckets from 1-5 that we currently sort into, not the fact that we're doing a merit-based reward.
Thus my point remains: if our review system is a problem (and certainly a great many people seem to think that it is) then this seems like a tweak on the system, not an overhaul. What we're being evaluated on and who is doing the evaluating is much more important than whether we're explicitly "stack ranked" into buckets or not.
Stack ranking is just one part of the many problems in MS's corporate culture. Once it's gone it won't end the politics, they'll just find other outlets (of which there are many). Another big problem is the review system in general, regardless of stack ranking. MS prioritizes highly visible and easy to complete work over more important and more difficult work. This creates perverse incentives to, for example, avoid fixing things that are known to be broken, or even assuming responsibility for them. It's far more beneficial to spin up a new project of trivial value than it is to take ownership of some broken or long abandoned system or tool that desperately needs improvement.
Your analogy reminds me of this I just read the other day:
"Some countries initially felt they were isolated from AIDS, but now
they realize there is no such thing. There is no border, no boundary.
We've learned that walls endanger because they encourage a false sense
of security. Even if you could impose the perfect program for screening
international travellers, infected people will get in, and some of your
own citizens will come back infected. In the meantime, people won't
follow safe sex practices, because they figure they're protected inside
their walls. (...)
One of the major barriers we face in trying to get countries to deal
effectively with AIDS is the tremendous gap between social myth and
social reality. I think closing this gap is a useful step. It's
important to deal with things as they are, and not as somebody would
like them to be. (...)
I have asked a lot of government officials and experts, 'At what age do
young men and women in your society begin to have sexual intercourse?'
This is not prurient curiosity on my part. I'm trying to figure out when
you might start certain kinds of educational programs. The expert thinks
a minute. He may take on a reflective look as he considers his own
adolescence, and he makes a decision. Is he going to tell me when he had
sexual intercourse, or when he should have had sexual intercourse? The
answers are not at all scientific, and frankly, people often don't know
what's going on in their own society in terms of sexual practices and
drug use."
- Jonathan Mann, director of the Global Program on AIDS, from the
book: "Reinventing the Future: Conversations with the World's Leading
Scientists" by Thomas Bass, 1994
Great book. But the (somewhat paraphrased) quote fits rather nicely if
you replace screening with "hiring process" and "career advancement"
with "sexual practices".
How do we want our organizations to work? What should the life-cycle of
an employee be? Can we state that frankly in a way that's both good for
the company and good for the employees? Where do managers go as they
grow older? Up or out? If up, where does the CEO go?
I think that's an accurate assessment. It certainly wasn't stack ranking that made J Allard leave. Microsoft has an inward looking culture because there is so much money to play with when Microsoft launches a huge initiative like XBOX or Windows Phone. Google's "moon shots" and Apple's "hobbies" are not instant tickets to the top of the organization.
Overlaid on those high-stakes struggles for control and prominence are some correspondingly huge egos, whence come dogmas like "Everything Windows."
The Enterprise part of the company suffers less from this because the growth there is more organic.
From the outside as a developer, you can feel the effect of such a drama-driven system as Stack Rank. MS's obsession with perfect backwards compatibility means they can't make mistakes, because those mistakes are forever.
So why embrace a process that seems to celebrate daring? A move-fast-and-break-things approach to projects? You'd think MS would be an analysis-paralysis company, because every MS product needs to integrate with hundreds of other MS products and be supported on oodles of platforms for like a decade.
But instead? We see this crazy wasteful churn of APIs and packages and MSDN Magazine-driven fashions.
I mean, how long will MS be stuck supporting Silverlight? Or Linq2SQL? Or ClickOnce installers? Or the zillion different SKUs of SQL Server and Access?
From an inside perspective, stack ranking was actually hurting backwards compatibility. "I made this cool new feature" gets you a lot more recognition come review time than "I made sure that Sim City kept working in the new version of Windows". That's why no one really takes the time to fix things like the console host, preferring instead to write the fancy new PowerShell ISE.
Still, it felt like BC was always a priority at MS, even if things often slipped by... it just felt like they were trying to maintain backwards compatibility on so many APIs and products in cases where things really did need breaking fixes. But instead of breaking fixes, we get a Whole New Product that is totally better than the old one, but has its own learning curve and its own problems and none of those will get fixed either.
Also, the new powershell ISE is slick (reminds me of Python), but at the same time the near-total lack of integration between Powershell and Visual Studio is pretty surprising. I generally find Powershell a bit disappointing... it feels kind of messy next to C# or Python or plain command-line. I'd probably rather just have a C# REPL with good intellisense. I'm sure one exists.
I think the main problem with stack ranking is that you convince your employees that their personal competitors are their teammates and not actual business competitors.
Any time the best way for me to get ahead is by using "The Art of War" on my peers you have set up your organization for eventual failure.
Generating value for your employer is not a zero-sum game. If I make the company an extra $x and the company rewards me with a bonus of $0.1x that money doesn't have to come from the guy next to me, it comes from the extra $x I brought into the company.
The idea that "there's a fixed budget for raises" or "that money goes into a different pot" is simply a way of refusing while transferring blame to an inanimate object.
Even if the reality is that there is a fixed budget for raises that needs to be awarded fairly, it doesn't logically imply there should be a fixed number of 'excellent' and 'awful' employee reviews to be handed out.
When one person succeeds we all succeed breaks down when you are pushed to succeed at the expense of everyone else. You are supposed to be working for the good of the whole, not just yourself.
Cooperation and team work are also meritorious, but they are not rewarded or encouraged in this type of merit-based system.
I agree with you, but this doesn't address the clever and glib but ultimately content-free argument above. You can stack rank on any criteria - including cooperation and team work.
It should not be a zero sum game. I attempt to pay my team based upon what they are worth to the company; not how they rank compared to their co-workers. You should be able to have an entire team of #1 developers ...
You know what, though? Productivity on a team can be just as separate from people's perception of you (i.e. how much they like you) as individual productivity is.
Imagine this experiment: you have a great, productive team who has one member they all hate (and therefore assume isn't doing much for the team.) You take that person off the team... and the team's productivity plummets.
Yes, that can happen--it's intuitive that that is what happens. But that doesn't mean that it's what does happen, even in a majority of cases. To guess at the result without doing the experiment is to rationalize the result you want to be true. You have to follow the numbers.
It honestly surprises me that MS gets away with having such poor working conditions and team work [1]. I guess the end of stack ranking shows that things are changing at least.
I know lots of people in IT, but somehow no one who works at MS [2]. Its seen as uncool or worse unmoral in my circles [3]. And these people, including me, didn't even know how bad the working conditions are at MS! I always thought of MS to be like one of those 'defense' companies [4]. You either don't really want to work there, because even if the technical challenge and the available resources are great, you don't agree with their mission or you fear that your friends and peers would look down on you. But to make up for that, they have really good work conditions [5]. Thats at least what I hear from people who worked on military projects at Raytheon, Boeing and EADS.
Hope you don't take this comparison as an insult. I think MS makes great things! OneNote, VisualStudio, Kinect, Age of Empires are all great products. And personally, I would have much, much (!!!) less reservations against working for them, than a so called defense company [6].
---
[1] And, I can't help myself pointing out, that MS's version control system is called 'Team Foundation'. New speak?
[2] The exception is MS Research, which is awesome, but thats not really MS.
[3] Most of us were born in the 80's (and many including me in Germany) and grew up hating MS. Even if you wouldn't use computers on your own, everyone including parents and teachers would tell you how bad MS, their products and their business practice were.
[4] Other examples are 'big pharma', tabaco, finances, esp. investment banking. I know people working in all of those industries. They all report excellent work conditions and compensations. Some are ok with the company actions it, some are proud to work there. But all of them look very self aware when they get asked "What do you work?"
The counterexample are jobs like social work, medical care taking, NGOs, academic research and yes, usually engineering as well. Many people want to work their, either because they believe in it, or because it brings them social prestige. As a result the high demand allows for poorer working conditions and less pay.
[5] Salaries at MS are still very good, as far as I know.
[6] Though, DARPA projects are very attractive. I can't deny that.
I'm sure all the stories you hear are true -- for one or even many. It's a huge place and I'm sure there are some teams in that "bottom 20% bucket" of pleasure to work in.
I work in dev in Redmond. All I can say is, for me, it really is a wonderful fun place to work and not at all like the outside impressions.
This sounds pretty good to me. If they actually implement what they wrote about here, I think Microsoft could become one of the better big companies to work at.
(I have a friend who works at BofA. They wanted him to take on a new project that he wasn't interested in. As a reward for agreeing, they went back to his old performance reviews and changed them from "Meets expectations" to "Exceeds expectations" and then promoted him for excellent performance. LOL.)
This is good to see. The whole premise of stack ranking is fundamentally flawed.
Clearly there is a curve that when applied to an entire population shows that there are under-performers. So far, so good, however, the problem is that stack ranking isn't applied to the entire population since it's impossible to normalize the performance of each individual. Instead, companies that stack rank do it on a team-by-team basis, which is a statistically inaccurate sample of the population where there can be a lot of skew.
Since it's up to the manager to rank their employees, this causes a lot of problems. This is particularly a problem if the manager sucks at hiring, or over hires for their team, and there is a lot of chaff. There is a massive incentive to do this, because the more employees a manager has, the more corresponding perceived worth in the organization they'll have. Plus, if it comes time to cull, it's really easy to shield the favourite employees, even if they have performed poorly, without disrupting the organization.
On the flip side, if you're really, really careful about who you bring on board, your team is in a weaker position because there is no one to terminate. This means you get rid of good performers based on bullshit metrics. I saw this happen at a largish virtualization company where one of the best employees on our team was let go because he had some minor HR-ish type issue. This caused a big percentage of the team to be demoralized and ultimately leave.
Sounds like an evil but effective way to combat the BS of stack ranking - keep a couple of obviously subpar staff chained up in the corner ready to be sacrificed at the review altar then replaced. Honestly, I can see the benefits of SR as a once off "clear the decks" purge, but as a continual measure it's insanity.
We will continue to invest in a generous rewards budget, but there will no longer be a pre-determined targeted distribution. Managers and leaders will have flexibility to allocate rewards in the manner that best reflects the performance of their teams and individuals, as long as they stay within their compensation budget.
Is this not in effect the same as a curve? Giving higher bonuses to one person means giving lower bonuses to another. Giving everyone the same bonus discourages high performers from staying (and also working on the same team). People who receive little to no bonuses take the hint to leave, just as if they had received a 4 or a 5. Considering only 10% of employees receive a 4, and 5% receive a 5, I'm thinking that effectively, there has been no change.
If two people are both performing at about the same level, they can get the exact same bonus. In a ranked system one employee must get more than the other, even though their actual output is pretty close to identical.
Not to mention when you make the ratings tied to rewards, as opposed to punishments, you're removing a lot of politics. Stack ranking discourages high performers from working together, as their performance rating is penalized by their proximity to smart people. Because stack ranking is inherently punitive, this also makes these employees less mobile. So not only are you stuck in a team full of super-ninjas who make you look bad, but the stack rank you got makes you toxic when it comes to internal transfers.
A fixed bonus pool won't fix the "everyone near me is too smart" problem, but it at least would give people a way out to another team. An otherwise good employee who rolled the dice wrong when picking teams does not gain a permanent black mark for it.
It also opens the possibility of giving a team of all rockstars, if they're (as a team) performing highly, a bigger reward pool that can be split evenly between them.
I seem to think it's much easier to convince them your awesome team producing awesome products (and taking in awesome money) should get extra money to spend than it is to convince people you shouldn't have to rank any of your employees lowly when they all have to.
I honestly don't even get why reward pools are such a big deal.
I do work for you, I am owed compensation based on terms we've negotiated before I started working for you. From time to time these terms will come up for renegotiation.
There is no need for compensation in excess of what we've negotiated. Sure, I am not one to turn down free money, but understand that this does not affect our normal compensation discussions.
My work is worth $X on the market. I expect that you will pay me $X (or come up with alternative forms of compensation that are mutually agreeable). I will not sign a deal that adds up to $X where part of the compensation is discretionary. My work is worth what it's worth. If it is not up to your satisfaction, you are free to terminate this relationship or renegotiate my pay. You may not unilaterally decide to pay me less than what we agreed upon, and I will not submit to a system that allows this.
Which is to say, you will be unsuccessful if you try to persuade me to lower my base salary on the promise of "bonuses".
I feel that "bonuses" are just ways to hoodwink people who haven't been around the block. Every time I have come across bonuses of this variety, it has been an excuse to lower your base salary. I have never once received the full possible bonus, even though I have been promised multiple times prior to joining the company that "everyone" gets the full amount, and that only very poor performers don't. I have never received a poor performance review.
If you do not pay me $X, whether in salary or in bonuses or in suitcases of bacon, I will leave. I do not give one flying hoot about stack ranks, bonus pools, or any such nonsense. I am not willing to inject uncertainty into my income without a proportional upside for myself.
The purpose of discretionary bonuses is to address imperfect (and potentially asymmetric) information about just how much you really are worth. It can be easier to assess post-hoc.
Whether it actually does this well is certainly an important question, as well as how it can be abused and how frequently that happens, but it seems remiss to rail against them without noting their intended purpose - which, in the abstract, seems entirely legitimate.
If I am not performing to expectations, fire me or renegotiate my salary. There are a great many ways to tune my compensation to my actual determined worth.
A discretionary bonus in this case is simply "you should take a below-market salary until we're convinced you're the real deal, and then maybe you will get the salary difference back". I'm not convinced anyone who isn't desperate will take this deal.
And having experienced the discretionary bonuses at two very large and well-known software companies, I am absolutely, completely, vehemently disinclined to ever enter into such an arrangement again.
For discretionary bonuses to make even the most remote amount of sense, it needs to offer the employee an upside for taking on the uncertainty.
"If I am not performing to expectations, fire me or renegotiate my salary."
Both of these are high overhead, which means harder to tune. Depending on circumstance, that may work to the advantage of the employer or employee, or to the advantage or disadvantage of both.
In principle it needn't require desperation, just confidence that your market salary should be above what you can demonstrate it should be during the interview process.
Again, I'm not speaking to actual practicality - I know in a limited fashion how it has and hasn't worked for me, where discretionary bonuses have occasionally been present but have generally not been a large part of my compensation; I don't have any particular insight into their function / misfunction broadly.
"For discretionary bonuses to make even the most remote amount of sense, it needs to offer the employee an upside for taking on the uncertainty."
Obviously.
Anyone saying "Base + max bonus gives the compensation you expect" is trying to take advantage. It should be "base + expected bonus is marginally higher than the fixed rate you would deserve if you are as good as you think".
Many companies give you a market rate and a bonus (sign on / stock RSU/ cash bonus etc) on top of it to incentivize extra work / ownership.
My case: my base salary is pretty competitive considering the market/location. I also get a stock award on top of that based on my future potential / current work etc. For me, the stock component has been a reasonable contributor to the final net take home.
Essentially: you work hard, you can potentially make 2x-3x your base and this multiplier only goes up as you go up levels.
I am not against discretionary bonuses like the above (obviously :). Come for the base, toil for the bonus.
This is definitely how it should be, the rule not the exception. It tends to seem like the exception in the places I've been exposed to. Its likely my choice centered around this area of the Atlanta suburbs that reinforces my perception.
A healthy organization will always "manage out" people who are not fit for the job. At Microsoft, folks are given the hint early enough that they can explore other internal options before leaving the company entirely.
Though, to be honest, if someone just can't cut it, they will leave the company.
"At Microsoft, folks are given the hint early enough that they can explore other internal options before leaving the company entirely."
Except that it doesn't work. No internal hiring manager will ever allow the interview loop/transfer for the internal candidate with the score 4 or 5 (I think those are the lowest scores in the current model:-). In 99.9% of cases those unlucky who got 5 get laid off by the next review period.
Thanks to the law of averages, a "stack ranking" system isn't harmful as long as the size of the group is sufficiently large. Employees aiming to be in the top 20% of a 5000-person organization are incentivized completely differently from from those aiming to be in the top 20% of a 5-person organization.
I think what they've done here is to allow each manager in the chain to decide how to handle their organization's evaluation and compensation. You could be VP of a 500-person division and instruct your directors and managers to rank everyone in your org in a single pool; or you could delegate to your directors and tell them to do what they think is best for their groups within their own individual budget constraints, which you assigned.
This assumes that everyone within such a large group would end up ranked accurately.
But the truth is that when you assemble such a large group, you end up comparing apples to oranges. Jane works on a doomed software project and valiantly manages to salvage some of it for other efforts, but management ultimately looks at her project as a failure and has trouble disassociating her work from the result. Meanwhile Bob works on a fairly straightforward hardware project that gets completed on time and within budget, but not necessarily as a result of his actions, and looks like a "team player" who gets rewarded as such.
Assigning a single scalar value ("top $x%") to each of these people necessitates ignoring a huge number of important differences both personal and contextual. Small groups with similar functions allow you to make more meaningful comparisons but only at the cost of ruining the statistical basis for making those comparisons in the first place.
The whole problem with forcing a predetermined model on your organization is that performance appraisals should be an empirical process where the observations peers and management make determine the model that is ultimately adopted (and which will guide future hiring/firing decisions). Forcing a predetermined model onto your organization gives you no data and leads to a self-fulfilling prophecy at best and corruption and politicking at worst.
Critical question unanswered by the letter: Is the bonus pool for a team primarily fixed in advance as a law of nature, or primarily determined by team performance as a whole, at the end of the period?
If it's the former, you're right and the details of how individual bonuses are assigned don't matter much.
The latter however would could up real opportunities: a team that gets together and delivers beyond expectations could all be generously rewarded instead of having the weird fight over who was the individual star performer that gets all the credit.
At least now there is a 'base income' of sorts, and if you are unsatisfied with your job and/or the bonuses you get, you have ample time to find another job. You also have the opportunity to try to improve. This is a great improvement over 'pack up your shit and leave.'
Bonuses must be distributed in some manner, and at most companies it is ultimately zero-sum. Giving one person a higher than average bonus means somewhere in the company (maybe on your own team, maybe someone across the world) will have to get less.
There difference is, theoretically, some teams could all be composed of high performers, and other teams disproportionately of low performers.
The forced curve before meant that every team needed to assign x% as high performers and x% as low performers.
Now, how you assign the high and low performers, from a limited pot of 'rewards', when every manager is going to want most of his team to be considered high performers -- well, that's what the 'forced curve' was intended to deal with. But I don't doubt it also led to increased competition and politics and decreased teamwork, as the one well-known critique of it suggested.
Stack ranking is created by management's inherent inability to trust people.
And that, in turn, is created by management's inability to trust in their own abilities. This is proved to be true in case of Ballmer and overall Microsoft's performance while under his leadership.
These changes are surely a positive sign for Microsoft.
I saw the downfall of stack ranking immediately after a company I worked at was acquired by Microsoft. The workplace changed within a month from one focused on teamwork and support to Lord of the Flies. When the only way you can succeed is by being "better" then someone else you are forced to step upon others.
I believe that this is also the effect of working for a public company with a stock that hasn't moved in price in 10 years.
Seen the same - work turned into a Survivor gameshow. Instead of concentrating on the product, everyone formed alliances and ganged up on the less-liked people. Everybody was so focused on politics nobody cared about the product anymore. Then the product died. I still don't think our MBA execs learned a damn thing from the whole fiasco, I'm sure they're somewhere else getting paid big bucks to run some other poor teams into the ground.
I've seen this a few times at MSFT. Except that the product didn't really die because nobody wanted to take responsibility for the actual killing. And every now and then there would be a re-org, the former exec would "move on" to his next atrocity and a "recycled" exec would go in front of the team and declare his passion for the product and that this time it will be different.
Interesting timing given the article and discussion yesterday [1] about other companies using stack ranking. I wonder (and to some extent hope) that the others follow suit.
Managers found out this morning. It's possible he was part of a pilot program and had early knowledge, but I suspect it's a coincidence. If anything, having early knowledge would likely have kept him from writing that until after the new Microsoft program was announced.
This is absolutely great for Microsoft and its employees. Grade by curve creates internal friction that is harmful to the team. I am a manager in a large company. I always suggested to grade by performance against job level. There is written requirement for each job level, it is relatively easy to measure against the written description by both managers and peers. Everyone has incentive to get salary raise, bigger bonus, promotion. There is no need to use internal competition to add more pressure.
On the other hand, the lower 5% people only cost about 2% of companies spending. It is not even worth to worry about it. You need to interview equivalent to 50% of employee count to replace that 5%, plus whole set of HR bandwidth to handle it. Microsoft has been losing a lot of value to fire lower 5% while keep a lower 5% CEO at the top for so many years.
I wasn't aware that US companies ranked employees and used rankings when purging the workforce (when I think about it it's a pretty obvious idea). In countries with stronger labour laws "underperformance" basically isn't a reason to fire someone. The employer is responsible for the employees performance (training etc.). This can be frustrating in the software business when just a few really poor performers can really sink a team. Obviously forming a really elite team in the US is easy, since you can purge from the bottom, provided you don't affect morale too negatively. But how do you do it in countries where firing for underperformance isn't an option? It's really hard to get away from a bell-curve team.
I think that's really subjective. There are always ways to abuse any kind of system.
Take for example working hours. A country with strong labor laws will usually prohibit employers from making employees work more than x hours a week, and if they do that they have to pay for overtime. That will make some people happy and productive because they will feel safe having protection from the system. But some people will abuse it and slack off.
On the other hand, if you don't have control over that you might end up in a situation where people are only considered good employees and productive if they work crazy hours all the time. Instead of being abused by employees, the system will be abused by the people at the top.
And I guess that covers underperformance. Who defines what bad/average/good performance is? Is the guy who does really good work considered to be underperforming just because he works 9-5 and wants to spend quality time with his family instead of making the office his second home? That kind of thing has to be prevented by law.
Can we drop the manipulation of language? Strong is obviously equivalent to strict, the meaning is clear-cut. It's not difficult to use these words and disagree with the principle they describe.
I can't really comment on other countries, but at least in Germany you have a (pretty) difficult time trying to fire somebody for 'under-performing' as long as the person doesn't mess up unrelated things (like repeated misbehavior, e.g. feigning illness, theft, sexual harassment, ..) or your company isn't doing all that well from an economic point of view.
Part of the new program is an explicit focus on frequent feedback. If anything, there ought to be fewer surprises than the current once (twice-ish with midyear discussions) a year feedback.
The risk going forward is that without being forced to a distribution, wishy-washy managers will trend towards the middle. High achievers will be under-compensated, and under-achievers will be overcompensated. The budget hasn't changed, so the same pool of money has to be divided among the same set of people, managers now have more freedom as to how.
>We will continue to invest in a generous rewards budget, but there will no longer be a pre-determined targeted distribution. Managers and leaders will have flexibility to allocate rewards in the manner that best reflects the performance of their teams and individuals, as long as they stay within their compensation budget.
The compensation budget is the key part here. I don't know how this is going to account for:
- Failed products with smart developers and their retention.
- Avg products with very smart developers
- Less 'visible' projects. Those that management don't realize is necessary until you have no one working on it. (This happens a LOT in big companies).
All this can be solved by pumping a ton of money into this as they are alluding elsewhere though.
Overall the fact that they are taking feedback seriously and are working towards a solution is pretty positive though.
But, I think that leadership/true emotional control means that, even if someone is treating you wrongly or criticizing you, you can dissect the behavior, and then appeal to reason.
For example, I appreciate, and even invite, ruthless criticism ("go ahead and insult me if necessary") when getting feedback (on my code, performance, etc.)
The importance of having friends who can say, "you're an idiot - you don't understand X, Y, Z" is high.
Sometimes I dislike when, at previous jobs, I've had to mask the truth simply to avoid hurting someone's feelings. Because, if you hurt someone's feelings, that person will close up to you.
It's nice that now they are going to value teamwork and collaboration more highly, but I don't see the lack of a curve making much of a difference in compensation level for the average contributor. The total size of the compensation budget is fixed, and they have to spend all of it.
Just because now 30% of the staff can fall into the Exceed Expectations bucket doesn't necessarily mean that the budget increases. The money gets divided differently, that's all.
It does seem like a positive change though if they can improve the culture of the workplace and minimize the amount of backstabbing, cronyism and political nonsense.
This is a great move for the company. Especially now that so many competitors have internalized the process. It was the single most identifiable thing that poisoned the culture at the company. It will be interesting to see what they replace it with. The process certainly made it easier to make decisions higher up the chain (even if it was difficult for the managers and their direct reports).
It may also take some of the pressure off of high-level people who previously had their rankings approved by Ballmer. (I don't have anyone specific in mind. Yes seriously.)
This is interesting in the context of https://news.ycombinator.com/item?id=6712717 "Why are Amazon, Facebook and Yahoo copying Microsoft's stack ranking system?" - the feature copying usually goes the other way.
i hope this will curb people from constant backstabbing that I witnessed during my short duration there. It was painful to watch very smart, bright people indulge in really pathetic behavior consciously to 'protect' themselves..
I kinda like what my employer does. There is a 1-5 ranking, but the distribution/buckets for bonus is determined after the reviews are complete. Of course, the concern here is that management "can" slot the buckets in a way that suits them, but I trust them enough to not do that..
Due to this, no one knows "what needs to happen to get X bonus".. everyone is just trying to do their best to get to the highest score and the amount of cash you get depends on what bucket you fall under
Best way is to do away with review and go with equal profit sharing instead. You don't even need to worry about levels/title, just call everyone a Vice President.
If I remember correctly, they promised that before, and all that came out was that "the curve" was still there, but hidden from sight and under a different name.
I'm glad this happened. It was a completely necessary move. I hope it's not just a surface change while they twist things to keep it all going. Backstabbing and not collaborating to ensure you're not the one at the bottom of the curve is no way to work. And having to worry about and deal with backstabbers everyday quickly leads to a toxic work environment. Good riddance.
This is going to open the floodgates of deadwood. Stackranking at least forces hard choices. They just needed to adjust the curve by team performance. E.g. rockstar teams have more exceeds than underperforms and a failing team has more underperforms than exceeds. Under the most recent system the best way to get a review is to be an A player on the B team.
Good for them. I don't like Microsoft but I like to see any company getting smarter. It's hard enough as it is to find and keep good people. And there are pretty obvious alternate ways to identify and expel "dead wood" if that was their original justification for stack ranking.
The last bullet point strikes me as incredibly odd. No ratings? How will managers determine raises and bonuses if they don't have a rating to determine whether the employee is meeting expectations or not?
You're asking how managers will be able to freely assign numbers to individuals according to their performance, without being guided by numbers that the same manager previously freely assigned to the same individuals according to their performance?
Looks like the process will be more peer driven. There'll probably still be ranking to find the top performers rather than weed out the bottom 10, which is good.
I've heard it attributed to former GE CEO Jack Welch [1] who is apparently Fortune magazine's Manager of the Century.
In terms of hard science, unfortunately blind randomized controlled trials are impossible, so it's not possible to definitively isolate causal relationships and confounding factors. "It seemed to work for GE in the 1980s" is the best that's on offer.
I'm not sure how it was developed, but its popularity is credited to Jack Welch, who introduced it to General Electric in 1980. In doing so, GE experienced a "5-fold increase in revenue":
In 1980 President Reagan was elected. In addition to many technologies (e.g., LSI ICs) coming online, the amount of taxpayer debt that the US government funneled into our industrial sector over the next few years was simply staggering.
One should look at where this revenue was coming from and compare GE to other companies in the sector (i.e., other makers of nuclear reactors and jet engines) during this time before drawing conclusions about personnel management theories (of all things).
I've had employees on probation for lack of productivity judged as excellent by their peers because of their ability to socialize their "abilities". I had the best developer on my team (a 10x developer if ever there was one) get slammed on technical ability rankings because of his prickly personality.
My VP and I used have quite the chuckle at all my "strengths" identified by my team and peers ... because they liked me and I was effective they attributed positive characteristics to me that I did not have.