Windows Confidential: Ship It
Who gets a “Ship It” award? You need to have contributed to shipping the actual product—otherwise you’re just writing code.
There’s an award given internally at Microsoft called “Ship It.” You receive this award each time you ship a product.
One of the hidden duties of the project manager is deciding who’s eligible to receive a Ship It award when the product ships. For people who have worked on a project the whole way through, the decision is easy. For people who joined or left the project partway through, though, the decision isn’t as obvious.
The key to the Ship It is the ship: You have to have contributed to the process of shipping code. For programmers, this means not only the obvious tasks of designing and implementing features, but all the other work that goes along with that process. Here are a handful of examples:
- Maintain the code throughout the project lifecycle.
- Address performance issues.
- Debug crashes and failures, even those that aren’t the code’s fault.
- Go through all bug reports and fix bugs, especially the really nasty ones that take a month to figure out.
- Revise code because of an oversight in the original design or a late-breaking feature (and these revisions can be extensive).
- Decide which parts of your feature to abandon. As Larry Osterman notes on the Engineering Windows 7 blog , in a post titled “Engineering 7: A view from the bottom,” cutting is shipping. It’s better to abandon something that isn’t coming together than to risk delaying the entire product by waiting indefinitely for one problem area.
One senior manager told me that after a project is completed and he delivers the Ship It awards, he will occasionally get a piece of e-mail from a former team member saying, “Hey, why didn’t I get a Ship It award? I worked on your project until such-and-such date, and you shipped my component in the final product.”
His response is often something like, “Oh yeah, I remember you. You worked on the team at the start, when the sky was the limit and everything was possible. You wrote a bunch of code, and then you left. We got stuck integrating it with the rest of the product, maintaining the code, fixing the bugs, diagnosing performance issues, dealing with the application-compatibility fallout, debugging all the crashes, all that other stuff that you need to do to ship the product. You were on the project team for the first part, the part where you write code.”
In other words: “You were here for the fun part of the project, and then when the not-fun part started, you bailed. You ate the dessert and left us with the vegetables.”
You know who really deserves the Ship It award for your component? The person who joined the team and was given responsibility for your code. That person wrote up the status reports for the feature, attended the feature meetings, responded to e-mail from people having trouble using the feature, debugged the crashes, and fixed bugs not only in your component but in several other components.
So the answer to, “Why didn’t I get a Ship It award?” is always, “Because we gave it to that other person instead—the person who actually shipped your code.”
The former team member admits as much in the original message: “... and you shipped my component in the final product.” They concede that somebody else actually shipped their component. So there’s no Ship It award for them. It’s called the Ship It award—not the Code It award.
Adam Barr has a nice rundown of the Ship It award on his Web site. The first comment on his article includes the early history of the award. The controversy that surrounded the Ship It award at its introduction has long since died away. Now, it’s just a regular part of the job.
Raymond Chen's Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history, Win32 programming and how not to make a presentation to an executive.