I once worked as a business development manager for a startup. As someone who was responsible for new projects, I was very much client facing and interacted with many different departments to ensure project success. One of these departments was the software development team.

The developers spoke a different language. Whenever we had conversations, they used technical terms I didn’t understand. Whenever we talked about timelines, I was unable to get a firm commitment in writing. Whenever we discussed the possibility of creating a particular solution, I received a host of reasons why it wasn’t possible and very few why it was.

The developers weren’t receptive to my suggestions and didn’t want to share information; communication broke down at every corner. There was a disconnect.

When faced with a disconnect like this between teams in your own company, how do you deal with it?

Understanding the Disconnect Between Teams

A good starting point is to discover the reasons for the disconnect. Sometimes these reasons are obvious and explainable through differences in job roles. Other times, they’re less clear cut; one bad experience between departments, for example, can cause long-lasting friction and resentment.

Job Role Differences and the Effects of Silos

Companies consist of various departments, marketing, sales, technical, IT, finance, etc. These departments operate a certain way and often using jargon only they can understand. The employees in these departments also have jobs to perform.

Anything outside their job is viewed as a distraction, so they ignore it. And it makes perfect sense: Everyone has limited time and focus; if employees were to constantly worry about other people’s jobs and focus on those details, their own would suffer. Some form of disconnect will always be present in a company. This, then, partly explains the disconnect I had experienced with the software development team.

Problems arise, however, when silos are formed. According to Business Dictionary, the silo mentality is defined as “a mindset present in some companies when certain departments or sectors do not wish to share information with others in the same company. This type of mentality will reduce the efficiency of the overall operation, reduce morale, and may contribute to the demise of a productive company culture.”

The software development team had formed a silo, with subsequent negative effects on efficiency, productivity, and my ability to communicate to clients and deliver projects on time.

Beyond Job Role Differences

Sometimes, though, other underlying factors cause friction. As I soon discovered, after speaking with the developers and watching how some sales employees interacted with them, resentment was underlying.

The developers had far too many negative experiences with certain sales representatives in the past—the ones who had promised clients unrealistic software solutions within ludicrous timelines without first consulting the software team about the constraints and then expected the same team to bend over backward to deliver, the ones who had walked into the software department and demanded project updates, and the ones who had viewed the technical team as workhorses instead of human beings.

The developers had begun to associate anyone from that department, including me, with those negative experiences, so they pushed back out of resentment.

Finding Ways to Remove the Disconnect

Armed with an understanding of why the disconnect exists, you can now find ways to remove it. There’s no one-size-fits-all strategy—it will depend entirely on whether the disconnect is caused by differences in job roles or if it’s something more severe.

If the disconnect is due to a difference in job roles, employees should list what information they absolutely need (and what they don’t need) from another employee to do their job properly.

In his article on workplace silos, Andy Silber uses the example of how a sales team needs information on new product launches, the cost of those products, and product features. He also adds that specific details, such as where the product was built and the production methods used to create them, aren’t necessary unless those methods are part of the unique selling proposition.

The point is sometimes, you just need to let others know what information you need to do your job. By keeping it relevant and on point, you don’t waste their time or yours. Remember, you are part of a company and will likely receive the same request from another employee in the future, so return the favor and create a culture that values the transfer of information.

If the reasons for the disconnect are something more, then you need to regain the trust and respect of the other department. There are various ways you can do this, such as treating people like human beings and making business decisions based on their input. In my case, I did the following—and yes, you guessed it, it was the exact opposite of what the sales types they’d grown to hate would do:

Instead of making unrealistic promises to the client, I first consulted the software team to get realistic timelines and an understanding of what was and wasn’t possible. The team was very much part of the entire process, and they knew that.

Instead of barking orders and demanding updates, I treated the team with respect. I kept them informed on project progress and asked for regular project updates, which they happily shared because I treated them well.

Instead of only caring about the client and final outcomes, I showed a genuine interest in their work. Taking the time to understand their world and how they operate reduced any friction between us. Over time the developers became more receptive to my suggestions and the barriers that once existed all but evaporated. We were now a team. We collaborated. We communicated. Most importantly, we treated each other with respect. All these factors combined contributed to our success.