Hard to Communicate with Other Teams? Check Out These Tips

Working across departments goes much more smoothly with these processes in place.

Jonas RoslandWhen teams in the same organization—or even across organizational boundaries—start to collaborate, they will most likely realize that not all of their goals align. The IT team, for instance, might not have the same criteria for success as the sales team. Different teams have different benchmarks, even if the teams are part of a larger organization (as in the case of relationships between a developer team and an operations team).

But the teams all strive towards the same goal, which is to make the organization successful. And they rely on each other to accomplish that goal.

For this reason, learning more about why a team is working on a specific project, not just focusing on how they're involved and what the project is about, can help you foster better relationships across your organization.

Focusing on why people act the way they do allows teams to better understand one another's goals and purposes, and helps everyone assume the best intentions from everyone involved in an effort.

Assuming positive intent when working across teams involves a few fundamentals, which I'll discuss in this chapter. First, it involves paying attention to your team's sense of identity. It also involves knowledge sharing across groups. And finally, it involves potentially changing the way you reward behaviors.

"They just don't get it"

Teams typically form strong social group connections, which, on paper, might seem excellent. Teams with strong social connections share willingly and help each other. But a strong sense of group identity can also introduce the real possibility that the group will learn to see itself as different from and sometimes better than other groups.

This may lead to an unhealthy tendency to turn away from those outside the group, which can result in teams not sharing vital information, or increased conflicts and a reduction in the quality of deliverables. Along the same lines, strong social ties can affect team merges, and organizations often encounter difficulties when working with new teams.

This disconnect between teams can lead to simple misunderstandings that are blown out of proportion, leading to frustration and anger towards other teams and their members. If you are part of this strong social group, you might hear statements such as "They just don't get it" and "Why don't they understand?" thrown around as morale-boosters and laughed off. But statements like these aren't helping either team succeed.

One way of dealing with this antisocial behavior is to create a new group dynamic by continuously rotating members or having them work very closely together on joint projects. By doing this you gain new viewpoints and mindsets between the different groups, slowly removing the barriers between them. Removing misunderstandings and friction between teams is imperative when developing a positive working environment across team boundaries. It will no longer be an "us versus them" discussion, but rather a newfound focus on creating value together.

Sharing knowledge

When creating a new open source project or open sourcing a proprietary product, it's critical that the audience that you're trying to reach understands why they should use it or get involved. If your documentation only focuses on how it's built and what it does, the possible success of your project will most likely be limited.

The same is true in any open organization. But by using open discussion platforms, members of a specific project community can share knowledge with each other and encourage involvement by constantly receiving feedback and ideas. The community will amass information and know-how that people can share using different media to promote the project (YouTube videos, marketing material, stickers, logos, code, how-to blog posts, conference sessions, and much more).

A common practice in open source projects and their respective communities is encouraging participation in a variety of forms, not just by writing code. Having a diverse set of people work together across teams where their different specialties are appreciated also means that the project will have greater impact. But on top of that, making sure the community is aware of new features, release dates, and upcoming changes ensures that they can easily communicate to others on how the project is progressing. When everyone is working with the same knowledge, people are more likely to assume they're working with the same intentions, too.

Changing behaviors

When working across teams and with new team members, it's important to recognize the individual strengths and weaknesses within the team and not just view the team as a whole, single unit. Making sure that everyone on the team learns how to deal with new tasks, both rudimentary and advanced, leads to the team working better together and accomplishing more. We can use methods first utilized in the early 1900s to ensure that team members enact desirable behaviors when they're using new tools and processes.

Research done by B.F. Skinner shows that positive and negative reinforcement shapes behavior. Because all actions has consequences, this means that if a consequence is positive there's an increased probability of that action being encouraged and repeated. Likewise, Skinner's experiments show that responses were better and faster when the consequence was positive, compared to when they were treated to a negative response.

This means that rather than waiting to congratulate new team members when they finished tasks, encouraging individuals often and repeatedly while they are progressing through tasks will teach them faster what path to take to complete specific tasks thanks to positive reinforcement.

Thinking about your teams this way you will create a more inclusive atmosphere by removing the notion of "rockstars": team members who always stay late, the ultimate troubleshooters, the ones with all the key information to any decision. Celebrating individuals who pull all-nighters can do more harm than incentivize. The presence of rockstar performers on a team may not necessarily lead to increased success for that team; it can actually have a negative impact on the performance of others.

Research from the Harvard Business School shows that there are three mechanisms that may account for the decline in productivity within teams when certain individuals are seen and treated at rockstars:

• A reduction in effort ("I don't see the point in trying")
• Increased risk-taking ("I must do something amazing to be noticed")
• Deterioration in cognitive processing ("I make more mistakes")

When talking about these star performers, it's critical to understand their role in the team. They're viewed as rockstars for a reason: They excel at what they set out to do. Don't undervalue them; instead, identify a different measure of their success. Celebrating valuable contributions such as customer interactions, education of others, and innovative ideas give teams a more varied view of what it means to be successful.

Creating an inclusive atmosphere by trusting everyone, not just star performers, to be capable of delivering the correct solutions for a certain set of problems can lead to more open and vibrant discussions, suggesting new and innovative ways of thinking. It also makes assuming the best-directed optimal solutions from everyone just a little easier.

As a result of assuming positive intent when working across teams, organizations and international borders, open source community members working together towards common goals can make projects very successful in their mission. This applies for a wide variety of projects such as the Linux kernel, the Go programming language—and this book.

This article originally appeared as a chapter in The Open Organization Guide to IT Culture Change.

Hard to Communicate with Other Teams? Check Out These Tips was authored by Jonas Rosland and published in Opensource.com. It is being republished by Open Health News under the terms of the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0). The original copy of the article can be found here.