Proactive Collaboration

This post is about my experience on how embracing proactive collaboration can help solve multi-dimensional, cross-team problems that I encounter regularly as a software engineer.

The challenge

I want to share a recent issue I bumped into at work that reminded me just how powerful proactive collaboration can be. The problem revolved around a required role to access one of our features–a case that proved surprisingly hard to reproduce because of inter-team dependencies and the multiple API versions we maintain for the same functionality.

My task was clear: investigate the problem, identify the root cause, and propose a long-term fix. I've managed to complete the first two steps–investigation and root cause analysis (RCA)–thanks to the combined effort of my teammates, project manager, QA engineer, and engineers from other teams.

Here's how.

Over the last few days, I focused on collecting every fact and piece of information I could: reproducing the issue on my own, reviewing past investigation documents, and confirming the actual behaviour with relevant stakeholders. Then, last Friday, while discussing the case with our QA engineer–who had been working on it for the past three months–I finally had my "Aha!" moment.

It started as an asynchronous Slack exchange, with each of us adding our own context and nuance. When we hit a dead end, I suggested we jump on a Zoom call to sort things out. After about 30 minutes of discussion, we invited my teammate to join so we could reproduce a scenario that neither of us could replicate alone. That collaboration led us to one unique case that reproduced the issue perfectly and revealed the root cause in a single, clear sentence.

That experience reinforced my belief that collaboration, moreover, the "proactive" one, is an essential skill for software engineers–especially when tackling cross-team, multi-dimensional issues. A problem solver working alone may not uncover the root cause without the full context: how the issue first occurred, which components it affects, why it might behave differently in other environments, and other critical questions unique to the case.

My early lessons

Cross-team communication wasn't new to me. I first learned its importance while working at Xendit. Given the nature of the business, collaborating with other teams was inevitable. This was especially true in the invoice team, where we handled various payment channels–each involving coordination with people from different teams, which have their own processes.

In practice, I often needed to reach out to someone from another team (and mostly one that I haven't worked with before!) and get an actionable answer or a clear next step in return. Here's an example of the kind of message I typically sent:

In relation to the above message, some of you might be thinking:

"Why don't you just check the API documentation or Swagger?"
"Doesn't the error response tell you what to do next?"
"Why not just read the code for that endpoint?"

Well, as the old saying goes: "easier said than done". Those options aren't always helpful–or even possible. The API might lack documentation because it's considered "legacy", the error message may not be actionable, or we might not have access to the code at all (by design, to comply with security or governance rules).

In such cases, sending a message with enough context and detail is the most effective way to make progress without unnecessarily interrupting someone's work. It shows that we've already done our best, and when we do reach out, we're asking targeted questions that enable the right person to give us a useful hint or next steps.

From practice to habit

Since then, I've applied this approach whenever I face a problem that requires cross-team collaboration: do all the possible work myself first, and when stuck, ask a precise question to the right person. However, if I don't know who the right person is, I usually ask my teammate to point me to one.

This habit didn't form overnight. It takes more than being able to phrase the right question to the right person. It requires adopting the mental model of understanding the why–the underlying cause of a problem–rather than stopping at the observable effect, or symptom.

That difference matters when it's time to propose a solution. If we only understand the symptom, we're more likely to create a shortcut or temporary fix, which most of the times lead to new issues down the road. But if we identify the true cause, we can design a long-term solution that addresses the real problem without introducing new ones.

Acting instead of waiting

Another mindset I've found valuable is to default to acting, not waiting, when facing problems that require cross-team coordination. After sending an inquiry to another team, it's easy to feel like "ok, I've done my part, let's wait for others to come back to me with a concrete solution". In fact, that's not always the case, and there's often plenty we can do to anticipate and prepare for the answers we might receive:

• Document all findings in one centralised place–so if they ask for past investigation, we can give them
• Consider multiple scenarios based on the current information–so if they ask for a specific scenario, we can give the details to them
• Plan for the worst case, such as not getting the answer we expect

That last point can be tricky, especially when we're operating in a gray area and upper management still expects progress. In those situations, I typically report blockers to my direct manager and see if they can help expedite the process. The key takeaway: don't wait–act.

Conclusion

I've been applying this style of collaboration for about six years now, and from my experience, it works across a wide range of business domains, company sizes, and work settings–whether remote, hybrid, or onsite. At its core, it's about adopting the mental model of getting to the cause of a problem, no matter what actions it takes to uncover it.

Collaboration–especially proactive collaboration–is more than just working together. It's about bringing together different perspectives, expertise, and context to solve problems none of us could tackle alone. And when progress stalls, it means stepping up: sending that message, setting up the call, sharing the missing context–whatever it takes to move things forward. That's how we steadily work through challenges together for the greater good.