Conway’s Law in Financial Services: The Silent Force Behind IT Complexity

In many financial institutions, architecture teams serve as central advisory units, overseeing multiple projects and defining architectural standards. These teams often include various specialists—enterprise, solution, integration, and security architects—each responsible for reviewing, amending, and validating proposed solutions. However, this layered oversight can lead to inefficiencies. Architects must stay continuously updated on project developments and are often only engaged during the design phase.

Yet, as deadlines and budget pressures mount, shortcuts are taken. The result is a significant gap between the intended architecture and the delivered solution. While resource constraints are partly to blame, a deeper cause lies in Conway’s Law.

In 1967, Melvin Conway observed:

"Organizations which design systems …​ are constrained to produce designs which are copies of the communication structures of these organizations."

In essence, the structure of a company—its teams, hierarchies, and communication flows—directly shapes the systems it builds. Siloed teams lead to siloed software. Inefficient communication results in disjointed integration.

This phenomenon is particularly visible in financial services:

• Corporate websites often reflect internal structures rather than user needs. Banking portals typically divide content into "Daily Banking," "Investments," and "Credits"—mirroring departments rather than customer journeys.
• Siloed IT architectures reflect rigid organizational boundaries, slowing down transformation efforts.
• Custom, point-to-point integrations are favored over hub-based models to minimize stakeholder involvement, despite long-term inefficiencies.

To address misalignment, many companies adopt microservices architectures, enabling small, autonomous teams to operate independently. While this can reduce dependencies, it comes with a caveat: as organizations evolve, microservices can drift out of sync with business needs.

Conversely, monolithic architectures—often criticized for tight coupling—can work well if paired with the right culture and processes that allow for rapid change.

As organizations grow, communication becomes exponentially more complex. A small engineering team operates very differently from one with hundreds of members. Startups often thrive with tight-knit teams but struggle as communication structures become more layered.

Anthropologist Robin Dunbar’s research shows we can maintain close relationships with about 5 intimate friends, 15 trusted ones, 35 close acquaintances, and up to 150 casual contacts before communication deteriorates. Jeff Bezos encapsulated this idea with the “two-pizza rule”: if a team can’t be fed with two pizzas, it’s too large.

To mitigate the impact of Conway’s Law, companies should:

• Define clear boundaries between teams and systems. Focus on interoperability with well-defined interfaces rather than forced integration.
• Empower teams with self-service tools, internal platforms, documentation, and automation to reduce interdependencies.
• Adopt iterative development approaches—build Minimum Viable Architectures (MVA) and evolve them.
• Streamline communication using tools like Slack, GitHub, and Wikis, ensuring clarity on roles and responsibilities.

Ultimately, you can’t change your software architecture without rethinking your organizational structure. If your development model isn’t aligned with your business objectives, your software won’t be either.

Designing your organization is just as crucial as designing your product. Companies that embrace this principle will be better equipped to adapt, innovate, and build systems that genuinely meet their needs—now and in the future.