One of my favourite short stories is “Story of Your Life” by Ted Chiang. In it, Chiang explores how language, both spoken and written, can fundamentally reshape how we perceive time, relationships, and even reality.
For example, languages such as English emphasize subjects and objects, which can lead to an emphasis on the doer or the agent, whereas Indian languages influenced by Sanskrit — such as Hindi or Malayalam — emphasize verbs or action, often dropping the subject or object.
Language, the fundamental building block of communication, has the power to shape mental models and philosophical concepts within their cultural contexts.
This got me thinking. If language can change how we think as individuals, does communication affect organizations, the systems they run, and the teams they build? Turns out, the impact is profound.
Conway’s Law
There’s an old law in software design known as Conway’s Law:
Any organization that designs a system will produce a design whose structure mirrors the organization’s communication structure.
If you’ve ever joined a new team and noticed how awkward product or system integrations feel, or how each team seems to “own” a siloed portion of a system, you’ve seen Conway’s Law in action.
When One Big Team Builds One Big Island
Not long ago, I worked with a large team responsible for multiple data functions — engineering, visualization, analytics, and modelling — all under one umbrella.
What worked:
- Fast initial development and delivery
- Clear internal structure and resource control
What didn’t:
- Rigid hierarchy and single points of failure that slowed cross-functional work
- Technology systems that couldn’t easily integrate with others
- Internal processes that mirrored the product’s lack of modularity
- Poor interoperability with the rest of the org, in code and collaboration
The team’s internal efficiency came at the cost of organizational agility. It wasn’t that they were doing it wrong — they were structured in a way that led to a predictable kind of product architecture: siloed and isolated.
How Cooling Systems Mirror Team Structure
Separate teams, separate cooling systems. If a car manufacturer has different teams for battery cooling, cabin climate control, and electronics cooling, the end result will likely be three distinct cooling subsystems — even if that’s inefficient.
Integrated teams, unified cooling. Contrast that with Tesla. Their ‘Super Bottle’ — a unified thermal management system — is the product of a smaller, more integrated engineering team working with a shared outcome in mind. This isn’t just clever engineering; it’s structural design enabled by communication and collaboration.
Outmanoeuvring Conway: Designing Teams for Outcomes
How do leading organizations intentionally design team structures that encourage integration and agility? Consider Amazon:
- The 2-pizza team rule — small, autonomous teams own a bounded area of the system end to end, from design to operations.
- Microservices that mirror team autonomy — loose coupling in the org leads to loose coupling in the software.
- Organizing around business outcomes — functional groups provide expertise, governance, and platform services; delivery runs through small, cross-functional, mission-oriented teams.
- Horizontal enablers for self-service — shared platform teams provide reusable tools, data access, and infrastructure. They aren’t bottlenecks; they make others faster.
Building a Bridge to the Island
To connect this “island” to the broader organization, I led the development of a cloud-based ETL platform that served as a data highway — not just technically, but organizationally.
I built a dedicated team focused on bridging systems and people: engineers who actively collaborated with data providers and reporting users. Together we established standards for data quality, usage patterns, and performance expectations long before integration happened. A once-isolated system became a reliable, integrated component of the larger ecosystem — thanks to a team structure designed with communication in mind.
Final Thoughts
I’m not advocating for co-location, centralization, or remote-first teams. There’s no silver bullet. But this much is clear: if we want our systems to be elegant, integrated, and adaptive, we must design our organizations and communication structures with the same care.
If you’re rethinking how your teams are organized, start by asking:
- What outcomes are we trying to accomplish?
- Are our communication flows aligned to these goals?
- Are our systems and product integrations struggling because our teams are misaligned?