Alternatives to "Rank and Yank" stack ranking: rather than playing around with Monad or writing some gadgets, I've dedicated my free time to reading up on what to do after you get rid of stack ranking and try to center on having everyone actually work together to get the best results for the customers vs. focusing on how to politically get ahead to get a good review. I'm also taking some time to contemplate on Deming's points and assess how Microsoft is doing against them. In some ways, we're slipping backwards into the industrial-era muck.
What I would deeply appreciate is real-world experience from people living with stack ranking alternatives. Now, I imagine there's something worse than stack ranking. People have written me saying how great it is to be with companies that reward all-around performance vs. relative performance. They feel appreciated, well compensated, and can focus on doing a great job. Managers feel like they can actually tell people when they do a good job (versus having to hold their tongue should that report be on the edge of falling into the 3.0 bucket and then being confused when that 3.0 review is delivered).
Is peer-review more screwed up and political than stack ranking? Can you incorporate a 360 assessment for everyone? Can manager feedback be constant and actually affect the manager's review? How about if you could provide feedback all the way up the chain? Should everything be transparent: if you're going to keep a stack rank, should you just publish it? If not, why?
Published stack ranks would be demoralizing?
Dude, it already is.
November 9th - Save the Date! Have you ever been to the shareholder's meeting for Microsoft? Well, if you're a shareholder and you want to experience the meeting... perhaps have your concerns heard between bursts of sunshine and smoke... you should put it on your calendar:
The Annual Meeting of Shareholders of Microsoft Corporation will be held at the
MEYDENBAUER CENTER
11100 NE 6th Street
Bellevue, Washington
on November 9, 2005, at 8:00 A.M.
Where are the Lone Gunmen when you really need them? There is no Mini. This blog is in fact organized by Microsoft leadership to make upcoming major changes and shake-ups appear to be organic and therefore easily accepted by the subtly manipulated rank-and-file workers of the company. They even got an amazingly good looking flunky, posing as the blog's author, to meet with a respected Business Week journalist. This blog is a place where people will blow-off steam and, having satiated their anger, be a compliant cog and jump back into the machine. One comment:
Hmm, I am starting to think this is just a PR stunt, this blog is fake.
Followed up into more depth here. I don't know whether to be flattered or insulted. Sorry, it's just me, my beat-up laptop, and a bunch of groovy people taking time to add their points-of-views.
Other random things: one comment following up on my last post:
Mini. Tell us more. Who was it that tried to fix the mess but went to Google instead?
I think I know - search the internal web for the PowerPoint named something like "BillG A Day in the life of a Dev" or such. The author, Mr. Perlow, moved on to Google last year or so.
Yep, that's exactly the PPT and author. The copy I have has the title Day in the Life of a Developer.
One comment makes a really good point about why the Longhorn reset was a good idea:
FWIW, the Longhorn reset was due to the fact that the main folks were distracted with Windows Server 2003 SP1 and then Windows XP SP2. During this "distraction", it was primarily devs that were working on Longhorn, and they were doing so in different branches. Release management had their 3rd string assigned to Longhorn. The testers weren't really even looking at it. The ones that were, were distracted with a new test harness and in learning/writing managed code automated tests. Very little actual quality assurance was going on because those folks were just too busy shipping other good stuff.
When folks finally came up for air and looked at Longhorn, the reset made sense because the Server 2003 code base was rock solid whereas some devs had been mucking with Longhorn unchecked for years. I think the scheme they came up with made great sense... instead of starting with a big mess and integrating changes from a solid code base, start with a solid code base and only merge rock-solid features into it. In hind sight, it's a no-brainer (though it was far less obvious back then).
Right. The issue I, and I imagine everyone else in the company, has is the circumstances that were allowed that led to the reset and that no one was held accountable after the metal had stopped screeching and the fires died down.
Okay, I'm hitting the road for some vacation-OOF. I'll pop in occasionally to follow-up on interesting developments.
(Updated: fixed some formatting and a bad hyperlink.)
No comments:
Post a Comment