The valiant hero stands with their cape flapping in the wind. Feet planted in a broad stance, fists balled on their hips, muscles bulging, the big red “S” on their puffed-up chest glinting in the sun as civilians cower behind them. “Stand back! Get away from them!” the hero booms. “I must protect my team!”

In this case, the “S” stands for Scrum Master, but I hear this sentiment from all kinds of software leaders: managers, product owners, architects, product managers—anyone who might feel responsible for a busy group of people (usually engineers). And this directive is usually handed down to them from their leadership or trainers. If the exact instruction isn’t “Your job is to protect the team,” the implication might come through in phrases such as:

“We’re evaluating the teams based on velocity.”

“Meetings take people away from doing real work.”

“We need more hands on keyboards!”

The implied ending to the imperative “protect the team” is “… from meetings, interruptions, distractions, complaining users, pushy stakeholders, and anything else that keeps them from typing one character after another into their consoles.”

I can see why people get so committed to the idea of protecting their teams. Most software teams do suffer from too many interruptions. During a retrospective, you might see “meeting fatigue” raised as a complaint. In one-on-ones, you might hear “I only had an hour to actually code yesterday.” And, while I don’t think that a team’s performance should be strictly measured by velocity, if your team can’t deliver stories, that is a problem.

But what I often see is that in their attempt to shelter their teams from distractions, leaders end up “protecting” them from valuable context that would help them build better software and from participating in conversations that shape the product.

I’m a consultant at VMware Tanzu Labs (which you might know by its former name, Pivotal Labs), where we believe in balanced teams with a high degree of autonomy. That means that each role should have a hand in each discipline—product managers can weigh in on tech stack conversations, designers should push back on priorities they disagree with, devs should negotiate the scope of a user story. Additionally, the team themselves should have the strongest voice in their solutions, rather than having detailed plans assigned to them by leadership. We’ve found this to be the most effective culture for building great software, but it only works when team members have enough context to make informed decisions. That’s where the well-intentioned “protection” of the team can become counterproductive.

Do your engineers sit in on user interviews? It’s amazing to me how different the team conversations are once this starts happening. Just one or two sessions and our whole team becomes user advocates, saying “But we’ve been hearing this in user research” and “Our end users are saying that’s not a priority.”

How closely does your team collaborate with other teams in your org? Do they work directly with teams they share dependencies with or do solutions get assigned down without their involvement? Not only does letting interdependent teams brainstorm and talk through solutions together usually lead to better ideas, I also love the relationship building that happens in these rooms.

Do you include your cross-functional team in design studios? Some of the best ideas I’ve seen have been sketched by engineers and data scientists. Besides that, participating in the conversation can lead to a better understanding of design thinking, and therefore better interdisciplinary conversations down the line. (Also, design studios are fun!)

But these are some of the many activities that overzealously protective leaders try to bar team members from.

The thing is, a balance needs to be struck between the need to free up time for deep work and the value of shared context. Over-rotating in either direction is counterproductive, and exactly where that happy medium lies depends on many factors, such as the complexity of your product and whether or not your engineers pair program (which makes context sharing more organic). If you’re worried about how to bring your team into more discussions without keeping them from doing heads-down work, here are a few tips that I’ve seen work:

Provide clear priorities and goals. Lack of focus comes when teams don’t have a clear understanding of what’s important, so they can easily fall into a reactive mode where everything that pops into their Slack or onto their calendar becomes the new de facto priority. If you help your teams understand what is important, they are empowered to do their own sifting and sorting through what activities will be the most helpful without you bringing the hammer down and cutting them off from the rest of the business.

Rotate responsibilities. Not everyone needs to be present for every meeting. Instead, bring various team members into different discussions, and provide opportunities for them to share context among each other. My colleagues and I at Tanzu Labs have experimented with several approaches to this. One is to have a daily “interrupti-pair,” a pair of developers who handles all non-coding work for the day: attending meetings, answering questions, troubleshooting defects, and any other ad hoc tasks that come up. On other teams, we’ve taken the opposite approach: having a “veloci-pair” (named so because they keep the velocity moving) who are completely sheltered for the day, while any other team member can field questions or attend meetings as needed. In non-pair programming environments, I still try to make sure I invite two engineers to every relevant discussion: one with enough context to contribute helpfully, and one with less context who is there to get up to speed.

Cluster meetings at transition times. To optimize for flow state, you want to provide your team with fewer interruptions and longer periods of coding time. To balance this need with the context-sharing collaboration time, try bundling your meeting times with times the engineers would be interrupted anyways: the beginning of the day, before lunch, after lunch, or the end of the day. While they will still be sacrificing some coding time, most engineers will say they prefer this type of schedule rather than a constant stream of smaller interruptions that keeps them from getting to deep work. (Here is a Miro Template to help you lay out daily schedules across time zones.)

These are just a few suggestions, but the most important thing is to experiment with your team to see what works for you. People may have different learning and working styles, and different schedules and circadian rhythms, that you’ll need to collectively adapt to. Once you have a strategy, you can channel that superhero energy into helping your team gain relevant context and turn it into actionable insights, rather than shielding them from it. That’s how you develop into a whole team of superheroes.

For more insights on the Tanzu Labs approach to product management, Download the VMware Tanzu Labs Product Manager Playbook.