Don’t Let an Inter-Team Crisis Go to Waste

Problem

One of my teams, which I was managing for about six months, was finishing up a deliverable for a new product launch. Everything was going fairly smoothly, though the last week people put in a few extra hours to make sure everything is finished. Then, on a Saturday, I got a note from another senior engineer, from team A, that there is a problem. One of my engineers committed a piece of code that touched another team's code base, and they were incredibly pissed. Accusations of bad intent started flying around, even though the engineer involved was very senior and at the company for a while; I trusted that his main intent was to get the project ready for release. The original reaction seemed to be out of proportion with the offence, and was certainly exacerbated by the fact that this happened over the weekend, where people could not meet face to face to talk.

Actions taken

My engineer addressed some of the immediate concerns that the other team brought up pretty much immediately when we got back to the office, which made things a bit better.

After talking to one of the engineers on team A, as well as their manager, I realized that the incident itself was a mere spark for some long-standing frustrations that the other team had with my teams. Once I realized that there is more going on, I called a meeting with a few key engineers on team A, as well as their manager (I left my engineer out of it, since emotions were still flying high).

I decided that my role was to listen and make sure I truly understand their perspective. What I learned was that because my team's code lived inside team A's application (which was a platform with extensibility points), they had several situations where my team's code caused issues for them. They felt that actions of my teams were slowing them down, and they felt that they effectively sometimes had no choice but to clean up after our team.

First of all, understanding their perspective helped me understand the interactions between the systems better and helped me do a better job anticipating future issues. More immediately, I realized that there were a few low-hanging changes we can make to start improving the situation and show that we were taking their concerns seriously. With a bit of time, as part of an unrelated refactoring, we worked to reduce dependencies between code modules. I had a coop work on one such dependencies, which was a highly visible change. Additionally, the other team improved some of the interfaces that other teams used to integrate with them, so the APIs were both clearer and the extensions easier to manage.

After a few months, one of the engineers that originally was the most upset, told me he felt my team was now working better with his!

Lessons learned

• Sometimes when somebody seemingly over-reacts, it's an indication of latent problems that have been building up for some time.
• Truly listening to people to understand their concerns helps alleviate tension; understanding the needs and concerns of other teams can help you prevent problems down the line.
• When you have a team you work with regularly and some of your code integrates with their application, you need to dig deeper and make sure you truly understand the interfaces, as well as some of the history between the teams to ensure smooth collaboration.