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

Logistics - Deciding a common location for all document sharing

Some of these posts can seem very logical and obvious, but in reality, many of these items have come up based on experience learned from various projects, shortcomings and feedback provided by the teams with whom I have been working. And they can be very important, even though they may not seem much.
When you have a number of different teams working on the same set of tasks, there are a number of documents, instructions, examples, demos, and other artifacts that need to be shared between these different teams, shared real time and with the required access available to all these different teams and their team members.
And it was one such case that caused a delay of around a week in the actual schedule of one such task that was being coordinated between different teams. A delay of any kind has a ripple effect on the entire schedule, and when schedules are less than a year, a delay of a week in any such related task can cause significant problems to the schedule and lead to some fire-fighting in the team management. In this current case, we eventually ran into an issue where a rights / security caused a blockage, and the person tasked to ensure the coordination did not even know about this security problem.
During the course of a project, the project / program manager cannot take on each and every area, and in one particular case, the coordination between a team located in the main geography, another team located in a different geography and a vendor team located in another geography. The vendor team was new to the product and had to be brought up to speed on the processes and technical knowledge of the product. In the light of some of this coordination effort, a team lead with experience of some of the relevant functional area of the product was put in charge of the coordination effort, reporting every week to the overall manager of the product about the status.
The lead started out well, using previous experiences to set out some of the required documentation. However, when an outsider vendor is needed for the product work, they need to be granted permission for the documentation area, And this permission cannot be granted by the team, but by a central IT unit which is responsible for all server access.
The problem turned out in this case was that part of the documentation was placed in a server that was off-limits to any outside vendor (there were some specific security protocols for some of the more important servers, especially those where code is resident on the server); but this information was not known to the project lead responsible for the coordination. The project manager knew this information, but the multiple tasks being done by the manager and the leads ensured that a proper discussion did not happen for the next 4-5 days, at the end of which a meeting resulted in the lead learning this security information, It took another 2 days to make changes to the documentation location, and then get the required permission. This entire stand-off did need to some changes being made on some parts of the schedule, not something that the project manager welcomes.
What the learning from this was that we did not do the required leg-work before starting this part of the phase, especially about a common location for sharing of documents and the permissions for these.

Working with different UI elements for translation ..

When you look to make your product available in many languages, or when you are looking to extent the availability to a new language, there is the need to do an effort estimation. After all, there is a cost involved with ensuring that your product is available in a new language; with these costs being:
- Cost of manipulating your code to ensure that it can support the new language (for example, if you want to have your product available in Arabic, you need to ensure that your product support the right-to-left style that is supported by Arabic, rather than the convention left-to-right that is supported by English and most other languages). There are other areas in the code which may need to be manipulated before the product can be available in the new language.
- Cost of translation of the application. This involves translation of all the UI elements in the application (and in the second half of this post, I will provide more details of what this means).
- Cost of doing an initial testing of the application in the new language to ensure that you have identified places where the translation needs to be done (this is different from the more detailed testing that needs to be done once all the translated elements are put into the application)
- Functional and linguistic testing that needs to be done to ensure that the application works properly in the new language. You would wonder as to why the translated application needs to have functionality testing, after all, there is no change in functionality. However, there is a lot that can go wrong from a functional perspective during the translation process. Once we had a case where the parameter for the new language was being passed incorrectly, which meant that the application was not working in a specific area, and this was caught during the functional testing and quickly corrected.
- If the application uses external components, then it is needed to be ensured that all these external teams either already support the new language, or provide the required support in your scheduled time.

Once you have worked out all these effort estimates, you need to get onto the actual effort involved with translation, and this can be tricky. There are different UI elements that need translation, with different levels of effort required for these translations. For example:
- There are simple UI text elements. These need to be sent off to the translating team and received back. There is very little complexity in such elements.
- There are images that need translation. If the images have either a snapshot of a section of the application or something in text inside the image, then there is a problem. You need to get snapshots of the application with the new language, and that takes time and effort, but is not complex. However, if you have text within an image (supposed this is showing an image of a template), then you need to get the original image (typically a Photoshop format, a PSD) and then translate the text, and re-insert the new image. This is more complex, and if the application has been in existence for some time, the original image may even have been misplaced.
- If you have videos within the application, that either show instructions or show the application interface, then it gets more complicated. You may need to re-shoot the videos, and that can quickly turn out expensive. Similarly, if you use Flash Video within your application, you will need to generate them again.
- And then there is the complexity associated with languages where the length of the text in certain languages is more than that of the original language. So, when you consider conversions into say German or Japanese, the converted text would be longer than the original text and may not fit properly in the application. In such cases, either the translation has to be tweaked and made shorter, or the application needs to be tweaked to accept the longer text. In both cases, there is a lot of coordination and process.

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.

Learning - Setup groups within the company and share experiences - Part 1

The first question is about why such a topic would belong in a blog about software processes ? Seems a bit strange to have a blog about experience sharing, since it seems to something that is not specific to the software area. However, I have found that the busy nature of the software professional leads to a scarcity of time, leaving little time for reviewing ones own experience, what to talk about trying to do experience sharing with people from other teams. This being busy nature has only increased due to the economic problems of the last few years, with the same number of people expected to do more.
So what is this post about ? In any decent sized organization, whether it be a product development organization or an organization that works on projects, a number of teams do similar kind of work and hence are in a position to learn a lot from each other. Even though their products or projects may be somewhat different from each other, the level of difference with each other would not be significant enough. As a result, if there was coordination (or rather, let us not use the term of coordination, rather let us talk about how they can share their experiences), then the teams and their managers can learn a lot about how each team handled some situations which are common.
This is best served through an example. We had a situation where we were running into problems with an external vendor (not even a vendor, more like a open source component maker who would post new versions of their component with updates and notes on a regular basis, every 6 months or so). We did not have any clarity as to what were the contact details of the key people in the component maker, we did not know details about the kind of testing processes that they had, and so on. This was causing us problems, since the component was important to us (it saved us a lot of money that would otherwise be needed to buy a professional software that did the same function).
At that time, we recollected that another team in the company was doing something similar in terms of functionality. We did a quick engineering discussion with them, and realized that they were far ahead of us in terms of figuring out these kind of details that we were looking for. They had knowledge of the key people in that open source project, and they had discussions which provided them far more comfort in terms of the testing processes and the level of quality in the released version of that component.
Because of this particular discovery, we had a senior engineering person within our group interact with a similar person from their team on a regular basis for these kind of discussions. We also created an email group with the specific name of that component, and made it open for other people within the company to join. The resultant was that over a period of time, we discovered 2 smaller project teams within the company that were also looking to evaluate such a component, and they got a head start based on the discussions that they had with us and with the other teams.
Now, if you do such discussions, not only for such an example, but for other cases where you are running into problems, such as problems with the latest seeds of MS Windows or OS from Apple, or where you are running into other problems, such groups can provide a lot of help, since it allows people to share issues and share solutions. However, it takes time and effort to do this kind of sharing and coordination, even though the rewards that you get from such sharing can be well worth it.

I will add more about this in the next post in the series (Sharing experiences within the company - Part 2 - TBD)

What is a CBSE process? What are the steps in CBSE?

The component based software engineering or CBSE process is nowadays gaining a new high in the field of software engineering. But still many of us are not aware of this development process. 

This article focuses up on the component based software engineering process as well as the steps involved in it. More commonly the component based software engineering process is known as “CBD” or component based development. 

About Component Based Software Engineering (CBSE) Process

- The CBSE process is treated as an individual branch of the software engineering that primarily emphasis up on the separation of concerns with respect to the wide ranging functionality that are present throughout a software system or application.

- This approach to software development can be thought of as a reuse based approach and is used for defining, implementing and composing the independent components that are loosely coupled in to the given software system or application. 

- With such a practice, an equally wide ranging degree of benefits is brought about in the software system both for the short term and the long term and also for the organizations that are involved with the production of that software system or application. 

- The components of the software system are considered to be a part of the platform where the development process begins by many of the software engineers. 

- The components are often converted in to services and are granted further characteristics that make it different from an ordinary component. 

- For example, this happens in SOA or service oriented architectures. 

- In other cases, the components are used to consume or produce events that cab be later used for EDA or events driven architecture. 

- An individual software component can be considered to be one of the following things:

1. Software package
2. Web service
3. Module encapsulating a set of related functions.

Principle behind CBSE Process

- All the processes of the software system or application are placed in to separate components so that the data remains safe and intact and separated from other dissimilar kinds of data. 

- There is a semantic relation between the data and the functions placed inside the components.

- It is this principle that grants the components the property of modular cohesiveness. 

- The co- ordination among components is facilitated via the interfaces of the components or modules.

- Whenever it is the turn of a software system or component to offer a service to the whole of the other system or application, it makes use of the provided interface specifying the service that can be utilized by the other components and how it is to be utilized is also instructed by that interface only. 

- This interface can be called as the signature of that particular component to which it belongs.

- One of the best things about the CBSE process is that the client need not have the knowledge about the inner working of the components in order to make use of it.

Steps involved in CBSE process

1. The first step is all about the creation of an interface specification using an IDL (interface definition language).

2. The second step deals with the creation of a component specification which consists of member functions and interfaces.

3. At this step the complete control of the development process is in the hands of the developers and the traceability metrics are based up on the CBSE principles.

4. Unit testing of the components using a test harness for making the entire process automated.

5. Component integration testing

With the CBSE process, the developers can make changes to a specific component easily as long as they adhere to their interfaces. 

What are different software development problems and what are its solutions?

Today‘s world is growing up in the age of software. The whole world revolves around the computers and the computing is all possible because of effective softwares. The quality of the software systems and applications that we use depends largely up on the quality and efficiency of the software development process.

For producing the quality and efficient softwares, a sound software development process is required. But, today as the technology is advancing, so are the problems associated with it.

In this article we are going to throw some light on the problems that come in the way of software development and also we shall seek some solutions for them.

DIFFERENT SOFTWARE DEVELOPMENT PROBLEMS

- There is a lack of skill in the IT sector and the available expertise is focused more up on the core competencies which include outsource functions that are distasteful and complex though still being important.

- The local software development relates to the global software development.

- A good cooperation is needed among the intra- organizational companies.

- There is a great need of effective outsourcing which includes the availability of global data centres, IT infrastructure and embedded softwares, software applications and maintenance applications.

- Apart from all these there is a big requirement for better application service providers or ASPs.

There are several other problems associated with the software development:

1. Communication Problems
- In today’s world the development of software is not concentrated over a region or area, engineers and experts from all over the world contribute in this.
- Formal communication is needed during the routine, inspections and for formal specifications whereas informal communication is required to describe the informally captured requirements.
- Problems like following occur:
(a) Distinct backgrounds
(b) Time zone difference
(c) Lack of information communication
(d) Distinct backgrounds
(e) Distance

2. Strategic Problems
A lot of problems are faced while designing a strategy for the software development like:
(a) When to start development?
(b) Which task is to be allotted to whom?
(c) How to manage risk at both organizational level and project level.

3. Complexity in Coordination
The members of the software development team often find it difficult to cooperate with each other.

4. Issues related to Diverse Cultures
- Team members are from different cultural backgrounds and this has an affect on their performance, individualism, and attitude towards the work.

- Emotions and attitude towards race, religion and class etc add to these problems.

- The team members should be smart enough to understand each other’s culture and learn to compromise and respect the cultures of each other.

- Some of the measures to overcome cultural issues include reducing the intense collaboration among the team members, reducing the cultural distance by cultural liaison and personnel exchange etc.

5. Physical or Geographical Dispersion
Geographical dispersion of the team members as well as resources which results in an uneven distribution of the vendor support, access to expertise and cause a hindrance in the use of software development practices which need a face to face interaction.

6. Technical Problems
Sharing of the artifact as well as information about the development plan and software becomes quite a difficult job.

7. Management of Knowledge
This is a consequence of lack of communication or poor communication among the team members, lack of proper documentation, repositories and so on.

8. Availability of Open Source Software
- Open source softwares that facilitate the exchange of information and artifact among the developers and provide means for the modification of the code should be made available to all involved in the development process.

- Such open source softwares help in unifying the distributed development process.