Holding Partner Teams Accountable

Problem

We were working closely and had multiple dependencies on a partner team. At some point, the disagreement between us on how we should solve a particular problem culminated. I was able to identify several lines of disagreement between our two teams:

• We couldn’t agree on how we should split responsibility between two teams. There were certain areas where the responsibility was clear, but then there were other areas the lines were blurry.
• We couldn’t agree on a timeline. The partner team would commit to doing something by, let’s say, next month and would fail to do so. We would be blocked for a certain amount of time by waiting for them to deliver on their commitments.
• We couldn’t agree on quality. Quality was not up to par -- we would not get what we asked for. Also, their support was inadequate; when we would ask for clarification, it would get unanswered.
  

Actions taken

Splitting the responsibility

I tried to talk to a manager of the team and reach an agreement with them on where the demarcation line would be and who would be responsible for what. We met two or three times but simply couldn’t come to an agreement. However, what we could agree on was to escalate the issue and involve our higher-ups to make the call. We both came up with a set of solid arguments why we should (not) be doing something.

Introducing regular check-ins

Another disagreement that troubled us was that we had a long-term commitment but without any benchmarks along the way. Frequent check-ins every two weeks would help us track their progress and allow us to raise our concerns early. However, if we would wait two months (as we did initially), that would be too far behind for them to catch up. Therefore we decided to introduce biweekly check-ins to ensure the team was making progress in the right direction.

Ensuring quality

We also made sure that whatever our engineers would have to implement, they would be involved in earlier stages. Even if that is only a draft, design document or unfinished work, our engineers would be reviewing it. That way, once it would be handed out to us, not everything would be fully baked, and we could put in our feedback and impact the further development. By doing so, we curtailed the possibility of going too far on one path and having to backtrack and redo a lot of things. Thus the early involvement of our engineers had a direct impact on the quality.

Finally, we decided to be serious about documentation and keep a written record for all the commitments and agreements. Everything we would agree on would also be in writing with due dates and precise deliverables.

Lessons learned

• Try to reach an agreement. If that isn’t possible, don’t back down from escalating it. If you can’t reach an agreement with a peer, you shouldn’t be fearful of having your higher-ups involved. Part of their role is to help you resolve disagreements you have with your peers. When you are certain that there is no path forward, escalate as soon as you can.
• Write down all the commitments. People can discuss various commitments, agree on some and then forget about most of them. Also, when commitments are discussed informally, people may have different interpretations of what was decided and by when. If you put that on paper, you can always go back, look at it and hold other people accountable.
• Have regular check-ins. If your dependencies on another team are long going, rather than waiting a few months to see the progress, you should have some mid-point check-ins to timely respond to their actions.
• Involve people who will be affected by implementation early on. They should be the ones to evaluate if it is something meaningful and/or feasible because they will be the ones to implement it.