Coordination with External Teams – Why Regular Meetings Matter

Sometimes, when I review the posts I write, I wonder—why even bother documenting something so obvious? Surely everyone already knows this, right? But then real-world experience kicks in. Time and again, I come across situations where professionals, even experienced ones, fall into issues that were already covered in one of these posts. That’s when I realize the importance of capturing even the seemingly obvious practices.

The goal of this post isn’t to restate the basics but to help individuals reflect on their processes. If you're doing something better than what’s mentioned here, I would genuinely appreciate it if you shared it in the comments. These insights help all of us grow.

---

📌 The Reality of External Coordination

For any team—especially those working on product development—it is inevitable that you will need to work with external parties. These could be:

• Internal teams within your organization that depend on your deliverables or supply essential components.

• External vendors or partners—third-party developers, marketing agencies, manufacturers, etc.

Let me give you an example. Our marketing team once struck a deal with a phone manufacturer to preload our app on their devices. At first glance, this seemed straightforward—just give them the APK and you’re done. But the reality? Far more complex.

We had to integrate special tracking parameters to monitor usage statistics:

• How often the app was used if preloaded

• How it compared to installs from other sources

This required not just technical changes, but intense coordination. And it’s one of the many examples where assuming things will “just work” can lead to missed deadlines or poorly tracked deliverables.

---

🛠️ Challenges in Cross-Organization Coordination

When you're dealing with external teams, one big mistake is assuming their work culture and structure mirrors yours. This assumption can be costly.

You need to:

• Clarify deliverables

• Map roles and responsibilities

• Track timelines accurately

• Define escalation paths

Communication gaps, time zone issues, different management styles—these can all derail a project if not actively managed.

---

✅ Best Practices for Effective External Coordination

Here are some core practices to adopt when managing collaborations with teams outside your organization:

1. Define Clear Responsibilities

Start by identifying stakeholders on both sides:

• Who owns which part of the work?

• Who is the decision-maker?

• Who handles testing, approvals, or rollbacks?

Have a contact matrix or ownership chart. Ensure it's documented and shared.

2. Establish Clear Communication Channels

Create dedicated channels for formal communication:

• Email threads with clear subject lines

• Slack or Teams channels for informal queries

• Project management tools (like Jira or Trello) to track progress

Avoid mixing multiple discussions in a single thread—it leads to confusion.

3. Set Regular Meetings

Regular sync-ups are crucial. These meetings help:

• Resolve roadblocks early

• Ensure accountability

• Track action items and outcomes

Depending on the project phase, these could be:

• Weekly status meetings

• Daily standups (during integration or release phase)

• Ad hoc calls for urgent issues

4. Phase-Wise Role Adaptation

In the early stages, marketing, legal, and business development people might be heavily involved. As you transition into development, QA and release engineers take over. Ensure that:

• The right people are in meetings

• Transitions are smooth

5. Track Deliverables and Dependencies

Have a shared tracker (Excel, Notion, Jira, etc.) that both teams update. Include:

• Milestones

• Deadlines

• Blockers

• Review comments

Maintain visibility. Transparency prevents finger-pointing.

6. Issue Management and Escalations

Not all issues can be resolved at the same level. Define:

• What constitutes a blocker

• Who gets informed

• Expected resolution times

Escalation should be a process, not a panic button.

7. Define Acceptance Criteria Early

To avoid disputes, both parties must agree on what “done” means. Define:

• Functionality expectations

• Performance benchmarks

• Test coverage

• User acceptance testing (UAT) criteria

---

💡 Tailor Your Process, But Keep the Structure

While the steps above are generic, the application of each depends on:

• Team maturity

• Nature of the partnership

• Project complexity

A lightweight integration project with an external CMS vendor may not need a full-blown steering committee. But a core integration with a payments processor? That absolutely needs structured touchpoints.

Create templates for:

• Kickoff checklists

• Weekly status updates

• Risk registers

• Communication protocols

These documents become lifesavers during escalations.

---

🚫 What Happens When You Don’t Coordinate?

Let’s revisit the pre-installation app example. Suppose we had:

• Skipped UAT

• Failed to add tracking parameters

• Assumed marketing had done the heavy lifting

The result? A product on millions of devices with:

• No user insights

• No uninstall metrics

• No feature usage stats

In a data-driven world, this is a disaster. And entirely avoidable.

---

📝 Wrap-Up: Coordination Is Not Optional

Working with external teams—be they partners, clients, or vendors—is inevitable. How you manage that collaboration defines whether your project succeeds or drags into chaos.

So don’t assume. Don’t delay. Build coordination into the DNA of your process:

• Communicate clearly

• Document rigorously

• Meet regularly

When done well, coordination becomes invisible—just like the best-run projects.

---

📚 Amazon Books for Further Reading

• “The Phoenix Project” by Gene Kim – Affiliate link from Amazon

• “Team Topologies” by Matthew Skelton – Affiliate link from Amazon

• “Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland – Affiliate link from Amazon

---

🎥 YouTube Video on Cross-Team Coordination

Challenges of Working With an External Design Team

Lining up the support structure at the start of a cycle with firm commitments ..

During the course of a software project, you need the support of a number of people. For those who are not so well versed with the various challenges involved in project management, handling the support and resources from outside the core team are one of the biggest challenges during the early stages of the project, during the middle of the project, and during the later stages of the project; which only means that handling the various supporting teams is one of the biggest tasks during a project cycle.
So consider the starting time of a project. The features that are required for the project to succeed have been generated (including the trade off about the ones that are critical for the project vs. the ones that can be cut when there are schedule risks), and there is a need to ensure that there is a formal kick-off for the project. What do you do in a formal kick-off ? Well, one of the key items is to ensure that the team knows what the project is about, what are the key features that will be there in the project, and other such details. Typically the product manager will give a presentation to the team about the aim of the product, the market, the revenue earned by previous versions of the product and the target for the current version, and a high level description of the features that are sought to be included in the project. For many of these features, the further detail that the product manager can give is about how these features were derives, whether these be from competitor analysis or specific requests by customers, or generated based on ideas by the team.
However, as part of the initial kick-off, there are many other discussions that need to take place. For making the software development project successful, there is a lot of support that is needed from other teams. There are teams that prepare the build and the installer, there are teams that work on the documentation and help files, there are teams that deliver components that are required for specific functionality in the product, there are teams that work to translate the product in other languages. Most modern organizations have these kind of dependencies; it is no longer possible to have a situation where a single team does everything that is required for the team (for example, if you have a product that uses video formats, you would rather be using a common component that uses different video codecs to work with these formats rather than write code for working directly with these video formats (it may not even be possible to write code for all these video formats due to technical and commercial limitations)).
It is easier to ensure that you have the support of your core team and more difficult to ensure that all these supporting teams are providing the required support. For this purpose, before the kick-off, you would need to work with all these teams, providing them details about your requirements and the schedule in order to get a commitment from them (in some cases, where there is a clash due to priorities for support, you may need to escalate before you can get the desired commitment). In all cases, unless you can get the required level of support from these teams in terms of commitment, your project is already at a certain amount of risk that you will need to manage in one way or the other.

Working with external teams to ensure that they fit your requirements into their schedule

I work in an organization that is fairly large, being a $500 million organization, having a number of products being worked upon by different product teams. As a part of this process, there are also many common components that are made by a few central teams, which provide functionality common to most of the products. For example, when you consider that functionality such as reading and writing to optical media, being able to open and write to video files, etc are common functionality, it makes a lot of logical sense to ensure that these functionality are done by a common team and then other teams pick it up. It is not such a open and dried system though, there are elements of complexity in these systems though:
- The various product teams that pick up these common components or code have different schedules, while the common component teams follow a set schedule (in most cases, this schedule is set primarily by the most important product team - for example, if you take the case of Microsoft, the MS Office or the Windows team will have a much higher priority than somebody working on Skype, and the schedule for a common component will be more geared towards the schedule of Office rather than that of Skype)
- The features needed for each product could be different, even if these are tweaks. The common components may provide a core technology, but even in these, there could be significant differences. A product that is geared towards an expert in the field of video would demand support for a more comprehensive set of video formats, while a more entry level product would just want support for a few widely used video formats. The makers of the common component have to work towards balancing the needs for such different requests for requirements, using the priority of the products that are requesting such features as a variable in making decisions.

As a result, if you are not part of the most important team, you have to keep in mind that your requests, even though important to your team, and critical, may not make it to the final list of items that the component team is working on. We have been in that position, and it can be pretty painful, but you are reminded that it is a decision meant for the good of the organization. What can you do about such a situation ? Well, there are a number of items that you can do:
- When you know that such a prioritization problem can happen, you need to ensure that for requirements which require a modification in the common component, you start working a bit early on those requirements and have the relevant discussions with the component team early. The later you present your requirements to the external team, the more problematic will be the conflicts that the external team will have to factor in, and the higher the probability that your requirements will not make it.
- Strike up a discussion with the product team that drives the requirements of the component team and learn about what are some of the new features that they are looking for. Evaluate those to see which of those fit into your requirements, which will give you a higher chance of ensuring that your features do make it.
- Even if the requirements differ like the point made earlier about different products requiring different levels of video format support, getting into discussions early and having more discussions geared towards such kind of support can ensure that the component team is able to provide alternative functionality, such as the same component providing different levels of functionality depending on variables that are passed to the component.

Preparing external teams with feature requests well in advance

One of the most necessary processes in the project development or product development cycle is the handling of requirements. In typical literature, you will learn that the product manager or the product management team generate the requirements at the start of a cycle, and then these requirements are prioritized, discussed and estimated with the product team in order to get to a situation where it can figured out as to what are the set of features that will be there in the given release. Seems simple. However, there are complications in such a situation and planning, especially when it comes to getting work done by external teams which work on their own schedule and their own priorities.
One way of handling this was through providing the requirements to them earlier than the above process. We work with several external teams, such as the team that works on our installer and release process, and teams that provide us components (with the same components being provided to other teams as well). We typically would have a lot of work for our installer / release teams, and hence it was difficult for them to do a lot of new work during the operative parts of the cycle where feature work was doing (getting a stable build and release process, and ensuring that defects were fixed, that glitches in the process were repaired, that builds that were broken were repaired and the process modified to ensure that the builds did not break again for this reason); hence we had to take a new strategy for getting new work done.
What was this strategy. We took the list of features that were proposed for the next couple of releases, and did a sorting of features where there was some changes required from the installer / release teams or from the teams that prepared the installers. Once this done and we had a list, we would run the list again with the product manager and do a prioritization of the features. At the same time, we also had discussions with the external teams on the amount of work that they could do and what was feasible for them (for example, there could be resource constraints or the organization priority for a product could be higher than the priority of your product), and also generated some estimates from them. This was an iterative process, since if a high priority feature required a lot of work from the external teams that they were unwilling or unable to provide, we would have to jiggle the list around to either modify the feature so that it was still feasible, or drop it entirely (and this not easy - once we dropped a feature that was #3 on our top list, but it required support from an external team to a resource level that they were unwilling to commit and for which even escalation did not help). This took some weeks, but at the end of this, we had a list that we could provide to our external teams.
Now all this is not useful unless it is done early in the cycle, and that is what we did. We took the list of features generated from the process that is described above in the middle of the current cycle and talked to our external teams so that they could accommodate this in their cycle; and in most cases, the extra available time was just the buffer required to ensure that the work could be done by the external team and be available in time for when the next version of the product started and work was being done on those features in the core development team. Of course, in some cases, even this extra time will not work if the team is not getting the sufficient priority by the external team, and sometimes you just have to shrug and accept it (after you have done all the escalation and prioritization discussions).

Working with external teams for getting them to resolve their defects

When we do our planning for the next release of the software, we normally consider a number of risks, seeking to define a risk database that tabulates various known issues that could cause problems to the schedule and the smooth progress of the project. One lesser known risk that sometimes does not make it to the list of known risks relates to defects with people who are outside the core development team. For example, you may have a component that is being used in the product, and there is a defect against that component. Such defects have a higher risk than defects that are with the core team, even if the defect is of the same severity. There are many reasons for these defects having a higher risk. Some of these are:
- The outside team may not follow the same schedule or the priority as the product team.
- In fact, supporting the product team may be a lower priority for the component team, since they may have been given a task of providing support to other teams. This can happen a lot in organizations where there are a number of teams, and a strategic product will get much more support. For example, if the MS Access team and the MS Office team report defects in a component used by both teams, who do you think will get the priority support. In such cases, there will need to be more discussions, escalations, and other such measures before there is support granted.
- There is a much higher degree of coordination and communication needed when interaction with a developer who is outside the core development team
- The same defect may be treated as expected behavior by another team that is using the same component. You may be having a doubt about why a defect can be treated as a feature, but in some cases, a particular workflow behavior may be seen as a defect by one team, and desired behavior by another team. In such cases, the situation may be such that the defect may never be fixed.
- When the defect is with a component that is an open source component similar, there is no guarantee that such a defect may be fixed.

Given some of these reasons above, defects with developers who are outside the core development team are a much higher risk than most teams tend to visualize. We once had a hair raising case where the component we were integrating had a defect, but somehow the developer working on it was not able to replicate the defect. This was close to an important pre-release milestone, and we needed to get some fixing done on this defect, but this back and forth discussion and coordination at a remote location meant that it took around 2 weeks to get the defect fixed and a new component integrated, and this was a big problem for us.
What do you do when you have such dependencies on extended teams ? Well, you can never really get away from the defects, but atleast have processes setup to reduce the time period and coordination cost for these defects. What should you do ?
- Have an understanding with the remote team about the level of testing at their end. If necessary, send them test cases and ask them to provide completed test cases before they provide the component. This helps in reducing the chances of defects passing through their end.
- Setup a process where they can received updated copies of your software so that they can test with such latest software
- Ensure that the external team totally understands your defect management system and processes and they have been provided permissions for the software.
- Have a protocol with them about exchanging information with them about defects and if there are queries on these defects
- Have a regular meeting with them, this help in ensuring that any issues from either end are resolved quickly
- Ensure that any serious defects are communicated to them at a higher priority. This also includes defects that need to be fixed on priority.
- Define an escalation matrix with them, so that if there are cases where you are dis-satisfied or need quick action, what is the process to follow.

All of these will not mean that you will not have external dependencies on defects with external team members, but the problems associated with these defects will be reduced.

Application dependencies: Ensuring that third party plugins are upto date with the latest software version

Software development involves working with and resolving a lot of dependencies. I have been writing about the dependencies related to vendors (Article 1, Tools, Process sharing)  and those relating to the use of components (Article 1, Article 2). But this is not the only dependencies that happen in a software project. When you look at big software such as Photoshop or Microsoft Office, these software and other large software deliver a lot of functionality. However, there is always the effort by all such software companies to get a lot of experts and users to extend these software in terms of adding functionality through the use of software. If you take these software, there are actually a number of companies that provide third party components, some of them free and others that users can buy. If you consider a software such as Photoshop, there are a large number of components available that provide extended functionality, such as being able to do a better job of photo manipulation, additional effects for the software, and so on.
Having such components also adds a lot of benefit to the software, since this is ensuring that there is a eco-system that grows around the software, and with these components adding functionality to the software, there is a larger set of users who grow attracted to the software. But, with all these functionality, there is an additional amount of dependency and risk. Any software goes through changes during the product development of a new version, and many of these changes can impact the integration of these components with the product. For example, during the development of a software version, we made changes to the database in which product information was being stored, and this database change meant that a number of such services through which components linked to the database would no longer work, and even if they would work, there could be changes in the way they worked. Such a change is a big thing, since the component makers go through the same challenges as the makers of the software, and there is a lot of synchronization that needs to happen with relation to the component makers. What are some of the processes that need to be gone through for such a change:
- As and when there are changes that could impact a component, there needs to be a discussion with the maker of the component. Detecting such a change is possible for the software team, but it can be difficult. It is far easier to add the component maker to the beta program of the software component maker, and they can check the ongoing version of the software in the beta program with the component and evaluate for any change.
- At the same time, there needs to be a testing effort to ensure that the product team (if through automation, then makes it easier) is also periodically checking the components with the software and informing the component maker if there is any problem
- The product team also needs to have the latest version of all the components to test all of these on a periodic basis. They cannot just depend on the component maker for the same, since if there is a major problem, then there is an impact on the credibility of the product team (for example, in an extreme case, it would be a real problem if the product was crashing on the installation of a component)
- There should be a mailing list which has all the component makers on it, and where the team can send out important updates on any changes in the product that could impact the components

However, there needs to be some limit on the amount of changes that are made in the product in every version. When people buy a component along with a software, they have the expectation that the same component could work in multiple versions of the software, and having to purchase a new version of the component is not likely to win the software company a lot of friends.

Sharing of test data with vendors along with test cases ..

In several previous posts, I have been outlining some details with respect to interaction with vendors, for example - (Outlining focus areas of testing, Process for answering queries from vendors, Extracting relevant test cases); all of these outline some areas of interaction with the vendors. Working with vendors cannot be just one single area, there is a lot related to information regarding processes, tools to be used, focus areas to be decided, and so on. Yet another area of interaction between the vendors and the core testing team is the data to be used for the various areas of testing.
Having testing data is very important. You may have all the required test cases for doing a complete feature testing of the application, but without the test data, all this does not mean anything. For example, if you are testing a video application, then you need to be able to test for the different video formats that the application would support, and there are a large number of such video formats that are needed to be tested (unless you are in the video domain, you would not really believe the number of formats that exist because of the large number of companies that do something for video). For each such different type of video format, you would need to have the required data in this regard - multiple number of video files in each format (as another example, you could have a video file that is just a collection of images, another without audio, and yet another that has a combination of video and audio - there could be a defect that is only found if the video file does not have any audio - we once found a defect like this and it was a big pain to figure out what the problem was; after this, we had to add files with and without audio to our testing matrix).
And video files are large. The total size of the video test data that we used for complete testing was more than 50 GB in size, and it was guarded with great care. Because of the sheer size of the test data, we had decided not to put this test data in the source safe we used (because the data backup of the source safe meant that the guys running the source safe were not happy over backing up so much data that was binary rather than being coding text files) and hence had made multiple disk copies of the this test data, and there was some amount of effort required to ensure that there was a master copy of the data and all copies were synchronized to this copy.
Are you getting an idea of the problem we faced when we added a vendor testing team to this matrix. We had to tell them the focus area of testing, we had to prepare the extraction of the required test cases and make sure that these made sense for somebody wanting to do the testing who did not have the same amount of experience as the core team, and then we had to also pass on the large test data to the vendor while linking this test data to the test cases. Even though we had a fast connection to the vendor, there were some permission requests that also had to be processed since some of the test data that we had was from the vendors with no permissions to pass on, and hence every time we needed to pass them onto a vendor, we needed permission (no monetary problem, just the paperwork and time required), and since the test data was changing with new video cameras entering into the market, there were synchronization problems. And in an unusual case, we found that a particular set of high end video files required a very high end machine and this information was not captured properly. So when the vendor tries to use those files, things were not working.
The challenges may differ depending of the type of test data, but there is a need to ensure that there is a strategy to prepare for the passing on the required test data to the vendor.

Working with vendors: Setting up a process for queries and the back and forth for these queries

I had been working with a development team for a long time, and one of the most frustrating items for the team was about working with people external to the team. The team had been working on multiple versions of the product for a long time, and had a lot of experience on the product (many members of the team had been working on different parts of the product for more than 5 years) and hence had a level of knowledge in some areas that was superior to the product manager (who also had a lot of experience in the product as well). However, the team needs to work with a large number of people who are not so experience. This happens with a number of teams. Typically, teams work with people who do localization of the product, teams work with teams who do documentation of the product, in many cases, some amount of testing is also done by external team.
In such cases, the biggest problem is that the external teams will NOT have the same amount of experience with the product as the product team has, and in many cases, the external team person working on the product has very little or no experience with the product. In such cases, if there is some kind of fast learning program that enables the external team member to learn about the product, it is beneficial, but in some cases, such a help is not possible (primarily because it takes effort to produce such help, and the product may also be changing fast between versions in which this help may need to be updated fairly quickly).
But, consider that whatever be the level of help available, the external team member will take time to come upto some kind of acceptable level, and they will also have a lot of queries on this front. Some queries would be available if there is some kind of FAQ available for the product, but typically FAQ's cover the product as a whole, and may not be available when some external tester starts getting into a feature in detail. In such a case, you will have people who have queries and things will move faster if these queries are settled quickly.
And this is where the frustration comes in. Unless there is some kind of process available for such queries, the team member can feel that these queries come up on a regular basis or get repeated (in fact, when talking to team members, this feeling has been projected again and again and there are repeated request to ensure that these get resolved).
We have tried multiple measures to ensure some kind of process for trapping all these queries, especially with regard to ensuring that the queries are all categorized as per the different features (and this ensures that a database was built up with regard to queries that these external vendors have). First, we tries using a MS-Excel document for capturing these, but then we started running into concurrency problems about exchanging the document back and forth, and who maintains the master copy of the document. And, given that the team was very comfortable with the defect management software and the vendors would also have to start using this software, we laid down a process whereby all the queries were logged as defects against the specific feature where the query was (and with a keyword that identified it as a query from a vendor), these defects were assigned to the respective feature person, and then the query would be responded to from the respective person, and the vendors were also told to ensure that they went through these defects before they raised a query.

Ensuring a proper kick off and knowledge transfer to external teams that also work on the software ..

When you consider the software team, you would have a development team, a testing team, designers (including the user interface designer) and also the management team (and one could include the product managers or the product management team in the set of managers). When you consider these set of people, they have a lot of knowledge about the product and the features in the product, especially the people who are working on specific features. There are a few other people who have the same amount of knowledge on specific features. Given their level of knowledge, they take this level of knowledge as granted when they have a discussion with other people who are not on the team, and it can be difficult for them to realize that other teams do not have the same kind of knowledge that comes from working on the same product for a long period of time.

Any product team will need to work with other teams that provide services such as translating the software into other languages, do the documentation for the software and other related services that the product team will not do. The problem with this concept is that people working in these teams do not have the same kind of knowledge of the product that the product team has, and this can be a source of friction in their interactions. In some of these cases, the software team would do the right thing, find out the level of knowledge of these external teams and prepare time to ensure that these teams get a ramp up of the software program. But, even in these cases, it is a fair approximation that they will never reach the same amount of knowledge as the product team, and expecting such a level is what leads to frustration.

In my experience, the frustration comes when the product teams work with external teams that have little or no experience with the product (and this can happen often enough when dealing with external teams, since these teams typically cannot afford to have dedicated people for handling products, and their attrition rate may be different from that of the product team). So, the product team has some amount of knowledge transfer with the external teams, and assumes that there will be some questions that would come from the other teams. However, it may turn out that it takes time for these new people to understand the product, and the queries only come later in the timeline, and this is unexpected for the product team.

The way to handle this is to have a line of managers who understand that new people take time to understand the functionality of the product, and these people will never get the time that people in the product team have. So, there are 2 processes on how to handle this - prepare an effective training program that provides as much information as possible without over-doing it, and equally, learn from the teams that have gone through such an experience and learn what steps can ensure that the external teams learn faster, and what are some of the common problems and frustrations that can crop up in such a relationship.