Cross-team collaboration

A few years back, in one of the organisations that I had worked with, one of the teams was known for being super non-supportive. You report any issue or raise a query, and you would get a this is not our problem response in a matter of minutes. This team’s deliverable was one of the foundational components for us, and so we often ended up reporting issues/clarifications to them.

This was a remote team and once I happened to travel to their location and met their lead. In the hour that I spent with this person, I realised something I was missing. They genuinely kept getting a large number of issues or requests from a number of different folks in the organisation. As per that team’s experience most of these requests were invalid issues, or issues in the user’s application itself. But the engineers on this team spent more time setting up tests and instrumentations only to realise it wasn’t their problem. These wasted context switches affected their development schedules.

Over time, they developed a simple filter: a this is not our problem response. Only the most serious issue reporters persisted beyond the first or the second response. By the time they heard back on an issue the 3rd time, chances were the issue was genuine enough for them to look into.

Having this conversation was an eye-opener for me. I could relate to the problem that they faced (although not to their solutions).

Over time a working relationship developed. That team figured out that when our team reported a problem, we really did our homework, provided concrete test scenarios and analysis; and hence the issue (or feature-request) was definitely something serious to look into.

Since then, when I happened to talk to other teams within the organisation, they used to say to us either of: “you have it easy, I would love to understand what kind of ‘setting’ you have with that team”, or, “you folks must be really aggressive”.

As a manager/leader we frequently end up in situations where we have to deliver/influence outcomes working with teams/partners that don’t directly report to you. There’s tons of posts about lateral influencing, but here is a quick list of what I have been thinking.

• This happens in all organisations, at all levels. Stop with the self-pity, of you being in this unique awkward position because of your current organisational structure¹. Own the problem, you have to solve this, that’s what effective managers/leaders do. Deliver the result, not an excuse.
• Everyone starts out new, everyone makes mistakes as they manoeuvre. The more such problems you solve, the better you become at solving these problems.
• If you read the story above, you will of course feel that solutions adopted by the particular team were incorrect, and they should have a better process. May be. Make yourself heard. But you won’t know their compulsions and priorities until you are that team day in and day out. It’s easy to throw solutions from the outside. So don’t bank on the team picking up your solutions and changing their processes immediately. You own your problem, they don’t. Build a relationship, understand their pain-points and do the extra work, to make it easy for them to assist you _today_, not after a year long process change that you advocate.
• If you are in a startup, delivering innovations, you have to think out of the box. This, by definition, implies doing things that are new. Something that you think is ground-breaking may be plain stupidity for the other teams. Reach out, provide context, explain your vision, understand their perspective. Ideas evolve through this. The more a team participates in the solution-making process, the more they identify themselves with the cause. Everyone is motivated for improving the organisation in ways that they think are right.
• Be firm on the end-goal, but flexible on the path towards it. Sometimes you may end up with a compromised solution in the interim. Given everyone’s priorities, identify what compromised solution is acceptable to you, for now. Keep making progress.
• If all else fails, do it yourself instead of relying on the other team. Its not always possible in all scenarios, but in many cases it is. Externally perceived expertise and knowledge isn’t always as large a moat as it is in your mind. It will be hard, of course, but not impossible.
• If you don’t have any option left, escalate.

Finally, its not always that you can effect all changes. If you genuinely associated yourself with a problem, and tried all ends to make it happen, it shows. People won’t look down on you, if it doesn’t eventually happen. An experienced, tenacious leader, developed through experience, that’s great to have on any team.

1 — If you feel strongly about it, by all means, you should also start talking about what you think a better organisational structure is and how it can be changed. Everything is a process, it takes time for the best solution to evolve. But don’t stop delivering in the short-term awaiting speculative changes in the long-term.