🏢 🔍 🤖

BEYOND CONWAY'S LAW: USING AI TO REDESIGN HOW TEAMS AND SOFTWARE WORK TOGETHER

From understanding organizational silos to changing the boundaries that create them

SOFTWARE ARCHITECTURE · ORGANIZATIONAL DESIGN · ENTERPRISE AI

---

From seeing the mirror to changing the reflection

In my previous article, Your Software Architecture is a Mirror of your Organization , I explored how Conway's Law helps explain the relationship between organizational communication and software architecture.

Teams develop their own responsibilities, terminology and ways of working. Over time, those boundaries can become boundaries in the software itself.

Business rules become fragmented. Integrations become increasingly complex. Knowledge remains distributed across source code, database structures, support tickets and people's experience.

But understanding why this happens raises another question:

If our software reflects the way our organization works, how can we deliberately improve both?

This is where the conversation moves from diagnosis to action.

Conway's Law explains how organizational structures influence software. A Software Digital Twin can help make those effects visible.

The next step is turning that visibility into better decisions.

1. A small business change. A large coordination problem.

Consider a hypothetical enterprise software system.

A customer asks for a new discount rule: certain product categories should receive an additional discount when an order exceeds a specific value.

From a business perspective, the request sounds simple.

But implementing it requires several conversations.

• The application team must update the order-entry screen.
• The database team must review the stored procedure that validates the order.
• The web team must adapt the customer portal.
• The reporting team must verify how the new rule affects sales reports.
• The support team must explain an existing exception used by some customers.

Before anyone writes code, the organization must reconstruct how the rule currently works.

Which implementation is authoritative? Are the calculations equivalent? Why does one customer follow a different path?

The problem is no longer just implementing a discount.

The problem is coordinating knowledge and decisions across boundaries that do not match the business change.

Some cross-team coordination is necessary. A shared business process can legitimately involve several systems and specialists.

But when the same coordination problems appear with every small change, those boundaries deserve a closer look.

2. The Inverse Conway Maneuver: designing the organization intentionally

There is an approach commonly known as the Inverse Conway Maneuver.

The idea is to deliberately shape team responsibilities and communication patterns so they support the software architecture you want to build.

Instead of allowing existing organizational boundaries to determine the architecture by default, you make organizational design part of the architectural conversation.

For example, if you want a coherent order-management capability, you need clear responsibility for how that capability behaves across application logic, data and integrations.

That does not necessarily mean putting everyone into one large team. It means making ownership, decision-making and collaboration explicit.

INTENTIONAL ALIGNMENT

BUSINESS CAPABILITY
What the organization needs to deliver

↓

TEAM RESPONSIBILITIES
Who owns behavior, decisions and outcomes

↓

SOFTWARE BOUNDARIES
Modules, services, data and interfaces

However, changing an organization chart is not enough.

A renamed team still faces the same constraints if every change requires external approval, nobody owns the business rule and the underlying dependencies remain hidden.

New boundaries must be supported by clear responsibilities, appropriate skills and workable technical interfaces.

3. Before redesigning boundaries, make the real system visible

Here is the practical difficulty.

How can you design better boundaries if you do not understand the current ones?

Architecture diagrams usually show applications, databases and integrations. Organization charts show departments and reporting lines.

Neither necessarily shows how a business change actually moves through the company.

A module may have a formal owner, while another team makes most of its changes. A stored procedure may implement a critical rule that almost nobody recognizes. A support ticket may contain the only explanation for an unusual behavior.

This is where the Software Digital Twin becomes particularly useful.

Its knowledge model can connect technical artifacts with business context and responsibilities.

A CONNECTED VIEW OF SOFTWARE AND RESPONSIBILITY

BUSINESS PROCESS
Order entry · Pricing · Confirmation

↕

TECHNICAL IMPLEMENTATION
Source code · SQL procedures · Tables · APIs

↕

OPERATIONAL KNOWLEDGE
Support tickets · Incidents · Historical changes

↕

RESPONSIBILITIES
Owning teams · Decision-makers · Contributors

This creates a richer set of questions:

• Which business changes repeatedly require several teams?
• Which rules are implemented in multiple places?
• Which critical components have unclear ownership?
• Which interfaces cause recurring incidents?
• Where does understanding depend on one person's undocumented knowledge?

Dependencies, change history and incident patterns provide evidence to investigate. They do not automatically explain why a boundary exists or whether it should change.

The model makes the relationships visible. The teams help interpret them.

4. One discount rule. Four different versions of the truth.

Let us return to the discount example.

Imagine that the investigation reveals the following situation:

• A Delphi application calculates the discount displayed during order entry.
• A SQL Server stored procedure recalculates it when the order is confirmed.
• The customer portal contains a separate implementation.
• A support ticket describes a customer-specific exception introduced years earlier.

Each implementation has a history.

The application calculation may have been designed for immediate feedback. The database calculation may protect transaction consistency. The portal may have been developed later by a different team.

The exception may still be a valid contractual requirement.

Simply finding similar code does not tell you which behavior is correct.

An AI-assisted knowledge system could help retrieve the relevant implementations, compare their conditions and connect them to documentation and historical incidents.

Where is this discount rule implemented, how do the implementations differ, and what evidence explains those differences?

A useful answer should point back to its sources: code locations, database objects, tickets and relevant versions.

It should also make gaps visible. Perhaps the original decision was never documented. Perhaps the portal behavior has changed since the last analysis.

With that context, the teams can decide whether to centralize the rule, introduce a shared contract or preserve distinct behaviors with explicit documentation and validation.

They can also establish who owns future changes to the rule.

The architectural improvement comes from a better-informed decision, supported by connected knowledge.

5. AI can reveal friction. People must change how work happens.

It is tempting to imagine an AI system that analyzes the codebase and produces the perfect team structure.

But organizational design involves more than technical dependencies.

Skills, customer commitments, operational responsibilities and business priorities all matter.

A component with many dependencies may represent a healthy shared platform. Two teams that frequently collaborate may be working effectively on a genuinely cross-cutting concern.

The important question is whether the collaboration supports delivery or creates recurring friction.

AI can help surface patterns and reconstruct context. Leaders and teams must decide what those patterns mean and what changes are practical.

Sometimes the right action is to clarify ownership.

Sometimes it is to improve an API contract, document an exception or remove duplicated logic.

Sometimes it is to change team responsibilities.

The goal is to align software boundaries and organizational responsibilities with the work the business actually needs to perform.

6. Start with one process. Measure the difference.

You do not need a complete model of the entire enterprise before learning something useful.

Start with one business process that creates recurring difficulties.

Order confirmation. Invoice generation. Inventory availability. Customer pricing.

Choose a process where delays, incidents or repeated coordination problems are already visible.

1. Map the relevant knowledge.
   Connect code, database objects, interfaces, documentation and support history.
2. Validate the relationships.
   Review the model with the people who develop, maintain and support the process.
3. Identify one recurring point of friction.
   Look for an unclear responsibility, duplicated rule or dependency that repeatedly delays changes.
4. Make a targeted improvement.
   Clarify ownership, improve a contract or change a technical boundary.
5. Compare the outcome with the starting point.
   Check whether similar work becomes easier to understand, implement and support.

Useful measures include:

• Time required to analyze the impact of a change.
• Number of handoffs between teams.
• Time spent waiting for decisions or missing information.
• Regressions associated with changes to the process.
• Time required to investigate and resolve related incidents.

Compare changes of similar scope and consider other factors that may affect the results.

The value of the initiative is not the size of the knowledge graph or the number of questions answered by an AI assistant.

It is the organization's improved ability to make changes with confidence.

A question for CEOs and CTOs

When a relatively small business change requires a large coordination effort, what is causing that effort?

Is it unavoidable business complexity?

Or is it complexity accumulated through years of fragmented responsibilities, duplicated rules and missing knowledge?

Before approving another major modernization program, examine how one important change actually travels through your software and your organization.

You may discover that a clearer responsibility or a better-defined interface removes more friction than another technology migration.

Final thought

Conway's Law helps us understand why software takes the shape it does.

The Inverse Conway Maneuver encourages us to shape organizational responsibilities intentionally.

A Software Digital Twin can provide connected evidence to support that work: how the system is implemented, where knowledge is fragmented and which boundaries repeatedly complicate change.

Together, these ideas suggest a practical cycle:

Understand the system.
Understand the responsibilities behind it.
Improve their alignment.
Measure what changes.

Your software reflects your organization's history.

With better visibility and deliberate decisions, you can start shaping what it reflects next.

---

ABOUT THE AUTHOR
Software development, SQL Server performance, enterprise architecture and Artificial Intelligence.

#ConwaysLaw #InverseConwayManeuver #SoftwareArchitecture #EnterpriseSoftware #ArtificialIntelligence #SoftwareDigitalTwin #KnowledgeGraphs #GraphRAG #OrganizationalDesign #EnterpriseAI #CTO #TechnologyLeadership