--- title: "Do new startup leaders need to grow their teams?" url: "https://www.5whys.com/articles/do-new-startup-leaders-need-to-grow-their-teams.md" canonical: "https://www.5whys.com/articles/do-new-startup-leaders-need-to-grow-their-teams.html" published: "2012-05-01T09:44:28+00:00" updated: "2012-05-01T09:50:41.873000+00:00" tags: ["First Steps during chaos"] author: "Roy Osherove" description: "Why early-stage startups are usually in survival mode with no time to grow people or use TDD, and why learning should start once the direction is proven." 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/" --- # Do new startup leaders need to grow their teams? I've been involved with several small startups. My feeling is that in the first few weeks or months of a startup's life, your main goal is to make sure you're running in the right direction. You're about to release something as quickly as possible (minimum delightful product) to the market to see if you're on the right track. That means that, you're mostly in chaos. you don't have time to learn new skills. You hire the best people and pay them well so you don't have to worry about teaching anything. It's about running as quickly as possible and wasting little money in the process. That means that to me, the learning phase only happens after the startup has matured enough to be in the right direction. after the second funding phase, probably, it has time to worry about things like quality, and growing the people. That's why I would not recommend TDD either when you're just trying to gauge people's reaction to something you might throw away in two weeks. I think that's also the reason why in many established companies who started as startups, the code base is so crappy - because the initial idea was to get something out there. It's fixing the code base that considered part of the "learning phase". But unfortunately, many companies continue to exist in chaos even after initial startup phase, and don't give enough time for skills and practices to be learned by the team. But that's a whole 'nother story. ## Read next - [On time, with quality - why is this mostly failing?](https://www.5whys.com/articles/on-time-with-quality-why-is-this-mostly-failing.html): Why teams fail to ship on time with quality while stuck in chaos, and why team leaders must remove commitments to make time to learn and practice. - [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. - [The Chaos Addiction](https://www.5whys.com/articles/the-chaos-addiction.html): How survival mode becomes a self-reinforcing addiction that cuts quality and learning time, and why a team leader must take a risk to break the cycle. ## 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/