The Way Teams Talk Shapes the Software They Build

Communication Shapes Code, and the Shape of Code is a Business Decision

A CEO who walks past a row of meeting rooms and sees the same engineers in three of them in one morning is looking at the company’s product. The way teams talk shapes the way the software gets built. When the conversation is constant and unfocused, the product locks itself into interdependency, and the cost shows up in the margin before it shows up in the code review.

1. Conway’s Law and the Friction Signal

Conway’s Law states that organizations design systems that mirror their communication structures. Professor Clayton Christensen takes the same observation and turns it into a design tool. If the communication structure shapes the system, then the CTO designs the right system by designing the right communication structure first. That is the discipline the rest of this article is built on. In a product where components have no defined interface between them, coordination meetings are the primary signal of structural friction. These meetings indicate that the product components need a better interface definition between them. The objective is to stop forcing teams to coordinate across component boundaries.

The signal is meetings, specifically the kind where both teams have to be in the room to get anything done. These are the meetings where the same two teams keep showing up to ship small changes. A CEO who puts every engineer in every meeting without asking what the meetings are about is paying the coordination cost twice, once for the meeting itself and once for the architectural leak the meeting was supposed to show.

2. Owning a Module Is Running a Small Company

A tech team that owns a product component operates as a sovereign unit. The engineering manager of this team functions as both CEO and CTO of the module, the same way a real company executive runs a small business. This is the structural application of Christensen’s profit formula: treat the module as an independent profit center. The priorities that govern it stop competing with the rest of the system, and the team runs the module like the small company it effectively is.

Sovereignty is a cultural reality where the team manages its own contract with the rest of the tech department. The team can refactor, change performance characteristics, or rewrite the internal architecture freely, as long as it honors the interface it has committed to. Baldwin and Clark formalized the same logic in Design Rules (2000): stable interfaces enable decentralized innovation, and the team that owns the module becomes the innovator, as long as the interface holds.

3. Two Kinds of Internal Customers

Tech teams within a tech department interact with two distinct kinds of internal entities, and the distinction matters because each one demands something different from the team.

• Internal Stakeholders: Operations or business teams who demand specific product outcomes. They stay out of the technical handshakes between modules. Modular systems fail at change pressure when the pressure forces cross-module coordination, and stakeholders drive that pressure by creating the demand for change. They route that demand through the tech team that owns the affected module. The technical customer is the consumer team. The stakeholder plays a different role, which is defining the business outcome the module must deliver.
• Internal Consumers: Other tech teams whose code interacts with the module’s interface. They are the primary technical customers, and they are the ones the interface contract exists to serve. The consumer’s call patterns define what the interface has to expose, and the producing team does not get to redefine that on its own because interfaces exist to satisfy demand and changing them unilaterally would disrupt consumers instead.

Both failure modes expose the module’s internals through the same back door. The discipline is the same in both cases: honor the interface as a contract, and let the producing team own the internals while the consumers own the demand.

4. Splitting a Request Without Breaking the Architecture

The CTO is responsible for the tech department and runs projects rather than teams. While teams own the modules, the CTO organizes projects. When a request from a stakeholder affects multiple modules, the CTO splits the requirement into one isolated project per module. Each team then evolves its component independently, with no cross-team dependencies. Splitting the requirement well requires a deep working knowledge of the existing interfaces, because the interfaces are what define where one project ends and the next one begins. Without that knowledge, a “split” is just a guess, and the dependencies come back the moment the first team ships. Christensen’s framing applies here too, the CTO’s job is project architecture: recognizing the existing modular structure of the product and matching projects to it. The metric of success is whether each project can be completed by one team without involving the others, which is also the test of whether the architecture is doing its job in the first place.

5. Interfaces as Protection, Not Overhead

Interfaces are contracts that must be resilient and evolution-resistant. They act as a protective barrier for the team, in the same sense Christensen describes when he distinguishes between interdependence and modularity. As long as the interface contract is honored, the tech team has total sovereignty over the internal logic of the module. They can refactor, improve performance, or change the internal architecture without seeking outside permission, and the rest of the system stays unaware of the change. Interface design is a finite job, and it creates the conditions for a culture of ownership, because the team owns the module and the interface tells them what they owe to the rest of the system. That shift is cultural at its core, and it is what makes the rest of the architectural discipline sustainable.

That said, contracts do change, and a good practice is to discourage interface changes by making them expensive and rare, treating them as a major architectural event. Teams that change contracts casually lose the discipline fast, and the architecture erodes by the time the next roadmap arrives.

6. When the Tech Department Is Still Small

Small tech departments are a different game. A single team covers the whole product, where context-switching is a required skill and the cost of it compounds with the size of the product surface. Maintaining modular interfaces is the discipline that keeps that cost manageable while the team is still small enough to cover everything. A tech lead stepping from payments to onboarding in one morning moves faster when the modules have a clean interface between them. The cost of loading the second module is just reading the interface, and the cost compounds with the size of the product surface.

The first payoff is the speed the small department gets from being able to switch contexts cheaply, which matters more when the same engineers cover the whole product. The second payoff is structural: when the department grows and teams are added, the product’s modules already organize around independent ownership, and the new teams slot into the existing module boundaries without having to negotiate them from scratch.

Modularity applies to the product and the technology, and the business model and the business operations often do not benefit from the same discipline, especially in the early stage. The mistake to avoid is treating the small-department discipline as a license to modularize everything, including the parts of the business that are still figuring out what they are. The architecture becomes modular to serve sustained demand, and forcing modularity on the business model before the decoupling point is the overhead Prof. Christensen warns against.

References

1. Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(4), 28-31.
2. Baldwin, C. Y. & Clark, K. B. (2000). Design Rules, Volume 1: The Power of Modularity. MIT Press.
3. Christensen, C. M. & Raynor, M. E. (2003). The Innovator’s Solution: Creating and Sustaining Successful Growth. Harvard Business School Press. See also Christensen Institute - Business Model Theory for the profit formula and modularity frameworks.