Field Note
Portfolio standardization can create new debt
Technology standardization across a portfolio can absolutely pay off. Better buying power. Repeatable controls. Shared expertise. Faster diligence. Fewer products doing the same damn job.
It can also create a queue every company has to wait in and a series of migrations that cost more than the variation they remove.
The difference is whether the standard solves a recurring portfolio problem or makes the application inventory look nicer for the next meeting.
Start with the reason
A standard should have a reason.
Common identity and access controls may reduce security risk. Shared financial definitions may improve reporting. A standard integration pattern may make acquisitions easier to connect. Consolidated hosting or software contracts may create meaningful cost savings. A repeatable commerce foundation may accelerate brands with similar operating models.
Those are outcomes.
“Everyone should be on the same platform” is not an outcome. It is a proposed mechanism.
Define the portfolio benefit first, then decide how much uniformity it actually requires.
Product standards are expensive standards
Mandating one product creates licensing and skill concentration benefits. It also creates migration cost, change risk, and a dependency on the central team that governs the product.
The economics work best when portfolio companies have similar needs and would otherwise duplicate the same implementation.
They work less well when one company is global and another regional, one sells subscriptions and another projects, or one depends on a specialized operational model the standard product handles poorly.
Forcing those differences into a common platform creates customizations. Enough customizations and the portfolio has standardized on a product while preserving every local operating model inside it.
That is not always progress.
Standardize the boundary
Product uniformity is only one form of standardization.
A portfolio can standardize:
- identity and security requirements
- financial and operational data definitions
- API and event contracts
- observability and incident expectations
- vendor and architecture evaluation criteria
- backup, recovery, and continuity controls
- integration patterns for common transactions
These standards can reduce risk and make companies easier to connect without requiring every application underneath them to be identical.
This often creates more useful optionality. A company can change a platform while keeping the portfolio contract stable.
Shared services need customer discipline
A central platform or technology team serves portfolio companies with different priorities, timelines, and economic pressures.
If the shared service has no product model, it becomes a gate. Companies escalate to get attention, build local workarounds, or buy another tool because the standard path cannot meet the business need.
The shared team needs a defined service, transparent cost, roadmap, support model, and a process for justified exceptions.
It also needs to know when a capability should remain local. Central ownership is not automatically cheaper once coordination and delay are included.
Exceptions should be explicit
An exception process is not a loophole. It is part of a credible standard.
Require the company to explain the business need, risk, cost, integration boundary, and conditions under which the exception should be revisited. Record the decision so the next diligence or integration team does not have to rediscover it.
This prevents two bad outcomes: arbitrary local variation and central standards that survive only because teams hide the ways they do not comply.
Measure the total portfolio effect
Track more than license savings.
Include migration spend, business disruption, central-team cost, implementation time, exception volume, release speed, incident risk, vendor concentration, and the effect on future acquisition or separation.
A standard that saves software cost but delays revenue initiatives across several companies may be a poor allocation of capital. A standard that creates a reusable control plane for every acquisition may be valuable even without an immediate license reduction.
Uniformity is not the goal
The goal is a portfolio that can operate, change, integrate, and separate with less cost and risk.
Use standards where they create that result. Keep variation where it reflects a real business difference and the cost is understood.
Otherwise the portfolio spends several years eliminating old technical debt by creating a new kind: mandatory sameness with a migration program attached.
The spreadsheet gets cleaner. The companies get busier.