10 Practical Tips for Effective Cross-Team Collaboration

Actionable tips that you can apply to your multi-team projects.

Source: Unsplash

It is not easy to be part of a project requiring multiple teams to work together to complete. If mismanaged, it can cost you and your organization valuable manhours and resources.

Throughout my career as a senior software engineer and engineering manager, I’ve had the privilege to lead the development of medium- to large-scale software that needs coordination between multiple teams and stakeholders. The ups and downs that I’ve experienced along the way have taught me a lot about leading cross-team initiatives — and I took notes and journaled about what I’ve learned. I thought it would good to share the common themes and what we did to minimize the chances of project delays and failures.

The tips here are not limited to teams within the same company. They could also apply to working with third-party teams; for example, your team needs to work on API integration with a team from a software service provider.

You don’t need to follow all the tips here. Pick and choose what you will need depending on the nature of your project. By the way, in this article, the word “project” could refer to a new product feature, a third-party integration, or any large piece of work that multiple teams in a company need to complete within a specific timeframe. Let’s get started.

1. Conduct a Kick-Off Meeting

At the beginning of every project, gather everyone involved and officially “start” the project. I know what you’re probably shouting in your head right now: “Another meeting?!”

This is not just “another meeting.”

The kick-off meeting is a good time for everyone to introduce themselves, put faces to the names. This is important, especially when teams are working remotely. It helps break the ice for those who have never worked together before.

During the introduction, ask everyone to share a few interesting things about themselves — their hobbies, what they did over the weekend, what they had for dinner last night… This breaks the awkwardness by sharing how everyone is as a person.

This is also a chance for the product owner, lead(s), and stakeholder(s) to share about goals, objectives, roadmap, KPIs, the “why,” or anything else that will inspire the team.

It is an opportunity for everyone to provide their inputs: questions, suggestions, and concerns. These inputs will help you address possible issues that might arise, given the different experiences that the teams have had in the past.

The discussion should be kept high-level. If you need to dive deep into specific topics, take them offline.

2. Share API Keys and Login Details Upfront

We’ve all been in a situation where we are about to test a RESTful API, or we want to access a reporting dashboard only to find out that we don’t have access. Getting access upfront is crucial, primarily if the team could provide it for us from another location or time zone.

Not having the passwords or secret keys to access important information could delay a crucial decision. Ensuring that we get the necessary authentication details upfront will save us and our team valuable time.

Securely share your secrets and passwords by using tools like LastPass and Vault.

3. Share Up-to-Date Documentation

Remote working has taught us the importance of asynchronous communication, which brought up the importance of maintaining adequate documentation. Well-written, up-to-date documentation helps onboard new team members and collaborators. Good documentation should have the answers before we even think about asking them.

Asking questions should be encouraged. However, proper documentation could save our teams time by preventing them from going back and forth in a question-and-answer loop. An email could have been sent instead of a meeting. A few sentences or diagrams could save a manhour of answering questions.

Confluence, Google Docs, and Draw.io are useful tools for documentation. Of course, you should also keep your repository’s Readme.md updated.

4. Set Up a Sandbox Environment for Testing APIs

Aside from documentation, a sandbox environment where teams can safely poke around with the APIs is critical, especially in the cross-team project’s early stages.

Reading the documentation alone is not enough. The engineers will need to get a feel for how the APIs work and formulate how they will write their code or design their software around these APIs. Sandbox APIs are also handy for preparing prototypes and for local development environment testing.

5. Set Up a Dedicated Communication Channel

Create a public channel on Slack (or whatever messaging tool you’re using) that is dedicated to your cross-team project. The channel could be temporary depending on how long do you need to collaborate with another team on the same project. Make the channel public so that the information is visible to everyone in the organization. Doing so makes it easier for relevant people to find and join your channel.

Use this channel to share information like documents and important announcements and to ask questions and share ideas. It’s best to ask questions about the project in your shared channel and have someone answer it within that thread directly. This allows you to easily share the answer if someone else asks the same question. Avoid asking project-related questions in a private message. If someone happens to message you a project-related question privately, remind them to post the question to your shared channel. There could be another person in the channel who could answer that question, and that answer could be useful to the other team members in the channel.

6. Maintain an Engineering Design Document

The collaborating teams should have a shared plan on how the system’s different components work together and agree on that plan. Prepare a design document that contains the details of your project’s technical architecture or system design. Get the teams’ feedback, make some adjustments to the plan, and iterate on the document.

This document will become the blueprint for collaborating teams when building the project. Engineers should refer back to this document when writing the code and clarify any doubts around design decisions.

7. Create a Terminology or Glossary Document

Have you ever had those meetings where it felt like everyone is talking past each other? How about getting stuck in one topic because the terminologies used appear to be consistent, but you later found out that there were different interpretations? I was once a part of a project where we later found out that two teams had used the same name for each of their respective web services, which did different things.

To avoid situations like this, maintain a living document containing the terminologies, jargon, and acronyms with definitions that are relevant to your project’s context. So next time there are discussions, everyone knows what you mean when you use certain words. Naming things is already hard enough; let’s also clarify the meanings of those names upfront.

8. Maintain a Decision Log

You and your team will make micro and macro decisions throughout your project’s duration, from determining which coding standards to use to choosing the tech stack or making high-level architectural decisions.

Sometimes teams need to revisit those decisions to make better ones in the future. Or we might need to undo individual decisions and change course. Decision logs give us context as to why we made certain decisions in the first place, which could help shape our future decision-making. You can present these decision logs in a table or spreadsheet, in Confluence or Google Docs.

9. Agree on an API Contract

Cross-team projects introduce dependencies between teams. For example, Team A owns Client X, and Team B owns Web Service Y. To support the new feature that the project requires, Team A will need Team B’s help to build a new API endpoint within Web Service Y that Client X can consume. That means that Team A and Team B will need to agree on how the request and response should look like between Client X and Web Service Y.

Agree on the API contract first before building anything in the client or the web service. Once the API contract is agreed upon by both teams — and assuming that Web Service Y will return the response upon receiving the request specified on the API contract — Team A can start working on the Client X feature. Team A will mock the response while the new endpoint on Web Service Y is in progress. Use protocol buffers, a JSON spec, or a pseudo-code to document and share the API contract.

10. Set Up a Recurring Sync-Up Meeting

Sharing updates using Slack or Jira could work for status updates to indicate whether a task is “in-progress” or “done.” However, discussions like getting around blockers, negotiating scope, or agreeing to a quicker solution might need to be discussed in a meeting.

Use the sync-up meeting for concluding discussions or answering questions that are harder to settle via asynchronous communication. If there is no open issue that needs a meeting to resolve it, then skip it. The cadence of these sync-ups will depend on the teams’ preferences, dynamics, and situation. I’ve been on cross-team projects where sync-ups occur just once or twice a week. In other cases, when the project is slipping, they can be as frequent as every day.

Conclusion

Don’t limit yourself to following the tips above only. Modify these tips according to your needs. Come up with your own set of actions. Gather feedback, iterate on those sets of activities, and keep doing what works based on the results. It’s even better if the results are measurable and backed by data.

If you liked this article, please check out this one about agile teams: