Showstopper the breakneckrace to create Windows NT and the next generation at Microsoft

1. 1Name the pattern before you judge it. Immersion is the state where work becomes the single focus and everything else erodes. The source lists the erosion in order: friends fade, marriage ties fray or rip, children are neglected or deferred, hobbies wither. Write those four lines down for each person and mark each one holding, thinning or gone.
2. 2Count hours and contact, not feelings. The source's hardest data point is numeric: Haluptzok worked upwards of seventy-five hours a week before the December release, and some days his wife saw him for fifteen minutes in the morning. Record weekly work hours and minutes of real contact with partner and children. Judge the person by those two numbers.
3. 3Separate normal mode from ship mode. Chenoa's anger flared again after Haluptzok 'had a bad month in ship mode.' Mark which weeks are release crunch and which are baseline. Then check whether the crunch level has become the baseline, as Cutler's 'do your best, all the time' standard implies.
4. 4Identify what is driving the immersion. The source gives four drivers: money (millions in Microsoft stock bonuses for those who succumb), insecurity ('do-or-die' pressure, with no alternative), pride and meaning ('I had only one concern — to ship this product'), and the leader's norm (Cutler 'rejects the distinction between work and leisure'). Name the dominant driver for each person. Money-driven and fear-driven immersion call for different conversations.
5. 5Audit the leader's modeling. Cutler ranks his priorities 'work, play, friends, family, in that order.' He rarely saw his three children, rarely encouraged coworkers with family problems, and avoided the subject. If the leader neither limits work nor speaks about the cost, the team reads that as the rule. Record what the leader says and does about off-work life, and whether anyone dares push back. In the source, resisters risk wrath or loss of respect.
6. 6Treat the household's signals as data. Chenoa wrote a seven-item list of grievances, then used the 'Box' for stray items. The Box did not fix his prolonged absences. It only managed the clutter. Log each household workaround and ask whether it addresses time absent or only the symptoms.
7. 7Test whether rewards are repairing anything. The $70,000 from the first stock sale bought a house a few minutes' walk from the office, and Chenoa was overjoyed. Her contentment was short-lived. Rewards that shorten the commute leave the absence intact. Check whether the money bought time or only trappings.
8. 8Ask the honest-cost question each quarter. Leigh Manheim asks it: 'Be careful what you wish for... When a company has you, they want you. They want a big piece of you.' Have each person answer in writing: what has this project cost in the four erosion areas, and would they choose the same trade again? Answer it before the next ship mode starts.

Haluptzok, an NT programmer, worked upwards of seventy-five hours a week pressing toward the December release. Some days his wife Chenoa saw him for fifteen minutes in the morning. Step 2 shows the problem in numbers: near-zero contact. Chenoa had already written a seven-item list of grievances (dirty plates, newspaper on the floor, the garbage, 'Even your three- and four-year-old daughters do better than you'). After a bad month in ship mode she switched to the Box, putting his stray books and clothes in a garage box. He noticed about a week later and spent an hour cleaning it out. Step 6 shows this did not change his absence. His first Microsoft stock sale netted $70,000 after taxes, which paid for a house a few minutes' walk from his office. They moved at the end of October 1991 and Chenoa felt the two years of sacrifice were worth it. The relief faded after the next bad ship-mode month. She was still alone with two daughters in Redmond, with no relatives nearby. Step 7 reads this as money buying proximity and a nicer house, but not hours at home.

• If weekly hours sit near seventy-five and household contact is down to minutes, treat it as an active sacrifice state and not a rough patch. Name it to the person directly.
• If the crunch period has ended and hours and contact have not returned to baseline, the immersion is now the norm. Act on it the way you would on a mode that never switches back.
• If the main driver is stock-bonus money or do-or-die insecurity, expect the person to keep paying the cost. Do not rely on their self-report that it's fine. Check the numbers instead.
• If the leader ranks work first and avoids family topics, assume the team will not raise their costs. Create a separate, safe channel for it, and do not count silence as health.
• If a household fix only handles symptoms (a list, the Box, a nearer house) while the absence continues, escalate to the time conversation. Do not add another workaround.

• Mistaking reward for repair. You assume the stock money and bigger house settled the cost. The tell: relief followed by renewed anger after the next ship-mode month, as with Chenoa.
• Reading silence as consent. You think nobody complains, so the team is fine. The tell: resisters risk the leader's wrath or respect, so they stop speaking, and the cost shows up only at home or in marriages that 'fray or rip apart.'
• Leading by example in the wrong direction. The leader says 'I never asked more of anyone than myself' and takes that as fairness. The tell: his own children seen mainly in summer, and the admission 'I don't think I did a very good job as a father.'
• Treating lifestyle as a trapping. You decorate the sacrifice with wealth (a tennis court nobody has time to use, a lakeside home where the owner sleeps at the office and calls himself 'homeless'). The tell: comfort items present, use of them absent.
• Dismissing the cost as universal. You tell yourself any big company would demand the same. The tell: Manheim's own 'would it be any different?' goes unanswered, so the decision is never actually made.

• ▸Person / role: name the team member and their function on the project.
• ▸Weekly work hours (baseline vs ship mode): record both numbers and the date range.
• ▸Minutes of real contact with partner/children per week: use the actual figure, as in the fifteen-minute mornings.
• ▸Erosion check (friends / marriage / children / hobbies): mark each as holding, thinning or gone, with one concrete sign.
• ▸Primary driver: stock/money, insecurity, pride in shipping, or leader's norm. Choose one and give the evidence.
• ▸Household workarounds in use: list every list, box or fix and whether it touches time absent or only symptoms.
• ▸Leader behavior observed: what the leader said or did about off-work life this month.
• ▸Honest-cost answer: one written sentence on what it has cost and whether they would choose it again.
• ▸Next action and date: one change to hours, contact or the leader's message, with an owner and a review date.

1. 1Set a goal large enough to sustain exhausted people when nothing else will — Cutler's team runs on 'only the enormity of their goal' after years of delay. State the stakes plainly: a year behind, team tired and frustrated.
2. 2Put programmers in charge of projects so they both manage and program; refuse to let professional managers who can't evaluate schedules or designs hold sway. This is Gates's deliberate structure.
3. 3Run code reviews as adversarial proceedings: begin with simple questions, then turn the screw, insisting you grasp the problem better than those paid to answer it. Spare no one's feelings.
4. 4Permit the pressure to be two-way — let engineers defend themselves or scream back, so long as you can do the same. Gates doesn't mind the shouting if reciprocal.
5. 5Lead by doing vast amounts of work and pushing others to match it; let no technical complexity slow your pace, which sets the tempo everyone must meet (Short on Cutler).
6. 6Place deputies near you who can read moods and defuse outbursts with a wisecrack, absorbing the volatility before it halts work (Short handling Cutler).
7. 7Vent stress outward rather than containing it — Cutler's creed — but accept the cost: a kicked wall cracked his toe, a punched stud broke his finger.
8. 8Keep yourself 'running scared': treat complacency as 'the road to ruin' and keep asking 'who is coming to get you,' even after success.

The morning in the Build Lab shows the environment in motion. The build isn't ready, Aretha Franklin plays, a shoeless juggler performs, and Cutler — no fan of either — growls, flings his chair, and storms out. He returns more upset: 'You're wasting the whole goddamn morning not having this goddamn thing ready,' then dejectedly tells the juggler to call if the build ever ships that day. The juggler and chief builder each pop a Rolaid; the day has soured early. The pressure is real: Cutler is a year behind schedule, facing thousands of bugs and doubts about NT's basic design, with 250 tired people depending on the enormity of the goal. The outburst is 'ill mannered but understandable' because 'time means everything to him now.'

• If a manager can't distinguish a promising program from a bust or evaluate schedules, then don't let them run the team — put a programmer in charge instead.
• If an engineer screams back during a review, then let it stand — reciprocal heat is acceptable; one-sided silence is not.
• If reviewers 'who have no business with anything' start poking holes and holding up the project, then treat it as stultifying interference and route around or exit (Cutler left VMS over exactly this).
• If you feel complacent after success, then deliberately re-induce fear — 'you always have to be thinking about who is coming to get you.'
• If stress is building, then let it out rather than contain it — but direct it at walls and words, not into breaking what the team needs.

• Letting bureaucratic review metastasize until 'every Tom, Dick and Harry' can hold up the project — the tell is that doers say 'things became harder and harder to do.'
• Venting into something solid: Cutler hit a stud and broke a finger, kicked a wall and cracked his toe — the tell is physical injury from the outburst itself.
• Mistaking almost-right for success; 'almost means you're still just wrong' — the tell is relief at being close instead of correction.
• Running teams through professional managers who can neither understand nor control programmers — the tell is mutual mistrust between managers and their coders.
• Promising compatibility with everything ('Unix, OS/2, Windows, DOS') to please the boss — the tell is a wish list that quietly multiplies the real work, since running apps is only half the battle; running them as fast is the other half.

• ▸Sustaining goal: the stake large enough to keep a tired team going
• ▸Schedule reality: how far behind, and what everyone knows about it
• ▸Who leads: name the programmer-in-charge for each piece (not a pure manager)
• ▸Review rules: is criticism two-way (can they scream back at you?)
• ▸Volatility outlet: where does stress go — words/walls, not fists into studs
• ▸Mood-reader deputy: who defuses outbursts before they stop work
• ▸Interference check: which reviewers 'have no business' and are holding things up
• ▸Compatibility scope: what did you actually promise vs. the ballooning wish list
• ▸Fear setting: what keeps you 'running scared' instead of complacent

1. 1State the quality standard as a belief everyone holds, not a rule for engineers only. Cutler's yearbook line applies it from management 'on down to the lowest peon': no manager who bends with the front office, no engineer who shorts quality to look productive.
2. 2Give every person explicit license to defend quality against schedule pressure. Cutler's version: 'everyone on my projects gets that license,' and if someone wants to ship before the team is ready, 'we tell him to pound sand.' Write down who may refuse a ship request and to whom they say it.
3. 3Put the most senior person physically at the point where code becomes a build. Cutler moved into the Build Lab, reviewed check-ins each morning and prepared fixes for the next build. His reasoning: 'If I'm in the Build Lab, that tells [the code writer]: I better not check in shit.'
4. 4Review every check-in before the build starts, and drive the build from the change list. Cutler gave builders file-level instructions ('Go to this directory and sync this file') instead of handing them the list. That keeps the cost of a bad check-in visible to the author's peers.
5. 5Make rejection concrete and attributable. Cutler used a 'Size Is The Goal' stamp on feature memos, and he once retrieved code from the trash, corrected it in red pen and returned it to its author. State what is wrong in the code itself, not in general terms.
6. 6Demand candor and punish concealment harder than the bug. Colleagues said that if you try to deceive Cutler 'he won't just let you hang yourself, he'll attack.' Require authors to report their own breakage and justify any shortcut. Cutler asked for assembly code to be ported to Mips 'or justify why we can't.'
7. 7Build in a structural check that forces honesty. Building NT for Intel and Mips in tandem kept programmers 'honest' about portable code. Choose a second target or test that makes shortcuts show up automatically.
8. 8Tie standing to output, not title or talent. Cutler: power in a group 'comes from what you accomplish.' Reward people who deliver clean work, and give praise on the same visible terms as criticism, so the team is not left guessing whether it is valued.

Cutler's Build Lab at NT crunch time. Lucovsky had run the lab for the first two releases and wanted a break, so Cutler took it, though a chief designer rarely moved in with the builders. By the time builders Shannon and Duncan arrived each morning, he was already in his maroon chair reviewing check-ins and preparing fixes. When the day's check-ins looked bad, he greeted the builders with 'What the hell took you guys so long? Get in here!' Then he 'drove,' telling them which directory to open and which file to sync until 'everything is clicking.' Cutler's stated reason: his presence told code writers not to check in bad code, and told everyone that he wanted NT 'built well.' The cost was heavy. Builds rose from a couple to a half dozen some weeks, the lab stayed open seven days a week past midnight at crunch, and Shannon, who said he used to be 'the laziest guy on earth,' worked ever longer hours. His temper was also visible: he walked out when a build was late and snapped 'You're wasting the whole goddamn morning.'

• If a ship request arrives before the team judges the product ready, then refuse it explicitly and say so; Cutler's standard is to tell the requester to 'pound sand.'
• If a programmer adds assembly or other non-portable shortcuts, then require a port or a written justification before the code stays.
• If check-ins look bad on the morning review, then the senior owner sits with the builders and drives the build file by file rather than delegating it.
• If someone hides or glosses a defect, then treat the deception as the larger offense, since Cutler's colleagues said he does not 'forget' being snowed.
• If you correct someone's code, then do it on the code itself (red pen, specific change) and pair it with a visible acknowledgment when work is good, because withheld praise leaves strong performers insecure.

• Accountability becomes fear without information: Lucovsky returned a draft marked only 'NO!' and the author was 'devastated' because he gave no reason. The tell: people know they failed but not why.
• Praise is so scarce that high performers doubt their standing. Roger Heinen kept an old note ('Roger, you really did a good job. Thanks, Dave') in his desk because he was too afraid to ask if Cutler still valued him. The tell: people hoard old compliments or avoid asking for feedback.
• The leader's temper replaces the system. Cutler kicked a wall and cracked his toe, smashed one and broke a finger, and stormed out over a late build. The tell: standards are enforced by mood, and the team manages the leader instead of the code.
• Quality is enforced through total immersion, so the culture burns people out. Zachary reports followers with frayed marriages, deferred children and withered hobbies, and builders working seven days a week. The tell: work hours climb as defect counts are discussed.
• Standards slip when the guardian is absent or distracted. Writers slipped faster assembly code into the Intel version despite Cutler's vigilance, and the Mips version lagged. The tell: shortcuts cluster wherever the senior reviewer is not looking.

• ▸Quality standard: one sentence every role, management included, can be held to.
• ▸Ship-refusal license: who may refuse a premature ship request, and to whom they say it.
• ▸Gate location: the point where code becomes a build, and the named senior reviewer who sits there.
• ▸Review routine: when check-ins are reviewed and what the reviewer drives personally (files, directories, fixes).
• ▸Shortcut rule: what must be justified or ported before non-portable or expedient code stays, and who approves.
• ▸Honesty check: the structural mechanism (e.g., parallel target builds) that exposes shortcuts without relying on confession.
• ▸Consequence ladder: what happens for a first bad check-in, a build break, and concealment, in that order.
• ▸Feedback commitment: how and when the reason for each rejection, and recognition of good work, is delivered.
• ▸Load check: weekly hours and rebuild counts, with a trigger for relieving the people carrying the standard.

1. 1Ship your own work to your own team before customers see it. On NT, the networking group had a dog food deadline of August 31. They finished the first networking version in mid-August, and fellow programmers started reporting bugs almost at once. Set an internal-use date and treat the first internal users as your test pool.
2. 2Accept the faster bug flow and protect the people absorbing it. After the first dog food version, the many reports 'had the salutary effect of speeding improvements, but it made life miserable for the network coders.' Thompson gave his coders beepers so they could answer crash complaints quickly. Plan for the response load before you release internally.
3. 3Record the exact conditions of every failure. The Build Lab's White valued 'reproduceable cases': bug hunters often spent hours aligning equipment to recreate the conditions where a bug appeared. Write down the hardware, the configuration, the symptom, and the timing when you first see it. Treadwell's report included the exact string (3fffffff fffff7), the Compaq PC, and the random 3-minute-to-20-hour interval.
4. 4Narrow the problem by listing what you know. Short, in his lab, made a list of everything that happened before the failure. Build the list first, then test hypotheses against it, including hypotheses about hardware you do not control.
5. 5Keep the pressure on an unresolved bug. Short kept raising the corrupting bug whenever he saw Treadwell and Glass working on something else: 'We're going to fix this because it isn't going away otherwise.' Assign an owner and revisit the bug at every contact until it is closed.
6. 6Widen the search beyond your own code. After three weeks Treadwell and Glass concluded the code was fine. Glass then went to Compaq's engineers and asked vendors about their hardware. An errata sheet from Adaptec finally matched the pattern. Ask suppliers for errata sheets and known-issue lists early, and describe the bug to them in full detail.
7. 7Run fixes through a fast, regular build cycle. White's Build Lab turned out about one build a day, seven days a week, with changes mostly limited to bug fixes. A coder fixed the bug, tested the replacement code, and logged a short summary of the fix on the lab's white board. Ship builds in the morning so testers get fresh code with a full day to work on it.
8. 8Test the way customers use the product. Dunie held that OS/2's tests concentrated too heavily on underlying pieces and not enough on imitating customer stress. He wanted testers to write tests as soon as pieces were specified, so tests were ready when the code worked. Write tests early and make them look like real usage.

On May 26, a Sunday, Treadwell found that his NT network code, used with a certain Compaq PC, put the string 3fffffff fffff7 near the start of every page sent across the network. It appeared at random intervals from three minutes to twenty hours, and it was the only corrupted data on the page. The team called it data corruption, 'a deadly sin, worse in some ways than a crash,' because there was no telling the extent of the damage. After three weeks of fiddling, Treadwell, Kimura and Glass dedicated the third weekend in June to it, with four others helping, and Treadwell and Glass concluded the code was fine. Short kept needling them and made a list of everything that happened before each failure, while Glass worked with Compaq's engineers after Cutler guessed the networking hardware was at fault. In mid-July an Adaptec engineer casually sent Glass a month-old errata sheet describing a bug that fit the pattern. Glass had spoken with that engineer several times over six weeks and had even described the bug in detail, yet he had been told it was unknown. The bug cost Treadwell a month, and the delay contributed to Thompson's team missing its dog food deadline. The lesson is to query hardware vendors early, and to ask for their errata in writing.

• If a bug is intermittent and corrupts data, then treat it as more serious than a crash, because the extent of the damage is unknown, and give it dedicated time, as the team did with a full weekend.
• If you have checked your code for weeks and believe it is fine, then widen the investigation to the hardware and its vendors, as Glass did with Compaq and Adaptec, and as Cutler suggested.
• If a bug report cannot be reproduced, then send it back for the exact conditions, because hours are otherwise lost recreating the setup.
• If a build or release lands late in the day, then move it to the morning, so testers work with fresh code instead of rushing before leaving for the night.
• If internal users start reporting many bugs, then expect the fix rate to rise and staff the response (beepers for crash complaints), because dog food speeds improvement at a cost to the people fixing.

• Leaving testing to customers. The attitude 'Let the customer test the program' saves the builder time and money but makes buyers see the first release as a gamble. The tell is that bugs first surface in the field.
• Testing only the underlying pieces. Dunie felt OS/2's tests did not imitate customer stress. The tell is that the product passes internal tests but fails in ordinary customer-like use.
• Assuming the fault lies in your own code. Treadwell and Glass were sure the code was fine for weeks while the true cause sat in third-party hardware. The tell is many weeks with no solution while you keep inspecting the same code.
• Vague bug reports. Without recorded conditions, hunters spend hours just aligning equipment. The tell is a bug that is 'sometimes' seen by one person and cannot be recreated by another.
• Staffing no one to absorb the dog food response. Frequent network crashes drew yelps from victims and made life miserable for the coders. The tell is crash complaints sitting unanswered because the developers are busy fixing.

• ▸Symptom (exact output): copy the corrupt or wrong result verbatim, such as the character string seen.
• ▸First seen (date, build, who): record when and where it first appeared.
• ▸Conditions in force: list the hardware, configuration, and steps active when it occurred.
• ▸Frequency and interval: note whether it is constant or random, and the shortest and longest gaps seen.
• ▸Severity: mark whether it is a crash or data corruption, where damage is unbounded.
• ▸Known facts before failure: list everything that happened before the failure, as Short did.
• ▸Hypotheses tested and result: for each guess (code, hardware, vendor), write what you checked and what you found.
• ▸External contacts and errata requested: list the vendors asked, the date, and whether errata sheets were received.
• ▸Owner and next check-in date: name one person and the date the bug is revisited.

1. 1Fix the build cadence first. Cutler insists on frequent builds of NT so his 250 programmers 'eat their own dog food.' Set a recurring build, publish its time, and treat a late build as an incident, because he is angry when it arrives hours late. A build is the unit that measures velocity.
2. 2Make each build testable the day it lands. The sooner a build arrives, the sooner the team tests it, finds imperfections and improves it. Assign owners to run the build against yesterday's tests and log what broke before the next one.
3. 3Treat small lapses as the main enemy. Cutler knows 'nothing slows progress more than a steady accumulation of small lapses.' Track every late build, botched test and missed handoff, and chase each one the same day instead of waiting for a big failure.
4. 4Ship a crude proof of life early, then add controls. The NT team ran a piece of NT code on the i860 in a week. It lacked virtually all its controls but displayed 'Hello World' on an attached screen, and that was enough. Define the smallest end-to-end run that proves the stack works on the target.
5. 5List your dependencies and staff them before they block you. NT's schedule hinged on three: the 386 port, networking and graphics. Cutler could spare no one for the port, so Gates pried one person from the OS/2 team and promised two more. Name each dependency, its owner and its headcount at kickoff.
6. 6Remove tooling drag. The i860 simulator took minutes for what the real chip did in seconds, and buggy debuggers gave a fuzzy picture of the code. Measure how long engineers wait on tools and put programmers on tool-building when the waiting eats coding time.
7. 7Decide on a failing platform quickly and price the setback. On January 2, 1990, Gates, Cutler, Myhrvold and Ballmer agreed the i860 must be replaced by another RISC chip, accepting months of fresh work. Name the swap, absorb the delay in the schedule, and move on.
8. 8Defend the quality line against premature ship dates. Cutler's rule: 'If some jerk somewhere wants to ship before we're ready, we tell him to pound sand.' Velocity counts only convergence on a shippable product, so a milestone that ships broken code does not count.

NT's chip crisis shows velocity under setback. Cutler's team got a first piece of NT code running on Intel's i860 in a week. It had virtually no controls but displayed 'Hello World,' a real milestone. Then the chip's problems grew. It was unreliable, tools were scarce, and the simulator ran on a 386 at a snail's pace, so minutes of waiting replaced seconds of work. Six weeks after the party with Gates, Cutler began searching for a replacement and preferred a Mips chip, knowing the switch would set the team back badly. On January 2, 1990, Gates, Cutler, Myhrvold and Ballmer agreed the i860 had to go, even though it meant absorbing months of fresh work. The same day exposed a second drag: the 386 port, which Gates called NT's 'ultimate platform,' was moving too slowly with too few people. The lesson is that velocity was protected by deciding fast to take a known setback and staffing the lagging dependency, not by pretending the schedule held.

• If a build arrives late or a test is botched, then investigate the same day, because small lapses accumulate and slow progress more than any single big problem.
• If a platform or tool repeatedly eats engineers' time, then price a replacement now. The i860 was swapped despite months of rework because waiting cost more.
• If a milestone depends on a team you do not control, then secure your own staff or a written sharing agreement. Cutler pushed for his own networking group, and Havens's work-sharing arrangement with Rubin's team ended the squabbling.
• If you cannot show the full system working yet, then run the thinnest end-to-end slice, like 'Hello World,' to prove the path before adding controls.
• If someone presses to ship before quality is there, then refuse. A date met with a broken product is not progress toward a shippable one.

• Counting activity instead of convergence: the team writes code but the build does not run end to end. The tell is that you cannot name the last build everyone tested.
• Ignoring a dependency until it becomes a crisis. Cutler focused on the kernel and lost sight of the 386 port, and Gates's complaints on January 2, 1990 came as a surprise. The tell is a critical piece with no named owner or only one person.
• Letting weak tools slow everyone. The i860 simulator and fuzzy debuggers cost minutes per step. The tell is programmers idle or impatient while waiting for the machine.
• Building in the wrong direction for too long. Whitmer trashed much of his code from the months after the Maui trip because his graphics concepts were still evolving. The tell is large chunks of code thrown away and no spec or prototype to anchor them.
• Letting reviewers stall momentum. Cutler complained at Digital that outsiders with no business in the project poked holes and held it up, and Prism was eventually cancelled after repeated revise-or-discard demands. The tell is the plan being revised more often than it is built.

• ▸Build date and scheduled time: record when the build was due and when it actually arrived.
• ▸Build lateness: note hours late and the cause.
• ▸Test result: record pass or fail and what broke, including botched tests.
• ▸Smallest end-to-end proof: describe the thinnest working slice (like 'Hello World') and whether it ran.
• ▸Dependency status: for each dependency (e.g., port, networking, graphics) list the owner, headcount and whether it is on pace.
• ▸Tool drag: note time lost waiting on tools, simulators or debuggers, and the proposed fix.
• ▸Setback and decision: name the problem (e.g., failing chip), the decision made and the schedule cost absorbed.
• ▸Small lapses closed: list the minor slips found and fixed today.
• ▸Ship-readiness check: state whether any pressure to ship early arose and how quality was defended.

1. 1Write the team's single concern in one sentence before any design work. Cutler's version is 'to ship this product. And to make it as good as I could.' Every later trade-off (feature, size, schedule) is judged against whether it makes the shipped product better.
2. 2Put technical judgment in people who can read the code. Gates put programmers in charge of projects so they could manage and program. His reasoning was that professional managers 'could not distinguish a promising program from a bust or evaluate schedules or product designs.' Name one technical owner per component who reviews the actual code.
3. 3Run line-level review that returns corrected work to the author. Cutler retrieved code thrown in the trash, corrected it with a red pen and handed it back. Review means marked-up code, not an opinion on the design deck.
4. 4Require absolute candor about defects and unknowns. Cutler's team knew that trying to snow him got an attack. Make it a stated rule that hidden problems are the worst offense, and have people report breakage the day they find it.
5. 5Write architectural requirements that protect existing users. VMS had to run both new programs and old ones written for the PDP-11 ('backward compatibility'). List which prior behaviors must keep working, and treat any change that breaks one as a defect.
6. 6Treat size and speed as gates with a recorded reason, not as the goal. Cutler stamped 'Size Is The Goal' on rejection memos when a feature greatly increased memory demands. Do the same, but write down what was rejected and why, so you can later check whether the rejection served the final product.
7. 7Cap review at the amount that is healthy. Cutler accepted that 'there has to be a certain amount of review' but resented every Tom, Dick and Harry holding up the project. Name the reviewers and the questions they own, and exclude drive-by objections.
8. 8Add a technical equal when the load exceeds one person. VMS reached ten people with Cutler still the senior programmer. The hire that helped was a senior programmer who proved his technical equal. Pair a second architect on the core before the schedule forces it.

VMS is the clearest case in the passages. In early 1975 Gordon Bell conceived the Vax line and its operating system, VMS, which had to run new programs and old PDP-11 programs: backward compatibility was a design constraint from the start. Cutler was the senior programmer on a team that peaked at ten. He would not ask for help ('When all is said and done, much more is said than done'), so the project's general manager hired a senior programmer while Cutler was on vacation. The newcomer proved to be Cutler's technical equal. The first Vax shipped in October 1977 and was a wild success, and Bell called Cutler the best writer of operating programs in the world. The same project shows the review limit. Once VMS mattered to the company, managers piled on, and Cutler complained that people 'who had no business with anything' were asking why he was doing this or that. Cutler accepted review in principle but objected to unowned review, and he left. The takeaway for a team of your own: keep a fixed compatibility requirement, put a technical equal on the core, and give review a named owner.

• If a proposed feature raises memory or speed cost, then reject it with a written memo, but also record what it would have added for the shipped product. Cutler's stamp worked as a brake, so check later that the brake did not cost reliability or capability.
• If the person assessing a design or schedule cannot read the code, then move that call to a programmer-lead. Gates's view is that non-programmers cannot tell a promising program from a bust.
• If a change would break something existing users rely on, then it needs explicit sign-off from the architecture owner. VMS treated old PDP-11 programs as a requirement.
• If one engineer is the only person who understands a core component, then add a technical equal now. Do not wait for that engineer to ask.
• If reviewers outnumber the people who can fix the problems they raise, then cut the review list to named owners with named questions.

• Treating size as the goal in itself. The tell: features are rejected on memory cost alone and nobody can say what the shipped product lost.
• Review as prosecution. Gates's code reviews, with tirades like 'the stupidest piece of code ever written,' show the risk. The tell: engineers argue about winning the exchange rather than fixing the code.
• Hero dependency. Cutler would not ask for help and needed a hire made behind his back. The tell: one name on every critical component and a team that waits on that person.
• Review by everyone. The tell: a project is held up by people with 'no business' in it, and the lead's response is to leave or route around the process.
• Feedback that is all criticism. Heinen kept one old thank-you note in his desk because he could not tell whether he was still valued after an attack. The tell: engineers hoard evidence of approval and avoid reporting problems.

• ▸Component and technical owner: name the one programmer who can read and judge this code.
• ▸Single-concern sentence: write the team objective this component serves, in the form 'ship it and make it as good as we can.'
• ▸Compatibility requirements: list existing behaviors or programs that must keep working.
• ▸Review log: record each marked-up code return (date, reviewer, what was corrected, author acknowledged).
• ▸Defects and unknowns disclosed: list problems reported to date, who reported them and when, to check that candor is working.
• ▸Size/speed rejections: for each rejected feature, note the cost cited, the memo date, and what the feature would have added to the product.
• ▸Review scope: name the permitted reviewers and the question each owns; mark everyone else as out of scope.
• ▸Second-architect check: record who is the technical equal on this core, or the date one will be added.
• ▸Positive feedback given: record the last explicit credit given to each engineer, so criticism is not the only signal.

1. 1Write the parent's strategic objective as one sentence in the executive's own words before any design work. Gates on NT: 'I very much wanted a portable [operating system]... not a question of if, but when.' If you can't quote the objective, you don't have it.
2. 2Split the objective into the product properties that deliver it. Bell's Vax aim (stay ahead of IBM in minicomputers while keeping PDP-11 customers) became two testable properties: backward compatibility and scalability. Give each property a pass/fail test.
3. 3Rank the objectives and name the one the parent treats as non-negotiable. Gates called the 386 port 'a top priority' and never imagined shipping NT unless it ran on standard PCs. The team lead's own preference (Cutler favored RISC) does not change the ranking.
4. 4Check the builder's bias against the ranking. Cutler feared the 386 version would tempt the team into nonportable assembly code. Treat that fear as a real design risk, and assign a named owner and a milestone to the parent's priority so it is not left to the builder's enthusiasm.
5. 5Put the scope cuts in front of the parent in writing, with specific deliverables. Perazzoli's first-anniversary presentation said old OS/2 apps would not run without extensive changes, DOS apps would not run at all, and existing OS/2 drivers would not carry over. Gates objected to the driver cut ('mother's milk') and accepted it only after being convinced.
6. 6Tie the product to dated milestones the parent can inspect: Jan 30, 1990 minimal NT running; Jul 30, 1990 code complete; Oct 30, 1990 version for applications writers; Mar 30, 1991 Golden Master. Note which milestones depend on groups outside the lead's control.
7. 7Reassign someone to watch the market and re-link the product when conditions move. Maritz acted as Cutler's 'eyes and ears onto the market'. When conditions changed, he married NT to Windows, which moved the project from the periphery to the center of Microsoft's future.
8. 8Secure the resources the objective implies and keep the parent from micromanaging. Gates funded NT at $150 million, the most expensive PC program to date, and ceded authority to Maritz and Cutler on technical matters.

Gates wanted a portable operating system for Microsoft's future, and Cutler, hired from Digital after Prism was canceled, was the leader he chose. Cutler thought DOS was a 'toy' and wanted a 'real' OS for powerful machines. About a year in, Perazzoli promised Gates specific deliverables, with a schedule running from 'Minimal NT up and running' (Jan 30, 1990) to Golden Master (Mar 30, 1991). The promises were deliberately limited: no DOS apps, no old OS/2 apps without changes, no reuse of existing drivers. Gates took some convincing on the drivers but accepted the trade. A tension remained. Gates saw the 386 port as a top priority, while Cutler favored RISC and feared assembly code would erode portability. That conflict had to be managed through the schedule. Later, Maritz married NT to Windows, which pushed it from the periphery to the center of Microsoft's strategy.

• If the team lead's preferred platform differs from the parent's top priority (RISC vs the 386 PC standard), then schedule the parent's priority as an explicit, owned milestone and guard against the lead's stated risk, such as nonportable code.
• If a scope cut touches something the executive values ('mother's milk' drivers), then present it explicitly with the alternative (new drivers, or peripheral makers writing them) and get agreement before proceeding.
• If market conditions change the product's role, then have the market-facing lead re-link it to the parent's core franchise, as Maritz did by tying NT to Windows, rather than defending the original positioning.
• If milestones depend on groups outside the lead's control, then flag those dependencies when you commit dates to the parent.
• If the executive is close to the technical details, then keep their involvement to strategy, resources and market knowledge, and let the technical leads decide the rest.

• Optimizing for the builder's ideal rather than the parent's priority. The tell: the lead calls the strategically required version (the 386 port) a distraction and gives it 'no passion'.
• Implicit scope cuts. The tell: the parent learns late that something it assumed ('mother's milk' drivers, DOS apps) won't be supported.
• Strategy frozen at kickoff. The tell: no one is assigned to the market, and the product stays at the periphery until someone like Maritz re-links it.
• Backward compatibility or other strategic properties left untested. The tell: the objective ('keep PDP-11 customers') appears in the pitch but not in the acceptance criteria.
• Under-resourcing or over-managing. The tell: the strategic bet has too little money for its scope, or the chief executive keeps overriding technical leads.

• ▸Parent objective (quoted): the executive's own words on what the product must achieve, such as a market entered, a rival neutralized or a platform created.
• ▸Product properties that deliver it: the testable features that realize each objective (e.g., backward compatibility, scalability, portability).
• ▸Priority rank and non-negotiable: which objective the parent will not drop (e.g., must run on 386 PCs).
• ▸Builder bias / conflict: where the lead's preference diverges from the ranking, and the specific risk it creates.
• ▸Explicit scope cuts: what the product will not do, and who on the parent side has accepted each cut.
• ▸Dated milestones: each date with its deliverable, as in 'Code complete' or 'Golden Master'.
• ▸External dependencies: groups outside the lead's control that milestones rely on, with a named contact.
• ▸Market watcher and re-link trigger: who monitors conditions, and what change would require repositioning the product.
• ▸Resources committed: the budget and authority the parent has granted, and where the parent agrees not to interfere.

1. 1Scan for withdrawal signals weekly, not at the end. In the passages, the tester's burnout showed up as leaving the office at odd times for urgent outside meetings, and as a new outside investment (a Laundromat) that he treated as an emotional life raft. Log any person whose attention, hours, or loyalty is moving elsewhere.
2. 2Name the cause out loud, privately. Manheim told the tester, "You're just reacting against your situation here." That diagnosis was accurate but came too late, and it did not change the situation. Ask: what specifically do you want less of (deadlines, angry colleagues, code)? Record the answer in the person's own words, such as "I really can't code any more because of my emotional state."
3. 3Map single points of failure before anyone breaks. Manheim built a buddy system between testers and critical applications, but one tester covered both Pagemaker and printing. When that tester quit, a month passed before the gap surfaced as the Pagemaker fiasco. For every critical area, list who covers it and whether any one person holds two or more.
4. 4Treat the key-code owner as an at-risk asset. Walt Moore wrote display-driver code, without which a customer would see nothing on a PC screen. He was sinking into malaise and barely getting work done, and he had long wanted to train a replacement. Do not leave a stated wish like that unanswered. Start the replacement search early, as Muglia did when he went looking for freelance driver writers.
5. 5Make the handoff a requirement of any departure. Manheim got the tester to promise a week training his replacement. Set this expectation early and schedule the week. The transition was still rough, and a late substitute may be more liability than aid, so the real fix is cross-training before a crisis.
6. 6Count the cost of retention honestly. The tester walked away from stock options worth $250,000, which shows that money alone does not hold an exhausted person. Do not rely on unvested pay as your retention plan. Remove an actual source of strain, such as a deadline, a conflict, or a load.
7. 7Stop leadership behavior from compounding the strain. The passages show Cutler angry at the world, smashing a wall and breaking a finger, and keeping a fixed negative view of groups like graphics ("Once you are on his bad side, there is no recovery"). Check whether your own volatility or your fixed judgments are a stressor your team cannot escape.

A tester in Jonathan Manheim's group on Windows NT shows the full arc. He covered both Pagemaker and printing, a pairing Manheim set up as part of a buddy system for critical applications. Signs came first: he left the office at odd times for urgent meetings about a Laundromat he had bought, a business with three employees and thirty-five washers. Manheim saw the pattern and told him he was just reacting against his situation, but the stress of NT made the man crave simplicity, a place with no unwanted deadlines, no angry colleagues, no code. A month before the Pagemaker problem surfaced, he walked in and said, "I can't do this any more. How do I resign?" He left behind $250,000 in stock options and refused to stay to the end of the project. Manheim extracted a one-week training promise, but the transition was rough, and the double coverage the tester carried left a gap. The Pagemaker fiasco followed. The lesson is that the warning signs were visible, the coverage was concentrated in one person, and the handoff came too late to protect the project.

• If a person starts spending work hours on an outside venture or emotional refuge, then treat it as a resignation signal and open a workload conversation immediately, not at the end of the project.
• If one person covers two or more critical areas, then split the coverage before the crunch, because their departure creates a silent gap that surfaces weeks later.
• If a key-code owner says they want to hand off their work or switch roles, then start training a successor now and bring in outside help if needed.
• If someone says they cannot continue because of their emotional state, then stop arguing for them to stay and secure a trained replacement handoff, since money did not hold a man with $250,000 in options.
• If your own anger or fixed opinions of a team are visible to everyone, then assume they add to the exhaustion and correct course, since reputations you set can be nearly impossible to undo.

• Reading withdrawal as a quirk. The tell: you know about the side venture or odd hours and respond only with advice, not with a change to the person's load.
• Concentrated coverage. The tell: one person is the named backup for several critical areas, so a resignation is discovered only when a problem escapes weeks later.
• Betting on financial incentives. The tell: the plan for keeping someone is unvested options, yet the person is willing to forfeit $250,000.
• Late, thin handoffs. The tell: the replacement arrives at the end of the project and a week of training is the whole plan, making the substitute a possible liability.
• Leader-driven strain. The tell: the leader's visible anger, physical outbursts, and fixed negative views of groups go unaddressed while the team is described as tired and frustrated.

• ▸Person and role: name the person and what they own.
• ▸Critical areas covered: list every critical area they cover, and flag any with two or more.
• ▸Withdrawal signals observed: record odd hours, outside ventures, falling output, and dates.
• ▸Stated strain in their own words: quote what they say they cannot take any more.
• ▸Backup or successor: name who can take over and their readiness today.
• ▸Handoff plan: set the training date and length, and who delivers it.
• ▸Retention lever other than pay: list what load, deadline, or conflict you can remove.
• ▸Leadership stressors: note any leader behavior or fixed judgments adding to the strain.
• ▸Next check date and owner: set when this sheet is reviewed and by whom.

1. 1Fix one direction and say it as a priority list. Cutler "sets priorities" himself, so the team never has to guess what matters. Write the top priorities down and treat everything else as subordinate.
2. 2Stay a working player, not only a commander. Cutler writes critical pieces of code and reviews the work of others. Pick the pieces where your own output sets the quality bar, and review everyone else's work directly.
3. 3Demand absolute candor and enforce it. Cutler expects the team to tell him the truth, and when someone tries to "snow" or deceive him, he attacks and remembers. Tell people the rule up front: bad news is acceptable, concealment is not.
4. 4Criticize fast and specifically when someone drops the ball. Heinen says Cutler is "quick with criticism." Tie each criticism to a concrete failure, such as a missed or deceptive piece of work, not to the person's standing.
5. 5Ration praise and make it count. Cutler is tight with praise, but his note, "Roger, you really did a good job. Thanks, Dave," was kept in a desk and reread for months. Write it down, name the work, and expect a short note to carry a long way.
6. 6Back compliance with real rewards. Those who submit to Cutler's will earn millions of dollars in Microsoft stock bonuses. Tie pay and standing to meeting your standard, since the harshness has to be paid for.
7. 7Keep process minimal and let outcomes carry the authority. Cutler says "process is to help get the job done, not an end in itself," and formal reporting lines on his team were ignored. Command through standards and review, not through org-chart procedure.
8. 8Price the cost before you commit. Cutler's followers live one-dimensional lives, with fraying marriages, neglected children and withered hobbies. Decide whether you will demand that level of immersion, and expect resistance to cost people your respect or draw your wrath.

Maritz and Gates face a leadership gap on NT. Cutler, running a team of about twenty-five, refuses more scope, especially graphics: "I'd rather be in charge of five people than five hundred." Gates worries the whole product will look poor unless someone of Cutler's stature fills the gap, and he considers ordering Cutler to broaden his duties, with Maritz "jam[ming] the decision home." Maritz declines. He sees Cutler as a powerful but delicate instrument: "If you fix the bad things, you're probably going to screw up the good things." He also knows Cutler would not accept such an order from him. When Maritz says "We should—," Cutler cuts him off: "We! Who's we? You mean you and the mouse in your pocket?" Maritz absorbs the insult and refuses a brawl. Instead, on February 23, 1990, he sets a challenge that ties Cutler to Whitmer's graphics group, so the organizational shortfall surfaces and Cutler can "volunteer." The lesson is that with a commanding, profane leader you steer by exposing evidence, not by issuing counter-commands.

• If someone has deceived you or hidden a problem, respond hard and visibly, because candor is the one non-negotiable. If they simply failed in the open, criticize the work and move on.
• If you criticize someone in public, give a specific, recorded acknowledgment of their good work soon afterward. Otherwise they spend months wondering whether you still value them, as Heinen did.
• If your own boss is this kind of leader, don't try to force or "fix" the style. Set a challenge that makes the gap visible and let the leader choose to fill it, as Maritz did.
• If the leader resists broader scope because spreading thin hurts quality, treat that as a real trade-off. Weigh it against the product risk Gates saw before overriding it.
• If you adopt this style, accept loose reporting and few procedures, and compensate with strong review. Commanding through process fights your own method.

• Criticism with no praise. The tell: capable people save old notes and hesitate to ask whether you value them, as Heinen did, too afraid to ask Cutler.
• Contempt as a habit instead of a response to deceit. The tell: colleagues absorb insults and humor them (Maritz brushing off the 'mouse in your pocket' line) instead of changing their work, so the heat teaches nothing.
• Insularity of the loyal tribe. The tell: outsiders call the team a "tight clique," and the team derides the host culture as "Microslop," which creates friction with the people you need.
• Total immersion mistaken for the point. The tell: team members' marriages end, children are deferred and hobbies wither, while those who resist lose your respect or provoke your wrath.
• Forcing a command through a leader who won't accept it. The tell: you consider ordering the move (Gates and Maritz did), but the person has shown no willingness to comply, so the order would fail or damage what works.

• ▸Direction in one sentence: state the singular vision you demand compliance with.
• ▸Top three priorities: list what you set and what everything else yields to.
• ▸Personal work: name the pieces you write or review yourself.
• ▸Candor rule: state in one line what counts as deception and what counts as acceptable bad news.
• ▸Criticism log: record date, person, specific failure and whether it was public or private.
• ▸Recognition log: record date, person and a written note naming the exact work done well.
• ▸Reward linkage: state what bonus, equity or standing follows meeting the standard.
• ▸Cost check: list the personal and family costs you are asking of the team and whether you accept them.
• ▸Process stance: state which procedures you keep and how review replaces the rest.

1. 1Remain a working practitioner, not just a manager: like Cutler, set priorities, write the hard pieces of code yourself, and personally review others' work so your authority rests on demonstrated output.
2. 2Ship a visible, unambiguous win that the field recognizes — Cutler's VMS/first Vax (October 1977) made Gordon Bell call him the best writer of operating programs in the world. Build credibility on a result, not a title.
3. 3Insist on frequent, honest feedback loops: Cutler demands frequent NT builds so the team 'eats its own dog food,' discovers imperfections early, and improves. Make your standards measurable and tested.
4. 4Demand absolute candor and refuse to be snowed; attack deception immediately. When work is wrong, say so fast ('quick with criticism') — but anchor the critique to the specific dropped ball.
5. 5Protect the work from dilution: when 'every Tom, Dick and Harry' pokes holes and holds up the project, concentrate decision authority in the hands that actually build, allowing only review that is 'healthy.'
6. 6Recognize that credibility is local and non-transferable. Cutler was a star at Digital but felt anonymous at Microsoft — 'My credibility just wasn't there.' Re-earn it by learning the new domain (none of his team had programmed a PC) before claiming authority.
7. 7Ration praise so it carries weight, but make it specific and durable when given — Cutler's one-line note ('Roger, you really did a good job') was reread by Heinen for reassurance years later.

When Cutler arrived at Microsoft in November 1988, he had no credibility there — 'few people knew anything about him; he felt anonymous.' His Digital stardom didn't transfer, and his tight clique got Microsofties' 'hackles up.' Yet Gates treated him as the ultimate professional because of a demonstrated record: Cutler had designed VMS and the Vax, and Bell had called him the world's best writer of operating programs. That track record, not a Microsoft title, let Gates introduce him as 'someone who can manage large projects and bring them in on time with the highest quality.' On NT, Cutler rebuilt local authority the only way it can be rebuilt — by setting priorities, writing crucial code, reviewing others' work, and enforcing the dog-food build discipline until the output proved him right.

• If you hold a leadership title but can't still do the core work, then your authority is bureaucratic, not technical — write and review code to keep it earned.
• If someone tries to deceive you about the state of the work, then confront it immediately rather than letting them 'hang' themselves, because tolerated deception corrodes the team's standard.
• If you move to a new domain (like Cutler's PC shift), then assume your credibility resets to zero and earn it by learning the unfamiliar territory before asserting decisions.
• If review has degraded into every outsider 'poking holes' and stalling the project, then narrow decision rights to the builders — keep only the review that is genuinely healthy.
• If a strong contributor has just been criticized, then give one specific, honest acknowledgment of good work so correction doesn't read as lost respect.

• Mistaking 'almost right' for right — Cutler's lesson from IBM school: on a computer 'almost means you're still just wrong.' The tell: celebrating near-passes instead of testing to failure.
• Assuming credibility is portable; the tell is expecting 'star treatment' in a new org where no one knows your record, then feeling anonymous and turning defensively inward as a clique.
• Leading purely by criticism with no acknowledgment; the tell is a top performer like Heinen privately wondering whether you still value him and being 'too afraid to ask.'
• Letting size breed bureaucracy — large teams 'sink into mediocrity' as review turns into obstruction; the tell is capable people fuming that they can no longer act 'with customary authority.'
• Refusing help when you're over-capacity to protect your image; the tell is being the lone senior programmer on an under-staffed team ('When all is said and done, much more is said than done') while quietly resisting a codesigner.

• ▸Demonstrated result: name the shipped artifact that proves your mastery (e.g., VMS, first Vax).
• ▸Current hands-on work: the specific code/decisions you personally still own.
• ▸Feedback cadence: how often you test real output ('eat your own dog food') and against what standard.
• ▸Candor check: where you last confronted a snow-job instead of letting it slide.
• ▸Credibility locale: in this room, who already respects the record — and who needs it re-earned.
• ▸Domain gap: what in this new environment you haven't yet mastered and your plan to learn it.
• ▸Review scope: which review is healthy vs. which 'hole-poking' you must cut to protect the work.
• ▸Praise balance: the last specific acknowledgment you gave a strong contributor, and to whom.

1. 1Write the ship plan as a dated memo with measurable gates, not a feeling. NT's 'Windows NT 1.0 Ship Plan' named a ship date (May 10, 1993) and listed milestones with numbers: Jan. 24 last performance check-in for beta 2; Jan. 31 stress results above 85%; Feb. 15 beta-quality builds and stress above 90%; Feb. 28 beta 2 to Sony for disc making. Every line states a date and a pass condition.
2. 2Settle the open design decisions before you trust the dates. The source calls the early NT schedule 'a glorified security blanket' because dozens of decisions, such as whether to build a new file system or carry forward DOS and OS/2 ones, were still unmade. List every unresolved decision, name an owner, and set a decide-by date ahead of the dependent milestone.
3. 3Agree the ship criteria with the executive who can stop the ship, and get them to bless them. Gates let NT ship because 'they knew the criteria' and he would not ask for additional speed or features. Write down the performance and feature bar, get the sponsor's sign-off, and treat reopening it as a change request.
4. 4Narrow change as the date approaches. From Feb. 28 to March 21 the plan allowed only 'very selective' performance check-ins, approved personally by Cutler and pretested on private builds. Name one approver for late changes and require a private-build pretest before anything touches the main build.
5. 5Run a continuous bug push with visible rewards. Dunie piped the Super Bowl into the lobby of Building Two to draw people in to fix bugs, and the team fixed fifty while watching. Pick a recurring, social event aimed at one outcome (bugs closed), and count the result.
6. 6Keep a small standing crew on the last known gap after the sponsor approves. Cutler and Dunie agreed to keep six people on performance 'for a little while longer' even after Gates's blessing. Ring-fence a named group and set an end date.
7. 7Assign someone to absorb the human cost. Perazzoli kept a slush fund for monitors and disk drives, asked overworked people what would ease the pain, and tied bigger requests to work ('Do this, this, and this, and then the trip will follow'). He 'keeps people from quitting when they've had their fill of Cutler.' Name this role explicitly, give it a budget, and use it weekly.
8. 8Hold release authority with the people closest to the build. Gates would abide by Maritz, Dunie and Cutler's decision on readiness. Decide in advance who says 'ready' and on what evidence.

In early 1993 NT's leaders held Gates to a plan, not a hope. A week after Super Bowl Sunday, Havens showed Gates the performance gains from Miller and Kimura: Windows programs still ran slower on NT than on DOS, but the gap was small enough to satisfy him. Gates blessed shipment, saying he saw 'no reason to hold this thing up' on features or performance, and that the team knew the criteria. Cutler and Dunie did not stop to celebrate. They kept six people on performance and kept pushing on bugs, and the Super Bowl lobby event had produced fifty fixes in one afternoon. The 'Windows NT 1.0 Ship Plan' memo set May 10, 1993 as the date and laid out the next five months: Jan. 31 stress above 85%, Feb. 15 stress above 90%, Feb. 28 beta 2 to Sony, then a March 21 window of 'very selective' performance check-ins approved by Cutler personally. The pattern is a fixed bar from the sponsor, a shrinking set of allowed changes, and a named person guarding the gate.

• If a design decision is still open and a milestone depends on it, then decide it first. A dated plan on top of undecided questions is only a security blanket.
• If the sponsor has approved the feature and performance bar, then stop adding scope. Reopen the bar only by going back to that sponsor, and keep only the small crew needed for known gaps.
• If a change arrives inside the final window, then it needs the single named approver and a pretest on a private build. Otherwise it waits.
• If someone says they cannot go on, then ask what would ease the pain. Grant the small requests from a reserve and attach the large ones to shipping work.
• If the bug rate must come down, then give people a reason to come in together and count the fixes. Don't just announce a target.

• Dates without decisions: the schedule looks precise while core questions, such as which file system, are unresolved. The tell is milestones slipping for reasons that trace back to an undecided design point.
• Leading by pushing alone. Short warned that Cutler 'leads by doing vast amounts of work and by pushing other people to do vast amounts of work,' and that the journey might strain people to the breaking point. The tell is people close to quitting and one person absorbing the team's fear and anger.
• Treating 'just make it work' as permission to ignore everything else. Cutler told Lucovsky, 'I don't care what [the code] looks like, just make it work,' and the source notes programmers hate documentation. The tell is work that is deferred indefinitely (the source's example is documentation) because it does not move the ship date.
• No single gatekeeper late in the project, so performance or feature check-ins keep arriving unchecked. The tell is that stress and bug numbers stall or regress between milestones.
• Moving the goalposts after the sponsor has signed off. The tell is requests for 'additional' speed or features after the release decision. In NT's case, Gates agreed not to ask for them.

• ▸Ship date: the single committed date, and who set it.
• ▸Milestones with pass conditions: each date paired with a measurable bar (e.g., stress result above a stated percent).
• ▸Open decisions: each unresolved design question, its owner, and its decide-by date.
• ▸Sponsor-approved criteria: the feature and performance bar, who blessed it, and the date.
• ▸Late-change window: start and end dates, the single approver, and the required pretest.
• ▸Bug push event: the date, the draw (what brings people in), and the target count.
• ▸Standing crew: names kept on the last known gap, and the end date for that assignment.
• ▸Pain-relief owner and reserve: who asks 'what would ease the pain,' and the budget they can spend.
• ▸Release authority: who declares readiness, and the evidence they will use.

1. 1Start from the source's limit: the passages never describe the NT team running its daily work on NT. They show the conditions dogfooding must fix, and the steps below are built from those. Treat them as application, not as a record of what Microsoft did.
2. 2Make the build reproducible by anyone before you ask anyone to live on it. Shannon's first NT build in August 1989 failed at step one, step two and step three of a three-page description. A build only the authors can produce cannot be dogfooded.
3. 3Cut a build on a fixed cadence and make it the one the team works on. NT was built once a week. Pick the cadence, name an owner, and require every developer to run that build for real work, not only demos.
4. 4Define 'daily work' concretely: the editor, the mail, the build tools and the test scripts the team uses today. Move one category at a time onto the in-development system, so failures trace to a specific piece.
5. 5Run it on the hardware customers will own, not the team's best machines. NT might need eight megabytes, eight times the then-standard amount, and Gates feared customers would balk at paying hundreds of dollars for memory. A team on oversized machines never feels that cost.
6. 6Log every failure at the moment it interrupts work, with what you were doing, what broke and the cost in minutes. Route the log to the person who owns the failing component. Perazzoli owned the memory manager, so memory failures go to him.
7. 7Review the log weekly against the schedule. Decide which failures block shipping, since 'If you don't finish, all the bright ideas don't mean anything' (Cutler). A bug that stops the team from working on the product outranks a new feature.
8. 8Keep testers inside the loop. Twenty testers needed a build to write test apps. Dogfooding supplements their work; it never replaces it.

Shannon, a former disk-duplicator on $5.25 an hour, joined the OS/2 build team and in August 1989 was asked to build NT weekly. He sat down with a three-page build description from Steve Wood. Step one failed, then step two, then step three. Wood called the instructions 'old news' and offered other commands, which also produced no build. Lucovsky asked why he even wanted a build, and when Shannon said twenty testers needed one to write test apps, answered, 'To hell with the testers.' The passages show a team whose builders could not build and who treated the people downstream as an afterthought. A mandatory daily-use rule changes the incentive: if the developers must run that weekly build themselves, the broken steps stop being 'old news' and become the first thing fixed, because the failure lands on them. The passages stop at the point where Shannon, still confused, goes to find Perazzoli. The rule is an inference, not a recorded outcome.

• If a new person cannot produce the build from the written instructions alone, then stop feature work and fix the instructions first; Shannon's failed first build is the tell.
• If a failure blocks someone from doing their daily work, then rank it above new features and assign it to the component owner the same day.
• If the system's resource demand is uncertain (NT's memory need was unknown for a long time), then run daily work on customer-spec hardware to learn the real number instead of waiting.
• If the team treats downstream users as an annoyance ('To hell with the testers'), then make the developers the users of their own build so the cost reaches them.
• If dogfooding reports are not moving the schedule, then tie them to the ship decision, because shipping is the real measure of the craft.

• Exempting the best people or the riskiest components from daily use. The tell: the failures reported cluster in code nobody on the core team touches.
• Running the in-development build only on oversized machines. The tell: nobody on the team complains about memory or speed until customers do.
• Letting build instructions rot because only the authors build. The tell: a newcomer's first build fails on early steps and the answer is 'just try this'.
• Collecting complaints without owners. The tell: the same failure appears in the log across weeks with no named person assigned.
• Treating dogfooding as a substitute for testers. The tell: testers lack a current build because the team assumes its own use covers it.

• ▸Build ID and date: the weekly build the failure occurred on.
• ▸Reporter and machine spec: who hit it, and the memory and hardware they were running.
• ▸Daily task interrupted: the real work being done (editing, mail, building, testing).
• ▸What broke: the observed behavior, in one or two sentences.
• ▸Minutes lost: the time cost, so the weekly review can rank failures.
• ▸Component owner: the one named person who gets it (for example, the memory manager owner).
• ▸Blocks daily work? (Y/N): Y moves it above new features.
• ▸Ship impact: does it threaten the ship date or the stated hardware requirement?
• ▸Fixed in build ID: close the loop only when the reporter confirms in daily use.

1. 1Recruit the core from people who already trust the leader. Cutler didn't raid Digital; seven of the top code writers from his old lab followed him to Microsoft within a week. Everyone on the core team had worked under him for years. Ask who would follow you without being asked, and build the first circle from that list.
2. 2Give the core a shared enemy or mission with a name. For Cutler's group it was Unix, 'his Moriarty,' a junk operating program 'designed by a committee of Ph.D.s' with 'never one mind behind the whole thing.' Write down the one thing the team exists to beat or replace, and repeat it whenever priorities blur.
3. 3Protect the group's terms at the moment of entry. Cutler's people refused to sign Microsoft's paragraph 10 (a one-year bar on joining a competitor) because Digital never imposed it. Before onboarding, list the clauses and rules your core will balk at. Decide in advance which to negotiate and which to hold, because the first conflict with the host organization defines the group's identity.
4. 4Keep the core small and tight, and plan for dilution. Once NT expanded, Cutler stopped being 'a familiar patriarch whose mercurial personality was accepted.' Most new people feared him and spoke to him 'only at their own risk.' Set a trigger, such as the team doubling in size, that prompts you to re-establish norms with newcomers explicitly rather than relying on old-timers' tolerance.
5. 5Absorb newcomers through intact groups and credibility, not individually. Felton 'brought an entire group with him; he simply transferred loyalty from one flag to another.' Managers who wrote code won acceptance faster. Prefer bringing in whole sub-teams with a lead who can code, and give outsiders (OS/2 and networking people, scorned in the past) a concrete path to prove their worth.
6. 6Watch the cost of the in-group. 'Total confrontation. The person who shouts and curses the most is right,' and 'everybody from OS/2 was a bozo.' Women programmers felt 'women weren't valued as much,' and were too wary to meet even for a potluck, 'as if a mere meeting were a show of disloyalty.' Audit monthly who is being excluded and what the loyalty norm punishes.
7. 7Let the group blow off steam inside the culture, then decide deliberately whether to police it. The hoser-ball game (a tennis ball filled with pennies slammed into rows of spent Coke cans) followed a successful two-day bug hunt. Diamond had to choose whether to 'crack down or cut them slack.' Treat celebration rituals as cohesion assets and set limits only on harm to others.
8. 8Account for money's effect on loyalty. Stock options made even the rookie Princeton programmer worth a few hundred thousand dollars within three years. This 'could buy a lot of loyalty and hard work' but also 'made for independent-minded programmers.' Don't confuse financial retention with allegiance to the leader.

When Dave Cutler left Digital for Microsoft, he didn't recruit aggressively. People who saw him as 'a high-tech Moses' followed. Within a week Microsoft hired seven of the top code writers from his old lab, and everyone on the core team had worked under him for years. On their first morning they were handed Microsoft's employment contract, including paragraph 10, which barred joining a competitor for at least a year after leaving. Having been warned about it, they refused to sign, arguing that Digital could never have hired them if it had imposed the same restriction. The company wouldn't budge: no signature, no work. The episode shows the pattern: loyalty is imported intact with the group, and its first test is a collective stand against the host's rules. Later, when NT expanded and brought in OS/2 and networking people whom Cutler had scorned, the old closeness thinned. Newcomers feared his temper, and the group's 'everybody from OS/2 was a bozo' attitude hardened the us-versus-them line inside the team itself.

• If your core has worked together for years, then rely on shared history for speed, but write the norms down before adding people, because tolerance of your temperament won't transfer to newcomers.
• If a new hire arrives with an intact group and a lead who writes code, then integrate them as a unit; if they arrive individually from a group your team has scorned, then assign a visible early win so they can prove their worth.
• If the team's identity depends on an external enemy (Unix for Cutler), then make sure the enemy still matches the project's goals; if the strategy shifts (OS/2 to Windows), then reassure the core about the project's survival, as Ballmer did for Cutler.
• If loyalty norms stop certain members from even meeting or speaking up, then treat that as a cohesion failure, not discipline, and create a sanctioned channel (as the Hoppers bulletin board did).
• If the team lets off steam after a hard win, then default to cutting slack and intervene only when the behavior frightens or excludes others.

• Mistaking financial lock-in for loyalty. The tell: options worth millions make people independent-minded, and allegiance to the project drops as net worth rises.
• Letting the leader's temper define the culture as the team scales. The tell: newcomers speak to the leader 'only at their own risk' and information stops flowing upward.
• Using an out-group label as glue. The tell: 'bozo' becomes the default word for a whole origin group (OS/2), and newcomers spend energy proving worth instead of working.
• Treating gatherings of affinity groups as disloyalty. The tell: members are too wary to attend a potluck, and bias persists because 'it only took one screw-up' for old skepticism to resurface.
• Rewarding combative style as correctness. The tell: 'the person who shouts and curses the most is right,' and abrasive high performers like Lucovsky ('Until you prove otherwise, you're wrong') drive teammates to resentment.

• ▸Core circle: names of people who have worked under you for years and would follow you unprompted.
• ▸Shared adversary or mission: the one thing the team exists to beat or replace, in one sentence.
• ▸Entry-terms conflicts: policies or contract clauses your core will resist, and your negotiate-or-hold decision for each.
• ▸Growth trigger: the team size or event at which you must reset norms with newcomers.
• ▸Newcomer integration path: for each incoming group, who leads it, whether they write code, and their first proving win.
• ▸Out-group labels in use: slurs or shorthand the team applies to other groups, and who is affected.
• ▸Voice channels: forums where excluded members can meet or raise issues without being seen as disloyal.
• ▸Release rituals: how the team celebrates wins, and your pre-set limit on when to intervene.
• ▸Retention vs. loyalty check: which members are held by money alone, and what else ties them to the mission.