In the telling recollection of former Microsoft engineer Dave Plummer, the company's 1990s talent machine looked less like a nurturing incubator and more like a high-stakes gauntlet: merciless interviews up front, strict role-fit triage inside, and a blunt performance architecture that either polished you into a contributor or pushed you out. Plummer’s account — calling interviews “merciless,” describing Performance Improvement Plans (PIPs) as a pathway to being “managed out,” and comparing the older stack ranking system to a lifeboat drill — revives a familiar narrative about the Redmond juggernaut: brilliant engineers, ruthless internal competition, and a set of people-practices that helped shape both Microsoft’s engineering prowess and its internal politics.
A Performance Improvement Plan (PIP) is a formal process that documents performance gaps, sets measurable improvement goals, and establishes a timebound review window. While PIPs are nominally meant to rescue employees who can and wish to improve, many companies — historically including Microsoft — have used them as a formalized channel to accelerate separations when the fit is poor. That practice is colloquially called “managing someone out.”
The modern leader’s task is to harvest the positive elements — recruiting excellence, rigorous standards, and clear accountability — while avoiding incentives that reward zero-sum behavior. That means designing evaluation systems that reward both individual craft and the ability to multiply other people’s productivity, combining compassionate remediation with real accountability, and remembering that processes which work in theory can be gamed or misapplied in practice.
Microsoft’s arc — from stack ranking to collaborative review systems to the current rebalancing of performance expectations — is instructive for any technology organization wrestling with scale, speed, and the human dynamics of creative work. The lesson for engineering managers and HR leaders is timeless: hire selectively, coach relentlessly, measure fairly, and keep the lifeboat drills out of the product room.
Source: theregister.com In '90s Microsoft, you either shipped code or shipped out
What people mean by "stack ranking" and "managed out"
In corporate HR parlance, stack ranking (also called forced ranking or forced distribution) requires managers to place employees along a predetermined performance curve each review cycle. The system typically allocates fixed percentages for top performers, middle performers, and the bottom tier — the latter often facing limited raises, diminished prospects, and, in many firms, a shrift toward exit.A Performance Improvement Plan (PIP) is a formal process that documents performance gaps, sets measurable improvement goals, and establishes a timebound review window. While PIPs are nominally meant to rescue employees who can and wish to improve, many companies — historically including Microsoft — have used them as a formalized channel to accelerate separations when the fit is poor. That practice is colloquially called “managing someone out.”
Dave Plummer: the witness and his context
Dave Plummer is a veteran engineer who joined Microsoft in the 1990s and later authored components that shipped in consumer Windows (notably the program that became Task Manager and ZIP-folder support). His perspective matters because he saw hiring, team composition, internal politics, and product shipping from inside Microsoft’s engineering culture during a decisive period of platform development. When Plummer describes the interview process as “selective and strict” and remembers managers using stack-ranking discussions to call out specific names for removal, he speaks as someone who lived those rhythms — and who also helped build the product artifacts that millions still use.The hiring gauntlet: why Microsoft’s 1990s interviews were famous
"Merciless" selection — myth and method
In the 1990s, Microsoft’s interview and hiring approach was widely understood to be highly selective. Candidates often faced long technical interviews, whiteboard problem solving, and repeated sessions focused on algorithms, system design, and role fit. That ferocious filtering had two effects:- It raised the bar for technical craft inside engineering teams.
- It generated a cultural baseline in which being a Microsoft engineer implied surviving a crucible — and, for some, a corresponding sense of survivor’s legitimacy.
When hiring misfires happen: alternative placements and role churn
Even the most selective process produces false positives. Plummer noted two typical outcomes for hires whose coding skills weren’t at the team’s level:- If an individual had strong analytical, design, or product thinking but weak implementation chops, they might be moved into program management — a role focusing on designing features, coordinating cross-team work, and shaping product strategy.
- If neither engineering nor PM fit seemed likely, the company might attempt remediation; otherwise, the employee could face progressive performance sanctions.
The PIP: a shield — or a sword?
Formal remediation that could become termination
Plummer’s blunt summary of Microsoft’s PIP approach — “you weren’t allowed to transfer internally… you had to bring your performance grade up within a certain number of months … or you were ‘managed out’” — highlights how the formal process functioned in practice for many. PIPs are, by design, documented and timeboxed. They create an auditable path: clear metrics, checkpoints, and consequences. Ideally, they are a structured chance to recover. In practice, they also give managers a defensible route to separate underperforming hires without resorting to ad-hoc or legally precarious methods.Two faces of PIP
- The humanitarian face: PIPs genuinely help people returning from illness, personal crises, or temporary skill gaps. With supportive coaching and realistic goals, some employees recover and continue valuable careers.
- The punitive face: When used as a de facto exit strategy, PIPs can be procedural pretext. A short timeline, unrealistic expectations, or blocked transfers can make success improbable. Plummer’s phrasing — “to save people that shouldn't be fired in the first place” — indicates an ambivalence: PIP can save reputations, but it can also formalize dismissals that ought to have been avoided by more careful hiring.
"Managed out" as cultural shorthand
“Managing someone out” became shorthand in tech for a manager’s set of tactics to get a poor-fit employee to resign or fail a formal remediation. That ranges from withholding work and isolating employees to imposing impossible deadlines. Historically, large engineering organizations used these techniques to maintain team productivity while limiting the legal and administrative friction of firings.The stack-ranking era: lifeboat drills, bell curves, and internal politics
How stack ranking worked inside large engineering teams
In a classic forced-distribution approach, a manager of a 20-person team must assign predetermined percentages to each rating tier. If the distribution mandates that 5% be “poor,” managers must place certain people into that bottom bucket even when relative performance is uniformly high. Plummer’s metaphor — "a lifeboat drill" where the lifeboat holds fewer people than the ship — captures the inhuman arithmetic implicit in the method.Behavioral side effects: competition that undermines collaboration
Plummer’s accounts of managers “naming names” and the culture of competitive upward jockeying are echoed by numerous former employees and investigative accounts. When careers depend on being ranked above colleagues, incentives shift:- Collaboration suffers: engineers prioritize individual visibility and credit over shared success.
- Political behavior increases: time and energy shift from product work to internal influence—meeting other managers, promoting artifacts, and documenting perceived weaknesses in colleagues.
- Risk aversion emerges: teams avoid shared ownership and long-term bets that obscure measurable short-term metrics.
The counterpoint: defensible differentiation and merit allocation
Supporters of forced distribution argue that some mechanism is needed to honestly differentiate performance at scale. Without tough calibration, pay and promotion systems can drift toward inflationary norms, and genuinely low performers can persist. Stack ranking is blunt, but it forces difficult conversations and can make compensation decisions more transparent — if implemented fairly and with managerial discipline.Microsoft’s break with forced ranking (and what came after)
The shift in 2013
In the 2010s, Microsoft publicly announced the end of mandatory stack ranking. The company moved toward systems emphasizing teamwork, continuous feedback, and manager judgment rather than a fixed heuristic curve. That transition reflected a broader industry trend away from bell-curve evaluation in large tech firms — a response to the documented cultural costs and the need for improved collaboration across product groups.After the curve: Connects and Perspectives
Microsoft replaced the rigid ranking with processes that prioritized ongoing feedback and multi-dimensional evaluation: individual impact, contribution to others’ success, and the extent to which a person used and leveraged others’ work. The intent was to restore teamwork as a first-order principle and to reduce perverse incentives to hoard credit or avoid risky, cross-team bets.Did ditching the curve fix everything?
Not automatically. Changing a formal review mechanism does not instantly rewrite habits, incentives, or accountability. Managers who internalized bell-curve thinking may continue to behave as if distribution constraints exist. Likewise, employees who learned to game rankings may point to culture shifts only slowly. Organizational inertia and local practice can blunt the theoretical benefits of a new model unless leaders actively coach and audit for the new behaviors they expect.The "lost decade" argument: complexity, nuance, and evidence
The claim
A prominent strand of tech criticism blames Microsoft’s stack-ranking culture for a period of relative stagnation in product innovation and market momentum — often called a “lost decade.” The argument says that internal competition and politics diverted attention from customer-driven product thinking and allowed competitors to out-innovate Microsoft in key categories.Weighing cause and correlation
This is an area that requires careful nuance. Stack ranking appears repeatedly in retrospective accounts as a corrosive factor that accentuated internal politics. Yet assigning full causal responsibility for a complex corporate performance curve to a single HR mechanism is reductive. Several interacting forces shaped Microsoft’s trajectory in the 2000s and early 2010s:- Leadership and strategic choices about platforms and mobile strategy;
- Market shifts (smartphone ecosystems, cloud-first transitions);
- Structural inertia and product portfolio complexity;
- Incentives and people practices, including but not limited to stack ranking.
Recognizing the benefits that created the problem
Ironically, the same selective hiring, engineering rigor, and internal competition that produced world-class products also seeded the conditions for political behavior. Organizations that prize elite hiring and short-term output metrics must consciously design systems that preserve collaboration and long-term investment. Without that, the strengths can become pathologies.Then and now: what’s changed in 2025
The swing of the pendulum
Industry trends in 2024–2025 point toward a renewed emphasis on performance accountability. Some firms are moving back to stricter remediation policies, shorter timelines for underperformance, and options to take severance instead of entering a PIP. These shifts are often framed as necessary to ensure resource allocation to high-priority strategic efforts — particularly as AI investments and competing priorities intensify.The risk of repeating old mistakes
Reintroducing hardline measures without safeguards risks resurrecting the worst aspects of earlier systems: reduced morale, lower psychological safety, and diminished risk-taking. The lessons from the earlier stack-ranking era remain relevant:- Clear expectations and continuous, constructive coaching beat episodic, high-stakes judgments.
- Public, transparent calibration of standards — rather than secretive forced distributions — reduces gaming of the system.
- Leadership needs to supervise how managers apply remediation tools to prevent PIP-as-exit defaults.
Practical lessons for leaders and engineering managers
Reframe evaluation to reward collaboration and leverage
- Measure both individual impact and how a person enables others to succeed.
- Develop metrics that reward shared ownership and cross-team outcomes, not just headline individual deliverables.
Use PIPs sparingly and constructively
- Make PIPs supportive, with realistic milestones and active manager coaching.
- Allow internal mobility when fit is questionable rather than automatically escalating to formal remediation.
Avoid forced distribution as a default
- If you must differentiate, use manager calibration and peer review, not rigid bell curves.
- Audit for adverse side effects: do people hoard work, avoid mentorship, or conceal risks?
Build an appeals and oversight process
- Ensure HR and senior engineering leadership can spot abuses and protect high-value contributors from political misclassification.
Risks and unresolved questions
The trade-off between speed and fairness
High-stakes accountability accelerates decision-making and reclaims headcount for strategic priorities, but it can also trigger churn, knowledge loss, and expensive rehiring cycles. The optimal balance depends on context: stage of the company, competitive pressures, and the maturity of leadership.Unverifiable or subjective claims
- Personal recollections — including Plummer’s colorful metaphors — are valuable but inherently subjective. They are best read as first-person evidence that complements broader reporting, not as definitive proof that any single policy alone caused past outcomes.
- The exact internal mechanics of any company at scale are often variable across groups. One team's experience with PIPs or ranking may differ meaningfully from another's.
Conclusion: memory, method, and what to keep from the past
Dave Plummer’s account is a vivid reminder that people practices shape software outcomes. Microsoft’s 1990s engineering culture — selective hiring, intense internal competition, and formal performance mechanisms — produced enormous product results and also created painful interpersonal and institutional trade-offs. The forced-distribution era drove some managers to make survival the primary currency, sometimes at the cost of collaboration and long-term bets.The modern leader’s task is to harvest the positive elements — recruiting excellence, rigorous standards, and clear accountability — while avoiding incentives that reward zero-sum behavior. That means designing evaluation systems that reward both individual craft and the ability to multiply other people’s productivity, combining compassionate remediation with real accountability, and remembering that processes which work in theory can be gamed or misapplied in practice.
Microsoft’s arc — from stack ranking to collaborative review systems to the current rebalancing of performance expectations — is instructive for any technology organization wrestling with scale, speed, and the human dynamics of creative work. The lesson for engineering managers and HR leaders is timeless: hire selectively, coach relentlessly, measure fairly, and keep the lifeboat drills out of the product room.
Source: theregister.com In '90s Microsoft, you either shipped code or shipped out