The Netflix Keeper Test asks managers: "If this engineer resigned today, would you fight to keep them?" While it ensures high talent density, I believe it often destroys psychological safety. For most software engineering teams, a collaborative culture built on trust outperforms a high-stress, sports-team model driven by the fear of sudden severance.
Imagine walking into your next 1-on-1, and instead of discussing career growth or system architecture, your manager is running a silent background process: If you walked out the door right now, would I actually care? Personally, I think this is a terrifying way to run an engineering organization. The "Keeper Test" has always fascinated me because, in my view, applying this raw, survival-of-the-fittest model to software development comes with massive, hidden architectural costs.
What is the Netflix Keeper Test and how does it work?
The Keeper Test is a management framework where leaders regularly evaluate their team members by asking if they would fight to retain them if they resigned. If the manager wouldn’t fight to keep them, the employee is promptly let go with a generous severance package. From what I've observed of the Netflix culture, they frame this by saying they aren’t a family—they are a high-performing professional sports team.
I’ve definitely been in situations where I’ve looked at certain colleagues and thought: If I were starting a company tomorrow, I would fight tooth and nail to hire them. I’ve also looked at others and thought: They’re fine, but I wouldn’t exactly go to bat to keep them. It’s a natural human distinction. However, Netflix codifies this. In their model, "adequate performance gets a generous severance." They prioritize talent density above almost everything else, replacing anyone who isn't an absolute superstar.
Why does the Keeper Test harm psychological safety in software engineering?
In my view, software engineering is an inherently creative and experimental discipline, meaning it requires psychological safety to thrive. I believe the Keeper Test directly undermines this safety by fostering a continuous fear of termination, which forces developers to avoid risky but potentially breakthrough ideas. When every mistake or temporary dip in velocity could mean failing the "test," I've noticed that engineers naturally default to safe, predictable choices.
Consider what happens when you build systems under threat. You don't refactor that fragile legacy module because if you break production, you might be out of a job. You don't propose a bold architectural shift because it’s safer to ship incremental, boring features. When we treat engineers like professional athletes who are only as good as their last game, we ignore how software is actually built. To me, writing code isn't a sprint down a track; it's a highly collaborative, iterative process of debugging and learning.
| Team Metric |
The Keeper Test Model (Sports Team) |
The Psychological Safety Model (Collaborative) |
| Primary Driver |
Performance & Talent Density |
Trust, Growth & Innovation |
| Risk Tolerance |
Low (Mistakes can lead to exit) |
High (Failure is treated as a learning tool) |
| Collaboration |
Competitive (Individual survival) |
Cooperative (Collective ownership) |
| Long-term Retention |
Low (High churn by design) |
High (Preserves institutional domain knowledge) |
In my experience, leaders can balance high performance and trust by establishing clear, objective expectations and treating performance issues as collaborative debugging sessions rather than immediate failures. Instead of a binary "keep or fire" test, I recommend implementing transparent growth paths that give engineers a fair runway to improve. This maintains high technical standards without triggering a constant state of survival mode.
I like to think of your team's talent like a complex microservice architecture. If a service starts throwing 500 errors, you don't instantly delete it from the cluster and deploy a brand-new, untested service. You look at the logs, find the root cause, and refactor. I believe people deserve the same systematic approach. High standards and psychological safety aren't mutually exclusive; in fact, I don't think you can have sustainable high standards without trust.
Frequently Asked Questions
Does the Keeper Test increase developer turnover?
Yes. By design, the Keeper Test increases both voluntary and involuntary turnover to maintain what Netflix calls "talent density." However, in my observation, this often results in a massive loss of institutional domain knowledge, making systems harder to maintain over time.
The best alternative is a transparent, continuous feedback loop coupled with a structured growth plan. This gives underperforming developers clear, measurable milestones and the support needed to hit them, treating termination as a last resort.
Can psychological safety and high standards coexist?
Absolutely. High psychological safety combined with high standards creates an environment of accountability and continuous learning. When developers know they won't be fired for an honest mistake, they are far more willing to take the calculated risks necessary to build outstanding products.
