The Coordination Tax in Your Software Estate

A shared change once took a quarter to reach every product in a large software estate because each team had to adopt and release it separately. Reuse was meant to lower the company's marginal cost of change, yet rebuilding was often faster and cheaper for each product team.

The technology payroll is visible. The coordination tax hides in backlogs, package upgrades, release calendars and the people employed to remember how everything fits together. Faster code generation leaves that queue intact.

For a large company building proprietary software, polyrepo is often the wrong default.

Polyrepo makes intuitive sense in open source, where independent companies choose whether and when to adopt a library. Separate repositories preserve that independence across company boundaries.

Inside one company, related proprietary systems serve the same commercial outcomes. Open source made independent software easy to combine; a company building proprietary software needs to make interdependent software easy to change.

Ronald Coase explained why companies exist: internal coordination can cost less than market exchange. Polyrepo recreates market-style transactions inside the company whenever one change crosses repository boundaries. Engineers must find the right owners, negotiate a route through several backlogs and repeat integration and validation for every consumer. A monorepo can make related software part of the company's cheaper internal coordination system.

At scale, repository boundaries often become organisational boundaries, acquiring separate owners, backlogs and delivery plans. The repository model then reinforces the communication structure Conway's Law predicts.

Source topology does not by itself change the organisation, architecture or delivery model. Where inherited structures create inertia, however, a monorepo is often the precursor that makes wider change practicable. It changes the default: related source becomes discoverable and changeable together, common standards can be applied once and cross-product work can begin without first negotiating through several delivery systems. Ownership, architecture and release authority can remain distributed. Shared source gives later improvements a productive path through the company.

Where the opportunity sits

In one large company's proprietary software estate, work touched around 3,000 separate repositories during 90 days. The same company has already demonstrated the alternative: one shared repository serving multiple products handled about 1,400 completed changes in its busiest recent month, more than seven times its 2023 peak as products were consolidated. The fragmented estate shows the opportunity; the shared repository shows that change is feasible at enterprise volume. I do not think the wider estate is unusual; its shape will be familiar to large companies built over time through acquisition, product expansion and successive generations of technology.

Consolidation creates four forms of business return:

Operating leverage. Common ownership records, dependencies, build configuration and controls can be maintained once and applied across products.

Time to value. Related work can cross products without entering a new discovery, negotiation, version and adoption queue each time.

Risk and control. Common controls and evidence reduce the reconstruction required during audits and incidents.

Strategic capacity. Familiar commands, conventions and dependencies allow engineers to follow demand across product lines.

The opportunity is distributed across platform budgets, backlogs, releases and incidents. Pricing it connects local engineering improvements to company-level customer and financial outcomes.

Repository count defines the surface on which coordination costs compound. As an illustrative annual model, allow an average 30 minutes of repository-specific ownership, dependency, build, policy and coordination work each week for 48 weeks of the year, leaving four weeks outside the model. Across 3,000 repositories, that equals 72,000 hours: roughly 40 engineer-years or £2.5 million at an illustrative blended loaded cost of £60,000.

The investment case must replace that assumption with measured work: sample representative changes, record how many repositories and teams they touch, and separate active effort from waiting time. Then establish the addressable share and the migration and running costs. State separately whether the return appears as cash, delivery capacity or lower risk.

Make reuse the shortest path

Reusable capability works only when adoption is easier than rebuilding. When every consumer must schedule, integrate, validate and release a package, duplication becomes locally rational and collectively expensive.

Pay once for the capability and make the shared route the fastest route. A shared codebase restores the economics intended by reuse: build once, change once and make the improvement available across products.

Technical separation remains available inside a shared repository; it does not require a separate delivery boundary.

Give AI a clear path to value

AI makes implementation cheaper. To turn that into company productivity, the route from idea to production must become cheaper too. When the constraint sits after coding, faster implementation delivers more work to the queue without reducing customer lead time.

DORA's 2025 research describes AI as an amplifier of the company adopting it. The dividend appears only when the cost and elapsed time of the whole change fall.

A monorepo gives engineers and AI the related source and dependency context needed to carry a wider change, while accountable owners retain review and production authority.

Google describes large-scale migrations in which related changes are generated and validated together, then routed to the owners of affected code for review.

Make controls reusable

A mandatory control should become part of delivery infrastructure, allowing the company to implement it once and apply it consistently. Across thousands of separate repositories, the same decision instead becomes an adoption campaign with repeated migrations, exceptions and follow-up.

Shared source and common tooling can integrate the mechanism once, update it centrally and evidence it consistently. That leverage requires investment: a credible monorepo needs company standards for building, testing and changing software, backed by clear ownership, fine-grained access, scalable build and test infrastructure, and developer tooling. The platform cost is explicit and central; the alternative distributes reconciliation across the estate.

Invest in fewer, stronger boundaries

A monorepo can remove a source-coordination boundary while products remain separately owned, controlled and deployed.

Team structures, release cadences and life cycles are not automatic reasons for separate source. Keep a repository boundary when the independence it protects is worth its recurring cost.

Untouched repositories can be among the riskiest in the estate. Their chance of receiving security updates is limited, while build paths and ownership decay. Inactive software still in use needs an explicit owner and maintenance path. Software no longer in use should be archived or deleted.

Repository boundaries are cheap to create and expensive to remove. They survive product convergence and reorganisations because no future initiative owns their removal.

Finance and technology should be able to answer three questions:

1. In a representative customer change, how much time is active work and how much is waiting at repository or team boundaries?
2. What annual cost and delay would consolidation remove, what would it cost, and would the benefit appear as cash, delivery capacity or lower risk?
3. Which boundaries buy necessary independence, and which merely encode historical organisational structure?

Companies exist because coordination within them can cost less than exchange between them. When shared work must negotiate its way across a repository boundary, the company gives back part of that advantage. Retain only the boundaries whose independence earns the recurring cost.