4 Steps To Solve Cross-Team Dependencies
Sooner or later, you’ll be asked to reach out to another team or person to solve a cross-team dependency and you will have to defend your arguments in the discussion. How do you prepare for it? Where do you start? I am going to explain here what I’ve learned in my experience so far.
I work in software development and I was recently asked to provide technical support to another team who joined my department, let’s call it the A-Team. Eventually, they got blocked in the development of a new feature by some dependency with another team, the B-Team. So, the A-Team came to me and asked if I could escalate their need to the B-Team and get things moving. That’s easier said than done! Also because, since I’m not really part of the A-Team, I had limited knowledge of what they were doing.
I had some doubts in the beginning: Where to start? How to do it? Who to talk with? There are many aspects to solve to do it right.
I think that now I have a better idea of how to proceed and I’ll be improving my process along with my experience. Here are my suggestions…
Step 1. Analyze the situation
The first thing to do is to analyze the situation. In my case that meant to investigate:
- what is the feature that the A-Team wants to build? How should it work? How/why is the development blocked?
- has the problem already been reported to the B-Team? Do they already know that another team depends on them? Is the problem tracked somewhere (like a Jira issue or something)? If the B-Team doesn’t even know about it, then, before escalating it, I first need to communicate the problem.
Gather all this information to build your case.
Step 2. How bad do you want it?
This is the most important point! I asked the A-Team:
- why do you need this? You need to collect the use cases, the reasons behind the request. How many user stories or features are blocked? When are those features expected to be delivered? Who requested those features? Was a customer, the PO (product owner), one of the higher executives of the company?
- what’s the impact of not having it? How will the customers be affected without that feature? Is it pure UI or does it include any back-end functionality? Can the A-Team develop a limited version of the feature, or a subset of features? Is there a workaround for the customer? is there a b-plan to develop the same behavior in a different way?
Sometimes answering those questions is not easy. You may need to talk to UX (user experience) designers, POs or other architects. Collect this information to better understand the impact of the feature and the motivations behind it.
Step 3. Do your homework! Who do you need to talk to?
You have to reach out to someone in the B-Team. But who? There are many ways to find an answer:
- If you’re lucky, you or someone of your team know already someone of the B-team;
- you can use an internal portal like Confluence, or use git blame, or similar, to find the owners of a feature.
Then there are two things to consider here: technical knowledge and/or authority!
If it’s technical knowledge you seek, you have to look for the people who have it. Here are few examples:
- say that you need to develop something but you don’t know how to use a resource from another team, like a service, a framework, a UI component, etc… In this case, you may want to reach out to an engineer of the other team, preferably senior;
- say that you are designing a complex feature and you need to agree with other team(s) on how to do it. In this case, you may contact the other team leader(s) and agree on what to do, or schedule a meeting with them, the team architects if needed and senior developers. You may want to include also the POs of the other teams.
It may be authority that you need. For example, say that the A-Team is blocked by a feature of the B-Team which is planned for later or has low priority; then, you need to discuss to someone to change the priorities of the of B-Team. In this case, you have to be extra careful when finding the person to contact.
This is very important and let me tell you why! Imagine that a ticket of the B-Team is assigned to a person and you don’t know who this is. You’re about to contact him/her in Slack directly, but then you have a moment of common sense and you investigate who this person is. Then you realize that she’s director of the UX design department (true story!) so you have a second thought and you decide to contact someone else who reports to her instead of wasting her time! Then you’ve earned a point in diplomacy!
Of course, some day you may need to contact someone higher.. but first, be sure that the situation and your urgency justify it.
In any case, find the right person and use good manners when presenting your case.
Step 4. Find a sponsor, someone to back you up
Depending on the situation or on the outcome of previous meetings, you may need to escalate on your side! This means that your authority is not strong enough (yet!) to get you what you need. In this case, talk to your direct superior or your team leader, your scrum master or your team architect, depending on the case. It’s part of their job to support you. They should be able to help, either by putting more pressure with their authority or by giving you some other suggestion you didn’t think before.
Some other common sense
Here are few extra suggestions I came out with while writing the article.. nothing from another word, just some common sense :)
Assume that the B-Team doesn’t know your problem
This happens constantly. Be ready to explain your problem clearly from the start. As you don’t know everything that is happening in other teams, you can’t expect that the rest of the people knows about yours.
When looking for someone, beside their position or role, try to understand what’s their knowledge
This is especially useful in meetings. Maybe you schedule a meeting with the B-team and they forward it to someone else. Who’s this person? What’s her expertise? Why is she needed? Asking yourself these questions will get you more prepared for the meeting.
They may want to help you but they are busier than you hoped
As technical persons, when you have a dependency with another team, this is one of the most complicated situations.
Probably having your PO in the discussion will help, since he/she can leverage the priority of your feature from a project management perspective. Eventually, be prepared to have to find some compromises: maybe you can split the whole initiative in two iterations and deliver half of it first. Or, your team can help the other and do part of or all the work needed to get unblocked (maybe after a short technical introduction). Depending on the situation there are different ways you can get through. You can get creative and brainstorm a solution with your team that works.
Conclusions
Dealing with a cross-team dependency is never trivial. You have to think about lots of aspects: gathering enough knowledge in order to understand yourself the problem, being able to explain the problem to someone else, find the right person to talk to, being able to defend your arguments, etc...
The suggestions I gave here are not specific to the IT world: you can easily apply them in any other circumstances, even not work related. Any time you need to talk with someone else, explain your case, justify your motivations, etc.
At the end of the day, it all comes to being a better communicator! Always keep in mind who is in front of you to send the right message in the best way!
