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
Vadim Antonov, Engineering Manager at Meta, dictates how he brought a brand new team into the remote learning process by ramping up onboarding and creating a mentor system.
Engineering Manager at Facebook
Anurag Jain, a leader role at Fortinet, speaks about finding a solution when for a project the apparent needs were not the thing to be solved.
Leadership Role at Fortinet
Anurag Jain, a leader at Fortinet, discusses his strategy to promote growth within his teams, using servant leadership concepts.
Leadership Role at Fortinet
William Bajzek, Director of Engineering at Sapphire Digital, compares and contrasts a team structure that utilized siloed skill sets and one where everybody’s duties overlap at the edges.
Director of Engineering at Sapphire Digital
Adam Hawkins, Site Reliability Engineer at Skillshare, uprooted an entire product and built it back up again with the help of his team.
Site Reliability Engineer at Skillshare
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.