One observation I'd like to share about team dynamics is that many groups form their identities around team names, charters, or visions. Though this is helpful in terms of group formation, it can also limit how the team contributes to the organization. When I say "limit," I refer to their sense of scope of work (aka "that's not my job") to a more nuanced one, like the vision of how they contribute to company goals. Let's see an example:
Nowadays, many companies create a team with the name of a specific technology or service. For example, a company with several development teams funds a team to help others simplify their deployments. They decide to use kubernetes, naming the team: "Kubernetes Team".
As the team matures, they'll naturally focus on solving problems solvable with kubernetes. When a new case for running a service in virtual machines requires building or adopting some additional tool that allows the other teams to simplify their deployments, they might not even consider it because it's not in the scope of the "Kubernetes team."
So you're saying that when you build a team and put a name on it, they will create an identity, which can be constraining, so how do you solve that problem or make it better?
I'm not sure this is a "problem to be solved," but something to consider and discuss with the team. It might be tempting to "try to find better names"*, but better names will not be sufficient in the end. You may attempt to keep this observation on your radar, discuss it with the team, and help them build a flexible mentality to respond to new needs.
*Note: By the way, it is better when teams are called for the outcome they try to achieve rather than the technology or piece of code they own
Follow me on Twitter or subscribe to the newsletter for more articles on software engineering leadership and troubleshooting software engineering teams' problems.
