Microsoft's New Employee Performance Rating System

After speaking with some folks involved with the recent town hall meeting and reading up on the resulting blogs and articles, I'm kind of surprised at reactions from key bloggers like mini and Scoble. I'll start off by caveating that I have not personally reviewed the new policies, but am making observations based on published materials from the sources I trust listed above.

I understand the happiness over things like bringing the towel program back. I never used them and never noticed them being gone while I was an employee. Still, if I had grown to take something for granted, I'd be happy about getting it back after it was taken.

However, I'm surprised about the happiness over stack ranking and the new comp model. First, my understanding--which may be off base--is that the model is aimed only at improving the benefit to the top performers. From my experience, these weren't people who had morale issues, so I can only believe this model was intended to stem the flow of brain drain.

Regarding the stack ranking, it's definitely not going away. Prior to the change, you roughly had:

1. 4.5-5.0: Rare
2. 4.0: 20%
3. 3.5: 37.5%
4. 3.0: 37.5%
5. 2.5: 5%

Although my experience was relatively limited, I found several things common about these rankings:

1. 4.0+ people are never disappointed and have high enough morale not to complain about morale
2. 3.5 people are almost always disappointed and feel they were barely passed over for 4.0s
3. 3.0 people are disappointed because they feel they're borderline 2.5, except for the handful who received 3.0 due to a recent promotion, group change, asking for permission to interview, etc (they all hate this practice)
4. 2.5 people are not surprised because they already know they should be looking for a new job

People might debate the observations above, and I'll concede the admittedly small sample size I'm working with.

The stack ranking is now:

1. Outstanding: 20%
2. Strong: 70%
3. Limited: 10%

I'm sure that each manager will be still required to stack rank their team, and then pass their proposed stack up the management chain. At some point, the stack will be finalized, and each person will get their result and the comp that is tied to it.

So what's the difference?

When most people land in "Strong", it'll be very easy for management to play up where they landed. In effect, the system has become pass/fail with the occassional "honors" thrown in to motivate the top 20%, along with better cash, stock, etc. Hopefully this will work in their favor by having a much more content majority of non-stars and let the handful that are deemed above the grade to remain in the company.

The one thing that people shouldn't say is that the system has changed because it really hasn't. Some numbers have gone up and others down, but in the end you just get less information about your performance than before from the overburdened management, which is probably better for everyone concerned.

5/21/2006 1:00:13 AM (Pacific Standard Time, UTC-08:00)      Comments [0]  

Setting Expectations And Being Accountable

I came across this posting tonight, via Scott Hanselman's riff on it, and it really got me thinking. In a nutshell, the postings talk about how life has changed over the past decade or so due to the broad acceptance of new technologies (email, voicemail, DVRs, RSS, etc), resulting in increased pressure on people to act on information as it becomes available, lest it pile up ominously.

I'll readily admit that I've often found myself in the past to be behind by a few voicemails, a few tens of DVR hours, a few hundred emails, a few thousand RSS items, etc. In fact, I'll bet most people feel the pressure to act and react to their open channels every second on a daily basis. However, I feel I've managed to find a pretty useful solution to this problem: saying “no” early and often.

Don't get me wrong--if you send me an email that expects a response, you'll get it. If I record TV I want to watch, I will. If you leave me a voicemail, I'll call you back. I think that saying "no" is a critical skill, but one that must be used preemptively.

At SharpLogic, I take on many different responsibilities that sometimes have complex interdependencies and are almost always "important" or "critical" (8+ on a 10 point scale). Every day I find myself with more than enough work to do, and it seems like there's always a ton of projects in the pipeline, which range from customer engagements to network maintenance to accounting to recruiting and so on. Some responsibilities are more important than others. However, every responsibility is still necessary.

One common thing I hear from people is "if I didn't reply to your message from last week, resend it because I delete all mail that's 10 days old". While this attitude may be fine among friends, it's completely unacceptable to a client.

Clients come to us with problems they need solved. In most cases, the problems range beyond software design to require a marketing perspective, and they also often necessitate a level of business consulting. They have tight deadlines (sometimes extremely tight) and, of course, need high quality results.

Sure, this might all sound common, so why do they come to us?

Results. I like to think of SharpLogic as Harvey Kietel’s character Winston Wolfe from Pulp Fiction (if you don’t know who that is, go see the movie).

When someone approaches us, they’re not looking for implementation of a spec. There probably isn’t even a spec. In fact, there probably isn’t even an identified solution. Clients come to us with problems—problems they want to “go away”. They want someone else to think about the problem, analyze the options, determine the best course of action, and deliver a proposal that minimizes the amount of time and effort they need to invest for the results to be delivered. The last thing they need from us is to be filling up their voicemail and email inboxes with tons of micromanagement administrivia. If we’re putting them in a position to say “no” to our requests, we’re part of the problem to begin with.

I know this is starting to sound like a commercial for the company, but I actually do have a point: I say “no” a lot.

In order to ensure our ability to deliver for customers, it’s necessary to be sure we have the time and resources available. If we don’t have time and resources, we won’t take on the project. There’s nothing worse than saying “no” to a customer after you’ve said “yes”—so avoid the problem by undercommitting, underpromising, and overdelivering.

These days my inbox rarely exceeds 25 “action required” items. I occassionally get voicemails, but they're usually some Silicon Valley startup trying to get me to resell their SharePoint Pong clone. Overall, it’s actually very easy to stay on top of everything if you scope “everything” down to a manageable size.

On a related note, I used to always wonder why people who are always “slammed” (way behind in work) ever got promoted. Then it occurred to me that the easiest way to undercommit, underpromise, and overdeliver is to always say you’re slammed. While I understand the motivation, it’s never been a strategy I’ve felt comfortable with since it lowers the confidence your peers have in you. However, it is an interesting, somewhat Darwinian, evolutionary mechanism that evolves the modern information worker. It’ll be interesting to see how it works out.

If you find yourself constantly slammed, you need to ask yourself whether or not you're overcommitted. I wish there was an easy formula to figure this out, but there isn't. While it would be great to get Outlook to automatically delete emails you'd end up deleting anyway, perhaps a better solution is to figure out why you're getting those emails in the first place. Sure, there's always unavoidable spam (both anonymous and from people who should know better), but there is also a level of personal accountability required to resolve the disease, not just the symptom. Sometimes people overcommit without realizing it (like the 35 Futurama episodes on my Media Center) or have a passive aggressive need for control (100+ RSS subscriptions ). Being overcommitted is awful and doesn't help anyone, especially those who rely on your committments only to have them broken.

5/17/2006 1:01:26 AM (Pacific Standard Time, UTC-08:00)      Comments [0]  

Our LEGO Project Mentioned On CNET

http://news.com.com/Microsoft+extends+tool+giveaway/2100-1007_3-6062716.html?tag=nefd.top

For everyone who emails me weekly asking if it's available yet, the answer is now "yes".

If you decide to play around with it, be sure to read John Wingfield's tips & tricks paper that will help you stay sane if you run into any problems getting things set up. Pay extra close attention to the infrared section as it just may save your life.

We really pushed the limits of the integrated ("tethered") programming model for the MINDSTORMS, so there are some things that might seem non-intuitive when you look at the library source. One of these days I hope to write a post about some of the major challenges we had to overcome, as well as the optimizations that make it usable. The library isn't right for every LEGO programming scenario, so take a look at the capabilities of MindScript and other "autonomous" offerings when picking a solution. If your solution needs to interact with a PC (such as to track a movement map or receive user input) then I think this project is the best solution available.

4/19/2006 10:32:01 AM (Pacific Standard Time, UTC-08:00)      Comments [0]  

Quick & Dirty x64 Porting Fix

I've been porting a native app to x64 (64-bit Windows XP) and having some headaches. In particular, I was running across this error:

This application has failed to start because the application configuration is incorrect.  Reinstalling the application may fix this problem.

Ironically, the app in question was part of the install process, so it definitely wasn't an installation issue.

After a few unsuccessful minor tweaks, I ended up creating a new "Hello World" app with VS 2005 on my 32-bit dev tablet. Sure enough, I got the same error when running it on the fresh 64-bit. After a little investigation, I found that I was able to run the app by not embedding the manifest (set "Embed Manifest" to "No" in Configuration Properties | Manifest Tool | Input And Output of the app's properties dialog), which is done by default.

I wouldn't recommend using this as a basis for a port, but it can help you get the app up and running quickly.

4/12/2006 8:44:20 AM (Pacific Standard Time, UTC-08:00)      Comments [2]  

I Can't Leave For A Single Week?!?

I was in Beijing last week, and look what happened while I was gone:

Ashton, am I being punk'd? Anyway, if I see Tom or Katie, I'll ask where your car is.

4/12/2006 2:50:17 AM (Pacific Standard Time, UTC-08:00)      Comments [0]  

Top Ten Most Annoying Recorded Messages

There are few things I've agreed with more than this list: http://www.vocalabs.com/resources/blog/C1672660030/E20060403162858/index.html.

4/4/2006 9:34:34 PM (Pacific Standard Time, UTC-08:00)      Comments [0]  

Team Hanselman and Diabetes Walk 2006

Scott gives a ton to the community (such as being lead dev on DasBlog [the app that runs SharpLogic's blogs] and chairing the Portland Code Camp). If you can, help him out: http://www.hanselman.com/blog/TeamHanselmanAndDiabetesWalk2006.aspx

3/20/2006 12:00:23 PM (Pacific Standard Time, UTC-08:00)      Comments [0]  

The Tale of Two Jimmys

Scott brings up some good points about the future of America: http://swigartconsulting.blogs.com/tech_blender/2006/03/h1b_visas_and_t.html. I love "HIS NAME'S NOT JIMMY!!! THERE ARE NO JIMMY'S IN CHINA!!!"

While I completely agree with Scott regarding the number of no-ops our country regularly produces, I also have a great deal of confidence in the future thanks to programs like H1B, which continually raise the average IQ and work ethic of our workforce and genepool. For the record, the H1B process makes sure you've given US citizens a fair opportunity to take on the job and requires you to pay the prevailing wage for a region, so it's actually more expensive to hire using H1B (after you account for legal and filing fees).

However, if we could also export one dud for every rock start import, that would be great too.

3/20/2006 11:32:24 AM (Pacific Standard Time, UTC-08:00)      Comments [0]  

I'm Starting To Get The Hang Of Fatherhood

Check out these "Before" & "After" pictures:

3/18/2006 11:24:04 PM (Pacific Standard Time, UTC-08:00)      Comments [0]  

Method Of The Day

Do you find that PathMakeUniqueName doesn't meet your needs? Perhaps you should try PathYetAnotherMakeUniqueName

I can't believe I never noticed this before.

3/13/2006 3:52:21 PM (Pacific Standard Time, UTC-08:00)      Comments [0]