--- title: "Dangers of Survival Mode" url: "https://www.5whys.com/articles/dangers-of-survival-mode.md" canonical: "https://www.5whys.com/articles/dangers-of-survival-mode.html" published: "2014-11-03T02:07:59.827000+00:00" updated: "2014-11-03T02:14:44.003000+00:00" tags: [] author: "Roy Osherove" description: "Lessons from a LEGO exercise on how leaders react in survival mode, and why deadlines, low quality and team behavior are not givens." 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/" --- # Dangers of Survival Mode I have just finished teaching a two day elastic leadership class in Denmark. One of the exercises I ask leaders to do is to try and finish a time based LEGO building exercises while the world if crumbling around them (lots of factors that create chaos). The goal of that exercise, where I play the customer, is to win by delivering to the customer what they expect to be delivered. This does not mean that what was initially discussed as the requested building is what will be delivered. Team leaders are expected to negotiate and try to change their surrounding "reality" by discussing and explaining to the customer what they can and cannot deliver, and negotiate on time, feature scope, or amount of people they can work with to achieve the task. It's always a very interesting experiment to see how people handle the stress associated with Survival mode. _Survival mode_ is that awful place where you are over committed and have no time to learn, so you are left only "reacting"; fixing fires, cutting corners, and never really proud of your work. Many times it is a spiral, since lack of time to do things "right" leads to much more messy fixes, and slower release cycles, since everyone has very little confidence in whatever it is they are building. So, how do people, even leaders with experience, react under this situation? In a very human way. The most common reactions are: - _Give up almost immediately_. As a customer, I tell them they have x minutes to finish, and not even a hint of trying to negotiate, or saying that this time frame doesn't fit the work. Many accept this time limit as a given even without asking simple things about the scope such as "how big is this LEGO bridge supposed to be" or "which color does it need to be?" - _Forget to show demos along the way_ so they can see if they are doing the right thing. Then failure ensues as what I requested and envisioned in my head is very different that what they envisioned. - During the work, _fail to notice any team bottlenecks_. For example people with disruptive behavior. - If helping out as part of the team, _forget to look at the big picture_, such as how much time is left, showing demos, or are there any inherent problems in the way of work. As a result, many teams fails to give what the customer _expected_ in the time negotiated. And many teams fail to even negotiate a reasonable amount of time, or even notice they are building the wrong thing in time, or at all. You might say "It's just LEGO." But lots of the same symptoms arise in real life software development (and other types of teams).How many projects have you been to where, on the _first_ day of the project, you knew it was going go fail? There is a certain release in knowing something like this. It helps you shed any responsibility to the well being of a project, and you feel less accountable. Here's the problem with that approach, though. _Many team leaders are "thrown" into a dire situation, thinking that the whole situation is "a given". A fact of life that cannot be changed._ Doomed project? Guess we're screwed then. Nothing left to do but twiddle your thumbs. No. You are _paid_ to _change_ the situation you're in, and do good professional work. If that's not what you are paid to do, I think you should leave your job. Most software team leaders have options if they started looking, and there are plenty of companies out there looking for people who want to be proactive bout making things right. So, what are those things that people think are "given" that aren't really most of the time? - _The time you have to finish the project is not really a given_. It is a direct factor of the estimates that you give at the beginning, and as time progresses you _can_ and _should_ ask for more time/ change of scope or adding team members (although that might make the project even later in some cases) - _The low quality is not a given_. You can change the low quality (at least for new work) by demanding it from your team. Don't have time? make time. Re-estimate. Is that scary to do? Guess what, part of being a leader is doing things that are uncomfortable. - _People's behavior in your team is not a given_. You can influence and help change unproductive behavior. Sometimes leaders avoid directly talking to people in their team about unproductive (problematic) behavior. Part of the work. You don't have to be an asshole about it, but you can be direct without being hurtful. People need to know that there are consequences for problematic behavior. You can even ask people to stop contributing, or ask for people to be replaced. Though usually you should try and work on the problem instead of getting rid of people. It will do good for you as well to try and jump into such a challenge, and you will learn a lot from it. ## Read next - [Definition: Survival Mode](https://www.5whys.com/articles/definition-survival-mode.html): A short definition of survival mode, the spiral of fighting fires with no time to learn, and how removing over commitments helps break it. - [12 Behavior Anti Patterns You Will Face As a Software Team Leader](https://www.5whys.com/articles/12-behavior-anti-patterns-you-will-face-as-a-software-team-l.html): Twelve team member behavior anti-patterns and three outside disruptions a software team leader faces in survival mode, with how to respond to each one. - [Signs you might be in survival mode](https://www.5whys.com/articles/signs-you-might-be-in-survival-mode.html): A list of early warning signs that a software team is in survival mode, such as constant urgency, missing context, no time to reduce risk and long stress. ## Topic - [Survival Mode](https://www.5whys.com/topics/survival-mode) --- ## 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/