Modular systems are essential in modern software and hardware. Modularity allows pieces of a system to be loosely joined together with other pieces. In modular systems each component can operate as it needs to as long as its interface to the other components is stable.

In comparison, Integrated systems are tightly coupled. A change in one part of the system can break something elsewhere in the system. While integrated systems can be very performant and reliable (everything is coded to work together) they are harder to update and iterate on.

Modular and integrated systems are all around us. The concept of modularity is the backbone of Clayton Christensen's "Law of Conservation of Attractive Profits". This post is not about that but you should go learn it.

According to Christensen, modularity has three conditions.

1. The module must have a specified interface

2. The interface needs to be measured

3. It must be a reliable dependency

The easiest way to think about this is an API. A good API has a defined input and output. It can be measured in terms of rate limits, speed, uptime etc. You can rely on it. It doesn't go down or worse, constantly change requiring you to rewrite your application.

While the concept of modularity and interdependence was created to explain how value moves in markets, its concept can be applied to any complex system, including human systems.

Modularity helps explain the dynamics (or dysfunction) of collaborating with teams inside a company.

Teams like to think about themselves as being modular. This is especially true in bottom's up cultures where teams are given a lot of autonomy to define their own roadmaps. They want to be modular because it allows them to remove dependencies which in turn allows them to move more quickly.

While most teams like to think of themselves as modular (or wish they were). They are not. This becomes clear when two teams try to collaborate.

1. Specified - You can not collaborate effectively with a team that has no defined interface. If you have no idea how to get things from them or give them things then no effective collaboration can exist.

2. Measurable - If you have a defined interface (agreed deliverables, cadence of meetings etc.) then you need some way to measure you are getting what you need.
   Let's say, as a Designer, you agree to meet with Engineers once a week to go over designs. The most basic measurement of that interface is if the meeting happened. Did people show up?
   More complex measurements might be if tasks generated from the meeting are closed inside some agreed upon time. Is measurable progress coming from these meetings?

3. Reliable - This is the most common break down in collaboration. One team, or both teams become unreliable. Even if both parties define on an interface and agree to measurements it is common for one team to get reorged or maybe reorder their priorities mid year. They very quickly become an unreliable dependency.

   The more teams trying to collaborate on a single product the more likely one or more becomes unreliable and the whole thing falls apart.

In a perfect world if these three conditions exist. Each team can work with independence. When trying to debug why collaboration is breaking down, it can usually be attributed to one or more of the conditions of modularity not being met.