--- title: "Burst your team's bubble - stop protecting them from the surrounding organization" url: "https://www.5whys.com/articles/burst-your-teams-bubble-stop-protecting-them-from-the-surrou.md" canonical: "https://www.5whys.com/articles/burst-your-teams-bubble-stop-protecting-them-from-the-surrou.html" published: "2011-06-17T21:54:16.427000+00:00" updated: "2011-06-17T22:14:09.343000+00:00" tags: ["Learning Phase"] author: "Roy Osherove" description: "Why, in learning mode, a team leader should stop shielding the team from the organization and let sales, marketing and support push their growth." 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/" --- # Burst your team's bubble - stop protecting them from the surrounding organization During [the learning phase of your team](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html), one of the nicest things you can do for your team members, is to stop protecting them from the surrounding organization. It was a great thing to do during the chaos phase, when you all needed time to put out all the fires. But now, that you have some time to learn new things as a team, that learning can be triggered by letting the organization "leak" into your team. You can start doing it incrementally at first. It doesn't have to be a burst, but you can start with allowing some of the following to occur (under careful watch): - **Allow the sales folks to walk into the team's room and ask questions or make demands.** Your team will start feeling the pressure from within the organization and start learning how to deal with it, or how to face reality of what people in the organization feel about their performance as a team. They will, with your help, develop new skills based on this (such as talking to non technical people) - **Allow the marketing folks to ask questions about upcoming features while the team is working**. Allow them to push for closer schedules. - **Don't bridge a team member's need for something \*from\* the organization** (such as getting better chairs, or a new screen). Instead, ask them what they intend to do about it. See what happens. Back them up with any action they'd like to take (talk to the CEO? Talk to the equipment manager?). Grow their skills in navigating the network that is your organization. Help them realize that they don't need you (besides your backing), to achieve things they need. - **Get the team to do first level support**, and help them develop the skill of creating features and fixing usability problems based on customer talks. facing reality is important for a learning team, and staying in a comfortable iteration where the team is fully protected is nice, but no one is learning from it. > They will not thank you. They will, sometimes, despise you for "breaking" your promise to be their leader and protect them. YOU will feel like you are betraying them a bit as well. That's ok. That's part of YOUR growth path. you're getting out of your own comfort zone (of how to lead a team), by learning how to get your team out of THEIR comfort zone. Explain the reasoning behind it, and follow up with whatever learning they will need to accomplish their newfound tasks. By BACKING them,  I also mean that you are willing to remove some of the development time in support of learning time. A developer trying ot get a new screen might need a half hour or more off, depending on how large your organization is, after all. Here's a simple rule to follow during the learning phase: > If everyone is feeling comfortable in what they are doing, you are not doing your job. Growth comes from doing things you're NOT good at, you're NOT comfortable with. It's that feeling you get when learning a new programming language, a new IDE, or switching from windows to Linux. More about learning, in future posts. ## Read next - [Grow your "feature teams" into just "teams"](https://www.5whys.com/articles/grow-your-feature-teams-into-just-teams.html): Why feature teams built from specialists carry a bad bus factor, and why team leaders should grow them into teams where everyone can do each other's work. - [Two Techniques to Avoid the Bus Factor In your Teams: Push and Pull](https://www.5whys.com/articles/two-techniques-to-avoid-the-bus-factor-in-your-teams-push-an.html): How push based and pull based learning help a team remove bus factors, told through an architect who fixed a search server without learning anything. - [You're not self organizing if you have a go-to architect](https://www.5whys.com/articles/youre-not-self-organizing-if-you-have-a-go-to-architect.html): A quick test for self-organization: if a team must ask an outside architect to finish its work, it is not self-organizing, and the architect should teach. ## Topic - [Learning Mode](https://www.5whys.com/topics/learning-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/