There is a point in running multiple ventures where the portfolio stops feeling like a set of businesses and starts feeling like a set of fires. Each venture has its own cadence, its own open problems, its own stakeholder relationships, and its own claim on the operator's attention. At two ventures, this is manageable through discipline. At four, it requires a system. At eight, it requires architecture. At eighteen, it requires an operating system — a shared governance layer that applies the same structural discipline across the entire portfolio without requiring the operator to reinvent it for each new venture.
HavenWizards 88 Ventures OPC operates eighteen active ventures ranging from a 66-module agricultural SaaS serving Filipino cooperatives (Bayanihan Harvest) to a faith-based content platform with six-locale internationalization (Motivational Inspiration) to a basketball affiliate content venture. The domains are unrelated by design — diversification as a portfolio property, not a failure of focus. What they share is a common operating system: the same governance framework, the same phase-gate methodology, the same quality standards, the same financial reporting structure, the same build-and-deploy infrastructure. Every venture is different. The operating model is the same.
The phrase "operating model" does most of the work in that sentence, and it is the phrase that most often hides nothing. An operating model that cannot be decomposed into named layers and specific mechanisms is branding — a label applied after the fact to whatever the operator happens to do. The model below is decomposable. It has three layers, each layer has named components, and each component addresses a specific failure that a multi-venture portfolio produces when it runs without one. Building it was the work of years, not months. What follows is the architecture as it stands now, after the iterations that produced it.
The Three Failures That Fragmentation Produces
Before examining the operating model, it is worth being precise about what it is for. A shared operating model is expensive to build and expensive to maintain. It is only justified if it addresses failures that would otherwise impose a larger cost. There are three.
Decision fatigue at scale. Every venture generates decisions. Most of them are minor — should we deploy this feature now or wait for the next batch? Should we respond to this partnership inquiry? Is this expense within the current phase's budget? For an operator managing a single venture, these decisions are overhead. For an operator managing eight ventures, they are a constant drain that produces decision-quality degradation. The decisions themselves are not complex. The problem is volume without a filtering structure. An operating model reduces the decision burden not by eliminating decisions but by delegating them structurally — to documented rules, to established thresholds, to defined governance mechanisms that handle the routine without requiring the operator's judgment on each instance.
Inconsistent quality across the portfolio. Without a shared standard, each venture produces at the quality level its current state can sustain. A venture in early development produces at a different quality level than one that has been operating for two years. The inconsistency shows up in the outputs — different code quality, different content quality, different customer communication. For a portfolio that wants to compound its reputation across ventures, this inconsistency is a drag. Someone who encounters one venture in the portfolio and then a second one should have a predictable experience of quality, not a random one. Random quality is what tells a market that there is no system behind the brand.
Repeated problem-solving. Every venture encounters a set of common operational problems: how to structure a product launch, how to handle a customer escalation, how to evaluate whether a feature is worth building, how to sunset a component that isn't working. Without a shared operating model, each venture solves these from scratch — through the specific judgment of whoever is managing that venture, without reference to how the same problem was solved elsewhere in the portfolio. The portfolio's collective intelligence is not accessible because it is not structured to be accessed.
The operating model exists to address all three. It does not eliminate them; it reduces their cost to a level the portfolio can absorb. Each of the three layers below maps to one of these failures as its primary target, though in practice the layers reinforce each other.
Layer One: Shared Governance — the Policy Layer
Shared governance is the rules and standards that apply across every venture regardless of domain, stage, or revenue level. It does not govern the content of each venture's business. It governs the process by which each venture makes decisions, advances through development phases, produces artifacts, and is evaluated for continued investment. Its primary target is the decision-fatigue failure.
The governance framework is derived from the DIOSH methodology — a versioned lifecycle system that defines eight phases from discovery through launch, with specific phase gates at each transition. The phase-gate structure does three things. First, it prevents premature advancement: a venture cannot reach the development phase without completing the architecture phase, regardless of the operator's enthusiasm for the idea or the apparent market urgency. Second, it produces consistent documentation: every venture at the architecture phase has an architecture specification produced to the same standard, which is what makes the portfolio legible to anyone reviewing it. Third, it creates a shared vocabulary: when I describe a venture as being at Gate 3c, anyone working in the portfolio knows exactly what that means without a separate explanation. A shared vocabulary is not decoration — it is the difference between a status update that takes a sentence and one that takes a meeting.
Within shared governance, the most load-bearing mechanism is the decision-authority structure. It sorts decisions into three classes: those made by the individual managing a venture, those that require portfolio-level review, and those that require a DIOSH contract — the five-safeguard analysis applied to any decision with significant security, growth, platform, performance, or monetization implications. This sorting is the mechanism that handles decision fatigue directly. The operator's judgment is concentrated on portfolio-level and DIOSH-level decisions. Venture-level decisions are made within the documented framework by whoever is responsible for that venture, which means the volume that would otherwise reach the operator is filtered at the layer below them.
The property that makes shared governance work is that it is genuinely shared — not administered from the center but internalized by everyone working within the portfolio. Governance administered from the center creates a bottleneck at the center. Governance internalized by the portfolio makes every participant an enforcer rather than a recipient. Building that internalization takes longer than issuing a policy document, because it requires the governance to be visible in the work itself — in the artifacts it produces, the gates it enforces, the decisions it makes legible — rather than in a document that lives separately from the work. The most common way a governance layer fails is not that it is wrong but that it is filed: written once, referenced never, and quietly replaced by whatever people actually do.
Layer Two: Shared Services — the Operational Layer
Shared services are the operational components that every venture uses but that only need to exist once. Building them once and sharing them across the portfolio is what allows an eighteen-venture portfolio to be operated without an eighteen-person operations team. Its primary target is the repeated-problem-solving failure as it appears in build and operations.
The shared services in the current portfolio fall into four named groups. The technical infrastructure layer is the Turborepo monorepo structure, the deployment pipeline, the observability stack, and the authentication architecture — a single technology spine that new ventures inherit rather than rebuild. The content production pipeline is the governance framework, the niche-model library, the editorial quality gates, and the publishing infrastructure. The financial reporting structure is the standardized P&L format, expense categorization, and cash-position reporting. The knowledge management system is the MEMORY.md framework, the lessons-learned registry, and the runbook library. Each group is a service in the precise sense: it has an interface, it has owners, and it is consumed rather than recreated.
Each shared service follows the same design principle: it must be configurable by each venture for its specific context without requiring changes to the shared service itself. The content production pipeline handles ventures with entirely different editorial standards because the niche-model layer is per-venture, not shared. The technical infrastructure supports ventures with different needs because the deployment pipeline is template-based. The financial reporting structure accommodates ventures at different revenue scales because the P&L format uses percentage-of-revenue normalization rather than absolute numbers. The principle matters because the alternative — forking the shared service every time a venture needs something slightly different — is how shared services quietly become eighteen private services wearing the same name.
The most important shared service to build first is the one the operator is rebuilding most frequently across ventures. For me, that was technical infrastructure. Early in the portfolio's development, each new venture launch meant setting up the same CI/CD pipeline, the same observability tooling, the same authentication patterns. The time to build a shared infrastructure template was paid back within two ventures. The time to maintain it is marginal compared to the time saved on each subsequent launch — a new venture now starts with more working infrastructure on its first commit than most operations assemble in their first month, because it inherits from the portfolio rather than starting at zero.
Shared services degrade if they are not actively maintained. The documentation goes stale, the patterns drift from current best practices, the templates accumulate technical debt. Maintaining them requires designating explicit time — not as a periodic cleanup but as an ongoing operational commitment. In the portfolio, shared-service maintenance is a first-class task in the governance structure, not an afterthought. A shared service that is not maintained is not a shared service; it is a liability that every venture inherits at once. The failure mode is asymmetric: the cost of maintenance is paid steadily by the operator, while the cost of neglect is paid suddenly by every venture the day the unmaintained service breaks.
Layer Three: Shared Intelligence — the Learning Layer
Shared intelligence is the mechanism by which the portfolio learns. Every venture encounters situations that other ventures have encountered or will encounter. Without a mechanism for capturing and distributing that learning, each venture learns in isolation — the lessons from one venture's failure or success do not reduce the cost of similar decisions elsewhere. The portfolio's collective experience stays inaccessible because it is not structured. This layer's primary target is the inconsistent-quality failure, because most quality inconsistency is really a learning that was captured in one place and never reached the others.
The shared-intelligence system has three named components. The first is the lessons-learned registry: a structured record of generalizable insights from specific venture experiences. The format is deliberate. Each lesson specifies the situation that produced it, the action taken, the result, and the generalized principle that makes it applicable beyond the original situation. Lessons that are too specific — worked for Bayanihan Harvest, irrelevant elsewhere — are stored as venture-specific notes, not portfolio lessons. Lessons that generalize — an LLM-output validation pattern applicable to any venture using AI-assisted pipelines — enter the shared registry and are referenced in the governance documentation for every subsequent venture that touches the relevant domain. The discipline is in the sorting: a registry that admits everything generalizes nothing.
The second component is the failure-pattern library. It documents the failure modes that have produced the highest cost in the portfolio — not to assign blame, but to build the structural memory that lowers the probability of the same failure recurring. The patterns include the failure modes I have documented across nineteen years of enterprise programs, in addition to the venture-specific ones. The library is the portfolio's collective operational memory. It is the first resource consulted when a new venture hits a problem that seems familiar — a check against known patterns before diagnosing a novel one. Most problems that feel new are old problems wearing a new domain.
The third component is the cross-venture calibration mechanism: the practice of deliberately applying an insight from one venture to a different one. When Bayanihan Harvest's experience with offline-first architecture produced a pattern relevant to Motivational Inspiration's six-locale content-serving architecture, calibration is what moved that pattern from one venture's memory to a portfolio-wide standard. Without deliberate calibration, patterns stay where they originate. Calibration is a specific activity, not a natural diffusion process — left to itself, knowledge does not travel between ventures any more than it travels between strangers.
What Holds the Architecture Together
The three layers — shared governance, shared services, shared intelligence — are not self-sustaining. They require an operator who treats operating-model maintenance as first-class work, not as overhead that gives way to venture-specific priorities when time is scarce. The mechanism that sustains the architecture is the regular operating-model review: a structured review of each layer on a defined cadence — shared governance quarterly, shared services monthly, shared intelligence after each significant venture event. Each review asks whether the layer is still serving the portfolio's current state: whether the governance framework has kept pace with the portfolio's evolution, whether the shared services are being used as designed, whether the lessons-learned registry is current.
The review is also the mechanism for catching drift. Drift — the gradual divergence of practice from the documented operating model — is the most common failure mode in shared governance systems. It happens not through deliberate deviation but through expedient local adaptation: a venture manager does something slightly differently because the shared approach didn't quite fit, and the adaptation becomes the practice without the shared model being updated. Regular reviews surface drift before it accumulates into inconsistency that requires expensive remediation. Drift caught at one venture-month is a note; the same drift caught at eighteen is a project.
Where the Model Breaks Down
The shared operating model is not free, and it is not always correct. It imposes a fixed cost that a small portfolio cannot justify and creates a rigidity that, in specific contexts, is worse than the fragmentation it replaces.
The most expensive failure mode is premature standardization. Building shared governance for a single venture is pure overhead — there is nothing to share, and the framework slows the one venture down without compounding anywhere. The model only earns its cost when the same problem recurs across ventures. Build it too early and the operator pays the maintenance bill for an asset that no one is reusing yet.
The opposite failure is forced coherence. A shared operating model creates pressure to make every venture conform to the shared structure, and some ventures genuinely need to diverge. A venture in a regulated domain, a venture with a fundamentally different operational tempo, a venture acquired with its own working system — forcing these into the shared model can destroy what made them work. The tell is when a venture's results start to track its compliance with the shared model rather than its fit to its own market: that is the signal that coherence has stopped serving the portfolio and started taxing it. Shared governance is a default, not a mandate. The judgment of when to let a venture run its own playbook is exactly the kind of judgment the model cannot encode for you, which is why the operator's engagement on the framework's edges never fully ends. There is also a ceiling that the solo-operator model does not escape: shared infrastructure reduces the marginal cost of a venture, but it does not reduce the irreducible attention each venture demands at its decision points. The architecture raises the ceiling. It does not remove it.
What You Can Adopt This Week
You do not need eighteen ventures to use any of this. The model is sequential by design, and the first increments are cheap.
Build the operating-model infrastructure before the scale requires it, in this order. Build the shared governance framework when you have two ventures, not eight — when the framework's overhead is low and the habits of working within it can be established before the portfolio depends on them. Build a shared service the second time you catch yourself rebuilding the same component, not the fifth. Build shared intelligence the first time you observe the same problem recurring in two ventures within six months of each other. Each trigger is observable without a system; you only need to be honest about noticing it.
This week, do one thing: write down the decision class that currently consumes the most of your judgment across ventures, and sort it into the three authority tiers — venture-level, portfolio-level, DIOSH-level. That single act of sorting is the smallest complete instance of shared governance. It does not require the rest of the architecture to deliver value, and it is the increment most likely to reveal whether the rest is worth building.
The architecture of a multi-venture operating model is not complicated. It is the discipline to build it before you need it, maintain it when it would be easier not to, and treat it as a first-class product rather than a support function for the ventures that depend on it.
Continue in this series
This piece is part of The Indie Operator's Complete Guide to Running a Venture Portfolio, my systematic guide to venture building and modular architecture. Related reading:
- Portfolio Governance: Running Multiple Ventures Without Losing Coherence
- 18 Ventures, 1 Operating System: How Modular Architecture Scales a Solo Operator
- The Indie Operator's Complete Guide to Running a Venture Portfolio
- Managing Risk Across a Venture Portfolio
See how this plays out in practice across my portfolio of ventures.
