Holding Partner Teams Accountable
16 June, 2021
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.
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.
Director of Software at JANA Corporation
Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.
Engineering Manager - Patient Experience at Curative
Jonathan Belcher, Engineering Manager at Curative, explains how to balance team cohesion and individual focus time, tapping into his experiences of working remotely for seven years.
Engineering Manager - Patient Experience at Curative
Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.
Vice President, Product & Engineering at Amilla
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.
Senior EPM/TPM at Apple Inc.
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.