Every multi-venture portfolio eventually arrives at the same tempting idea: centralize the common functions, reduce duplication, and capture the economies of scale that supposedly justify running multiple ventures under one umbrella. On paper, the logic is clean. In practice, shared services are one of the most reliable ways to drain value from a portfolio while creating the illusion of efficiency.
I've designed the shared services structure for HavenWizards 88 Ventures OPC across ventures in technology (ShoreSuite, AHA E-Commerce), education (WonderScape), and agriculture (Bayanihan Harvest). What follows is what I've learned — mostly through watching shared services fail, and occasionally through designing them to succeed.
Why Shared Services Fail More Often Than They Succeed
The appeal of shared services is real: a single accounting team serving four ventures costs less than four separate accounting functions. A shared legal resource means each venture gets access to institutional knowledge without each venture paying individually for a full-time attorney. Centralized IT means you're not buying four separate software stacks for commodity functions.
The problem isn't the appeal. The problem is that shared services create structural conflicts that the organization is usually not designed to handle.
Misaligned incentives. A shared service exists to serve multiple clients — the ventures it supports. But its budget, headcount, and priorities are set by the portfolio — the entity that funds it. When venture A needs something urgently and shared services is consumed by venture B's quarterly close, who wins? Usually the venture with more organizational gravity, which often means the larger or older venture, not the one with the more urgent need. Over time, faster-growing ventures that need more from shared services lose confidence in a function that can't prioritize their needs.
Chargeback conflicts. How you allocate shared service costs to individual ventures is a governance problem with no clean solution. Allocate by headcount, and a venture with a small team that makes heavy use of the service pays less than it costs. Allocate by usage, and you need to measure usage, which creates overhead and incentivizes gaming. Allocate evenly, and small ventures subsidize large ones. Every chargeback model generates complaints and political friction that has nothing to do with whether the work is good.
One-size-fits-all solutions. Shared services trend toward standardization, because standardization is how they achieve efficiency. But each venture in a portfolio has different customers, different regulatory environments, different cash flow patterns, and different operational cadences. The hospitality venture (ShoreSuite) has seasonal cash flow and high transaction volume. The agricultural cooperative platform (Bayanihan Harvest) has irregular, harvest-cycle-driven cash flow and complex cooperative accounting. One accounts payable process does not serve both well.
Hidden coordination costs. Every interaction between a venture and a shared service requires handoffs, briefings, and reviews that don't exist when the function is housed within the venture. These costs are invisible in the shared services budget but very visible to venture operators who spend significant time managing the interface between their operation and a shared service that doesn't quite understand their context.
What Genuinely Centralizes Well
Not everything fails as shared services. There are categories where centralization consistently delivers real value without destroying venture autonomy.
Legal entity structure. The holding company architecture — parent entity that holds equity in subsidiary operating ventures — is a legitimate form of centralization. The holding entity manages equity, handles investor relationships, maintains corporate records, and provides a single interface for portfolio-level governance. This centralization is structural, not operational, and it doesn't require the holding entity to make day-to-day decisions for ventures.
Banking relationships. A portfolio-level banking relationship creates real leverage: better credit terms, lower wire fees, access to products that single ventures couldn't access, and a single KYC/AML process for the portfolio rather than separate processes for each entity. The key is that banking relationship management sits at the portfolio level, but each venture maintains operational control over its own accounts.
Compliance infrastructure. BIR registration, SEC reporting requirements, data privacy compliance — the frameworks for these are the same across ventures even when the specifics differ. A portfolio-level compliance function that maintains the frameworks, tracks regulatory changes, and provides audit support can serve multiple ventures effectively because the underlying work is standardized enough to genuinely centralize. This is different from operational finance, where the daily work is too venture-specific to centralize effectively.
Shared tooling licenses. A portfolio-wide subscription to a project management platform, a document suite, a design tool, or a communication platform — negotiated at portfolio volume and distributed to ventures — is genuine value. The license cost is lower, the procurement overhead is consolidated, and ventures get tools they might not have budgeted for independently. The critical discipline: shared licenses, not shared instances. Each venture should have its own workspace, its own data, and its own configuration — even on a shared platform.
Cross-venture knowledge management. Lessons learned in one venture that apply to others — a supplier reliability problem in agriculture that informs sourcing decisions in e-commerce, a customer onboarding failure in hospitality that applies to education — are genuine portfolio assets. A lightweight function that captures and circulates these lessons across ventures creates value that no individual venture could create for itself.
What Should Stay at the Venture Level
The failure of shared services is most consistent in the domains where ventures have the strongest need for autonomy, speed, and contextual judgment.
Customer relationships. No shared service can manage customer relationships across ventures. The customer relationship is specific to the venture's product, the venture's team, and the venture's culture. Centralizing customer success or account management creates a generic interface where a specific one is needed. The customers of ShoreSuite (hospitality operators) need completely different things from the customers of WonderScape (learners and educational institutions). Shared customer-facing teams produce generic service that satisfies no one well.
Product decisions. Product decisions — what to build, what to prioritize, how to respond to customer feedback, what to cut — are the most venture-specific work that exists. They require deep knowledge of the customer, the competitive environment, and the operational realities of building and shipping. No shared function can hold this knowledge across multiple distinct product lines. Centralizing product decisions creates bottlenecks, political interference, and products that reflect portfolio-level priorities rather than customer needs.
Marketing strategy. Marketing is inherently contextual: the right channel, message, and positioning for Bayanihan Harvest (a B2B platform for agricultural cooperatives) has nothing in common with the right approach for AHA E-Commerce (a retail platform). A shared marketing function that serves both either splits into de facto separate teams — defeating the purpose — or produces generic work that serves neither well. Marketing strategy and execution should sit close to the customer, which means inside the venture.
Operational staff. The people who do the daily work of each venture — the operations team, the customer-facing team, the delivery team — should belong to the venture, not to a portfolio function. When operational staff are shared, accountability for venture outcomes becomes diffuse. Who is responsible when a delivery fails? The venture operator who requested the work, or the shared operations team that executed it? This ambiguity produces exactly the accountability voids that operational problems hide in.
The Governance Design That Makes Portfolio Sharing Work
If you're running a portfolio and want to capture legitimate shared services value without destroying venture autonomy, the governance design matters more than the organizational chart.
Portfolio-venture interface protocols. Every shared service needs a defined interface with each venture: who requests work, what the turnaround SLA is, how disputes are escalated, and how costs are allocated. This interface should be designed before the shared service launches, not patched together after the first conflict.
Venture autonomy floors. Define explicitly what each venture controls without approval from the portfolio level. The list should be long: hiring decisions below a threshold, operational spending within budget, product decisions within approved strategy, customer relationship management, marketing execution. Ventures that have to ask permission for routine decisions quickly stop feeling like ventures and start feeling like departments — and they behave accordingly.
Sunset criteria. Every shared service should have explicit criteria for what would cause it to be dismantled, spun into a specific venture, or externalized to a third-party provider. This discipline prevents shared services from becoming organizational fixtures that persist past their useful life. If the shared accounting function isn't delivering cost savings that justify its coordination overhead, the sunset criteria should trigger a conversation about whether centralization was the right choice.
Direct accountability for venture outcomes. Portfolio-level functions — including shared services — should be evaluated on the performance of the ventures they serve, not on internal efficiency metrics. A shared IT function that is highly efficient but consistently blocks venture-level product decisions is failing, regardless of its SLA metrics. Accountability alignment between shared services and venture outcomes is the governance mechanism that prevents the misaligned incentives problem from becoming structural.
The Honest Accounting
The case for shared services usually rests on a cost comparison: centralized function vs. distributed functions across ventures. This comparison is typically done badly, because it counts the nominal cost of the shared function against the nominal cost of equivalent distributed functions — without counting the coordination overhead, the venture autonomy costs, the one-size-fits-all quality degradation, or the hidden costs of chargeback disputes and political friction.
Do the real accounting. Count everything. What does the shared function actually cost, including the time venture operators spend managing the interface? What does venture autonomy actually cost, in speed, in product quality, in customer relationship management? What would the venture-level capability cost if each venture built it independently? Are there third-party providers who could deliver the same function at lower cost and without the portfolio-level coordination overhead?
In my experience, this accounting often reveals that genuine shared services candidates are narrower than they appeared — legal entity structure, banking relationships, compliance frameworks, and tooling licenses are the consistent winners. Operational functions — finance, HR, marketing, IT operations, customer service — are almost never worth centralizing across distinct ventures, regardless of how clean the logic looks on a slide.
The shared services trap is not that centralization is always wrong. It's that the organizational reflex to centralize is much stronger than the evidence for centralization warrants. The discipline is to centralize selectively, audit the results honestly, and be willing to decentralize when the accounting shows that centralization is consuming more value than it creates.