Victor Stone

April 19, 1999

Reorganizing teams at Microsoft had become so commonplace that at my regular poker game we invented a variation of seven card stud called "Re-org," which somewhat facetiously mirrors what happens in the workplace. Any time a king lands face up, all players keep their down cards, but shift their up cards to the player on their left. You continue play as if nothing happened, using the combination of the new up cards with your old down cards. Betting strategy is tough in this one, since you end up with a randomly different hand than you started with—at the whim of a king.

One of the most important aspects of the new corporate structure will be losing old habits, including "schedule chicken."

Ah, but now comes the Mother of all Delightful Re-Orgs. The latest high-level and very public re-org comes with some new and interesting aspects. To his credit, Steve Ballmer (who has never asked those closest to him to call him "Sire") spent a fair amount of energy becoming extremely familiar with customer issues—and by most accounts, the re-org reflects an informed response. Most of the public press emanating from Microsoft has dealt with the impact the re-org will have on customers. But there is another, just as important, side to this re-org. Ballmer spent an equal amount of energy getting real and honest data (much of it gathered in private and exposed anonymously) on the internal workings of Microsoft. The re-org reflects his reaction to those findings as much as addressing customer issues. Ballmer explained this in an internal memo to all Microsoft employees, the bulk of which (through no fault and much consternation on Ballmer's part) we all first read in The Seattle Times about the same time it hit our Exchange Inboxes. It might be helpful to illuminate further on this other critical aspect of the re-org.

As far as I can tell, one of the most important aspects of the new corporate structure will be losing old habits that were bequeathed from the days of Microsoft yore, when as a much smaller institution such practices were either legitimate or relatively harmless for the size of the company. Some of those habits become vices, however, as the company scales larger and larger. One such iniquity is a process dubbed "schedule chicken."

Like many of my time, my first exposure to the game of chicken was viewing the classic scene from Nicholas Ray's Rebel Without a Cause. In that scene, Judy (Natalie Wood) and Jim (James Dean) were reaching achingly for each other's outstretched hands while their tears dropped over the Malibu cliffs into the dark abyss below—and onto her (now permanently ex-) boyfriend Buzz (Corey Allen) and his Chevy. You see, Jim and Buzz were matched up to race their hot-rods over the fateful cliff and were supposed to jump out just in the last instant before their cars went over the edge. The first one to jump out of the car would be labeled a "chicken," while the one closest to the edge would win bragging and (implicitly, anyway) Judy plucking rights. Jim jumped out okay, but the strap from Buzz's leather jacket caught in the door handle, and he ended up in the third category of outcome: He missed the code complete date, he slipped the ship, tanked the target date—basically, Buzz bogeyed the bug bounce.

The software project equivalence happens when two or more areas of a product claim they can deliver their features at a ridiculously early date because each assumes the other feature area team is lying even worse about how long it will take them to deliver their features. This charade marches forward past one psychedelic checkpoint after another until just before the goods are actually due. A more seasoned team lead will delay copping to what is painfully obvious for as long as humanly possible, hoping someone else will break first and jump out of their car. The ceremony where the team lead has to admit the emperor isn't wearing any clothes results in a tribal ritual that rivals Inca sacrifices, except that the virgin probably felt better about her fate. It is very difficult for the offending feature team to recover from being the furthest out on the schedule—because now that the truth is known, all everyone else has to do to look good is to finish just before that late team. Even if the schedule chickens end up beating the deadline, it is nearly impossible for the people on that team to beat the stigma of being unable to stay on a schedule.

Schedule chicken wasn't the only thing mentioned for clean up. Here is the short list, la Stone, of other internal processes that have changed as a result of the re-org:

• Distinctively unique ideas are no longer killed simply because they are distinctively unique. Specifically, "If this is such a big problem, how come you are the only one who has ever thought of it?" is no longer a valid reason to kill a feature or product.
• Distinctively stupid ideas, unique or otherwise, are shot on sight by the newly created Stupidity Discipline Task Force, whose main mission is to walk around campus with rolled up back issues of Dr. Dobbs ready, able and willing to use them on the noses of program managers.
• Which brings up the creation of The Task Force to Ensure the End of All Task Forces. In one final desperate grasp at trying to put a structure onto the inherently spontaneous phenomenon called "brainstorming," the new management team has decided that all developers at Microsoft are now part of the Task Force, and will meet four times a week. Everyone will just have to decide once and for all if the programmatic string property of a push-button should be called "Label," "Text," or "Value." The only parameters given to the Task Force are that it keeps its final slide deck down to under 110 slides, and that it covers the strategic implications of its recommendations. The last such Task Force meeting I attended made Carroll's Caucus Run look sane. Even though the final report is due in two years, most seemed happy with the compromise solution: "__szlpstrLabTxtValEx2."
• There will be no more on-campus, on-demand counseling for over-the-hill, over-opinionated-yet-under-researched engineers who seem eager to publicly over-share their neuroses.

This last point seemed to make quite a lot of sense to me. After all, those public ventings are not so much "career chicken" but more of a "career cry for help" that is best left alone.

Would you like that schedule baked or fried?

To give credit (blame?) where it is due, I must admit I've been at companies that work the schedule chicken scam so much better, it makes Microsoft look like a blindfolded, drunken Buzz locked in the trunk. At some scheduling meetings in Silicon Valley, I vividly recall checking the eyes of my colleagues not so much for the truth, but for being bloodshot, with dilated pupils. These were before the days I mastered some of the subtleties of the game, and my nickname was "Three-lines," because I claimed that's how much code a feature would take. In the end, I was off by approximately 297,331. (Hey, they don't call the man-month mythical for nothing.)

Learning how to "schedule approximate" better came later in my career. In a sick and twisted way, managers that become used to this manner of doing business actually become superb schedulers, because not only do they master the art of guessing how long their project will take, but of guesstimating with pinpoint accuracy how long all of the projects in the product will take with remarkably little data (for instance, a list of engineers' names and features they are responsible for). The managers need to do this calculation because they can't trust the other leads to be realistic about their dates up front, but they want to use the extra time they know they are going to have as productively as possible.

Victor Stone is on the Product Design Team in RAD Tools at Microsoft. He says "Don't belong. Never join. Think for yourself. Peace."