---
title: "Definition: Survival Mode"
url: "https://www.5whys.com/articles/definition-survival-mode.md"
canonical: "https://www.5whys.com/articles/definition-survival-mode.html"
published: "2013-10-20T11:52:39.097000+00:00"
updated: "2013-10-20T11:59:08.008000+00:00"
tags: ["First Steps during chaos"]
author: "Roy Osherove"
description: "A team is in \"Survival\" mode if they do not have time to learn and slowly practice new skills. Such a team is usually over committed and is too busy chasing fires instead of having enough time to hone and practice the skills that prevent…"
usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)."
license: "https://creativecommons.org/licenses/by/4.0/"
---

# Definition: Survival Mode

A team is in "Survival" mode if they do not have time to learn and slowly practice new skills. Such a team is usually over committed and is too busy chasing fires instead of having enough time to hone and practice the skills that prevent the root cause of the fires in the first place.

For example, a team may be too busy fixing all the bugs that keep popping up, that they do not have time to learn and slowly practice design,  refactoring and automated testing of the code to prevent future occurrences.

Another example: A team is too busy deploying things manually and preparing for a release instead of spending the time to create a release and build chain.

Survival mode is usually patterned as a downward spiral. The less time you have to fix the root causes, the more time you will need to fix the fires that are caused, and then you have even less time to fix the root causes.

To get out of survival mode the team needs to:

1. Remove over commitments
2. Change current estimates to include quality in the estimates (usually an increase estimates on current work by 100%-500% is needed)

By taking these actions you can create a positive loop in which you fix root causes and then have less fires to fix so you have more time to fix more root causes etc.


---

## About the author

**Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery.

### Sites

- [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership.
- [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts.
- [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin.
- [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model.
- [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps.
- [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes).

### Social

- X: https://x.com/royosherove
- LinkedIn: https://www.linkedin.com/in/osherove/

### Contact

- Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7

### License

Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/