--- title: "Making Impossible Decisions Without Panicking" url: "https://www.5whys.com/articles/making-impossible-decisions-without-panicking.md" canonical: "https://www.5whys.com/articles/making-impossible-decisions-without-panicking.html" published: "2009-09-07T11:47:27+00:00" updated: "2009-09-13T22:06:58.163000+00:00" tags: ["Shu"] author: "Roy Osherove" description: "How a team leader can make a decision with only bad options without panicking: involve the team, weigh the risks, then run a blame-free review afterward." 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/" --- # Making Impossible Decisions Without Panicking Sometimes you're faced with a question that only has bad answers. A while ago one of my friends was faced with exactly one of those: It turns out that the technology the team chose to use on the project was not scalable enough, 2 days before going into production. They had several choices available: 1. Host the non scalable part on a separate server and hope for the best 2. Change the code behavior (requires lots of testing, in a rush, not a good idea!) 3. find a different technical solution (impossible at that time frame) All these solutions suck. but there is more you can do: - Consult with your whole team for other solutions. Explain them the situation and be _open to hearing other solutions_ without taking them down. - Consider each solution for the time it takes, amount of people needed and the risk involved - Consider combining two or more solutions if it makes sense ## Don't Panic Whatever you do, especially if you're in a time rush - **don't panic**. If you panic - chances are you will rush into a decision without thinking well about it, and might end up digging a bigger hole. in this case going for option #1 and changing the code in parallel could be a better option than just choosing one of them. ## I put out the fire - now what? Now it's time to make sure you learn something from this horrible experience (and we've **all**been there) so that it does not recur. Sit down with your team and try to gauge out the reasons why they think you came to this situation. For example - "We could have done something about this 2 months ago but didn't" - "We could have tested for scalability but didn't" - "We didn't really understand that the requirement was scalability of this magnitude" - "We wanted to do this early but never got to doing it due to lack of time" - "It was lower on our priority list" etc.. Make sure it does not turn into a blame fest - no names. always make sure people use the term "we" since as a team you are all responsible for this. If people try to be negative and say they had nothing to do with this failure remind them that as a team everyone is equally responsible to anything that comes out. After you're done making that list, sit down with the team and make a list of things that you commit to start doing starting today. It will be **your job** as a team lead to make sure the team has the time and permission to achieve these things. Try to not be the only one saying something. Always be the third or fourth person contributing to the ideas, to show people that you expect them to be part of the process. Here is what such a list can be: - "The team commit to doing performance testing of this application on a weekly basis" - "The team will always ask about scalability requirements for all applications from now on, and are they a must to go live" It could just be one item, but one that you can really commit to - make sure _you are not lying to yourself_. ## Read next - [Daily Standup Meetings - Introduction and 5 useful tips](https://www.5whys.com/articles/daily-standup-meetings-introduction-and-5-useful-tips.html): How to run a daily standup meeting with the three questions, why each question matters, and five hard-learned tips for keeping it under 15 minutes. - [Step #4 - Start doing code reviews – Seriously](https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.html): A team leader's guide to serious code reviews: what to look for, reviewing every check-in yourself at first, then training the team to review its own code. - [4 ways to discover a stuck team member, and what you can do about it](https://www.5whys.com/articles/4-ways-to-discover-a-stuck-team-member-and-what-you-can-do-a.html): Roy Osherove recalls being fired as a stuck developer and shows how standups, code reviews, test reviews and pairing help a lead spot and unblock people. --- ## 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/