The advice I most often hear about running multiple ventures simultaneously focuses on the optimization side: build shared infrastructure, govern with frameworks, delegate aggressively, protect your calendar. This is all correct. I have done all of it. And it still does not prepare you for the specific things that break when you attempt it at scale.
I currently run six active ventures: Bayanihan Harvest, a 66-module platform for agricultural cooperative operations; HavenWizards, a property management platform; WonderScape Education, an ed-tech venture; ShoreSuite, focused on hospitality management; AHA E-Commerce; and 143 Basketball Haven. I teach in the graduate program at PCU Manila. Each of these is at a different stage of maturity, runs on a different business model, and requires a qualitatively different type of thinking to run well.
What follows is not an argument for running six ventures simultaneously, and not an argument against it. It is an account of what actually breaks — specifically, concretely, from direct experience — and what addressed each failure mode, including the failure modes that did not have clean structural solutions.
Attention Debt
The first thing that breaks is not your capacity to do the work. It is your capacity to notice what is not working.
Attention debt is the gap between the things that required your notice and the things you actually noticed. It accumulates invisibly because the thing you missed was, at the moment you missed it, competing with something else that seemed more important. When you are running six ventures, something always seems more important.
In HavenWizards, the specific incident that made this concrete: a recurring friction point in the property onboarding flow had been generating support contacts for six weeks before I saw it. The contacts were in the system. The category was tagged. The volume was not high enough to surface as an anomaly in the metrics I was monitoring. Someone on the team had flagged it in a message thread that I had marked as read without processing. The platform was not broken — the onboarding flow worked. But six weeks of users encountering friction that a three-hour design intervention would have resolved represents a compounding cost: users who had a worse first experience than they should have, some of whom did not come back.
Attention debt does not announce itself. It shows up later, when you are doing a retrospective and counting the weeks between when something started going wrong and when you actually addressed it. In my experience, the gap is longer than it should be, consistently, across all six ventures. The cause is not that I am inattentive. The cause is that attention is a finite resource and I am distributing it across a surface that is too wide for it to cover completely.
The structural intervention I have used is a dedicated review cadence — not more monitoring, but a scheduled, uninterrupted pass through each venture with the specific question: what have I not been looking at? This is less elegant than an automated alert. It requires me to deliberately generate the signal rather than waiting for the system to surface it. It works partially — it catches things earlier than they would otherwise be caught. It does not eliminate attention debt, because no amount of scheduled review covers the things that broke between reviews.
How I Try to Make Attention Debt Visible
The review cadence above is the intervention. The instrument that makes it work is more specific, and it is worth decomposing, because "review each venture regularly" is the kind of advice that sounds actionable and changes nothing.
The problem with monitoring metrics is that metrics surface the things you already decided to count. The HavenWizards onboarding friction did not show up as an anomaly precisely because no metric was watching that flow at that resolution. The signal existed — in support contacts, in a tagged category, in a flagged message thread — but it lived below the threshold of anything I was actively monitoring. Attention debt accumulates exactly in the space between what a venture is generating and what the operator has chosen to look at.
So the weekly pass through each venture is built around a different question than the dashboards answer. Instead of "what do the numbers say," it asks "what is the system telling me that I have not chosen to count?" Concretely, that means reading a sample of raw support contacts rather than the rollup, scanning the message threads I marked read without processing, and looking specifically at the parts of each venture that have been quiet — because in a portfolio, silence is not the same as health. A venture that generates no escalations may be running well, or it may be one where the people closest to the problems have stopped surfacing them because nothing happened the last few times they did. The pass cannot distinguish those two states from a dashboard; it can only distinguish them by deliberately going to the uninstrumented edges and reading what is there. This catches a category of problem that no alert will, because alerts only fire on the failures you anticipated.
Priority Collapse
Priority systems work until all six ventures have a crisis on the same day. This happens more often than the probability would suggest, partly because crises are correlated — the same external conditions that stress one venture often stress others — and partly because what counts as a crisis is relative to the baseline, and the baseline across six ventures is already elevated.
The specific day I remember most clearly involved a regulatory deadline for Bayanihan Harvest, a key hire walking out at ShoreSuite, a technical outage at HavenWizards, and a course delivery problem at WonderScape that was visible to students. These were simultaneous. I had finite hours. I had to choose what to let burn.
The priority framework I had built — weighted by revenue, by external exposure, by reversibility — gave me a sequence that was analytically defensible. What it did not account for was the cost of the things I deprioritized while I was working through the sequence. The regulatory deadline was met. The HavenWizards outage was resolved. The ShoreSuite hire did not return, and the effects of that gap ran through the next three months. The WonderScape course delivery problem was addressed twelve hours later than it should have been, and several students had a bad experience during those twelve hours.
Priority collapse is not a framework failure. The framework did what frameworks do: it gave me a rational basis for sequencing decisions under time pressure. What it could not do was add hours to the day or reduce the number of things that required attention simultaneously.
The partial structural solution is building each venture to absorb short-term absence without cascade. This means investing in documentation, decision rights for people who are not me, and processes that do not require my real-time involvement to continue functioning. I have made progress on this in some ventures. In others, the complexity of the operation or the stage of development means that some things genuinely cannot proceed without me, and on the day that all six are in that state simultaneously, no framework makes the math work.
Identity Confusion
This one took the longest to name. The problem is not that I lose track of which venture I am working on — that is a simple context-switching problem with simple solutions. The problem is subtler: I start applying the mental model of one venture to decisions in another.
The governance patterns that are appropriate for a cooperative-facing agricultural platform are not the same as the patterns appropriate for a consumer-facing education product. The risk tolerance appropriate for an early-stage e-commerce venture is not the same as the risk tolerance appropriate for a property management platform with institutional clients. The communication style appropriate for graduate students is not the same as the communication style appropriate for rural cooperative officers.
When I am deeply immersed in Bayanihan Harvest for several days — thinking about cooperative governance, working with member-education frameworks, tuning the platform to the rhythms of an agricultural calendar — and then switch to ShoreSuite, there is a contamination period. My first few decisions in the ShoreSuite context are slightly miscalibrated, not wrong in ways that are obvious, but shaped by the wrong frame. I am more concerned with consensus and member buy-in than the hospitality context requires. I am less concerned with speed-to-close than the hospitality context demands.
The interventions I have tried: physical or temporal separation of venture contexts (working on one venture in the morning, another in the afternoon, with a deliberate transition ritual between them); maintaining per-venture decision journals that I read before picking up a venture I have been away from; explicit context notes at the end of each session that remind me where I left off and what the operative frame is for that venture.
These help. They do not eliminate the contamination period, because the deeper issue is not procedural — it is that I carry a primary frame based on whatever I have been most recently immersed in, and that frame influences my judgment faster than I can consciously correct for it.
Relationship Strain
The failure mode I least want to name directly, but which has probably had the largest actual cost: the people in each venture who needed more consistent attention than the distributed model could provide.
This is not about missing meetings or being slow to respond to messages. Those problems are manageable. The deeper issue is that building and maintaining the kind of working relationships that allow complex things to get done requires a quality of presence — sustained, consistent engagement that tracks where someone is, what they are carrying, what they need to be effective — that is difficult to provide across six ventures simultaneously.
At WonderScape, I worked with a curriculum designer whose contribution to the product was significant and whose engagement with the work was high. She did not need supervision or direction. She needed a thinking partner — someone who understood what she was building well enough to give her useful feedback, who tracked the evolution of the curriculum from version to version, who could tell her when she was on to something and when she was going in a direction that would not hold. I could not reliably be that person across the cycle of work because my attention was elsewhere more often than it was present.
She eventually moved on. The departure was professional, not acrimonious. But the work we did not do together in the year she was at WonderScape — the conversations we did not have, the iterations that did not happen — is a real cost. It shows up in the product.
I do not have a clean structural solution to this. The approaches I have used — clearer role definition, better documentation of context, team structures that provide peer thinking partnerships rather than depending on me — address some of it. They do not address the part of it that is fundamentally about sustained individual attention, which is not fungible.
The Infrastructure That Helps and What It Cannot Fix
The shared infrastructure I have built across the six ventures — common governance templates, shared financial reporting structures, cross-venture technology components, a communications rhythm that covers all six in regular review — does meaningful work. It reduces the overhead of context-switching between administrative functions. It makes it possible to maintain governance standards across six operations simultaneously without rebuilding the governance apparatus from scratch each time. It is worth having.
What it cannot do is reduce the fundamental cognitive and relational demands of operating six distinct ventures that each require genuine engagement. Shared infrastructure addresses the administrative overhead. It does not address attention debt, priority collapse, identity confusion, or relationship strain, because none of those failure modes are primarily administrative.
Attention debt is a function of how much there is to notice and how much noticing capacity one person has. A shared governance template does not increase noticing capacity. Priority collapse is a function of how many simultaneous crises can occur and how many a person can manage in parallel. A shared financial reporting structure does not reduce the frequency of simultaneous crises. Identity confusion is a function of how many qualitatively different frames one person holds and how quickly they can switch between them. A common technology component does not reduce the number of distinct frames. Relationship strain is a function of how many people need sustained individual attention and how much of that attention one person can provide. None of these are infrastructure problems.
The infrastructure helps with everything infrastructure can help with. The failure modes that matter most are not infrastructure problems.
The Question I Keep Coming Back To
I teach organizational design in the graduate program at PCU. I regularly work with students who are managing multiple roles simultaneously — academic work, professional responsibilities, family obligations, community commitments. The question they most frequently ask is a version of the same question I ask myself about the venture portfolio: is this sustainable, and how would I know?
The honest answer I have arrived at: sustainability in a multi-venture or multi-role context is not a binary condition. It is a rate. The question is not "can I sustain this?" but "at what rate am I consuming the resources — cognitive, relational, physical — that the operation depends on?" If the rate of consumption exceeds the rate of replenishment, the operation is not sustainable over any extended horizon, regardless of how well each individual venture is running at any given moment.
The resources that matter most — the ones I have found hardest to replenish under sustained multi-venture load — are not the obvious ones. Energy is manageable with sleep and exercise. Calendar time is a logistics problem with known solutions. The resources that are difficult to replenish are the quality of thinking under pressure and the depth of presence in relationships. Both of these are consumed by sustained multi-venture operation in ways that rest and calendar management do not fully address. Both are critical to doing the work well.
I have not resolved this question for myself. I have a clearer picture of the rate at which I am consuming these resources and a more realistic estimate of the replenishment rate than I had three years ago. The gap between the two is the answer to the sustainability question, and the gap is narrower than it was. Whether it is narrow enough is something I continue to watch.
What Did Not Have Clean Solutions
The failure modes described above all have partial structural interventions. Attention debt has improved through disciplined review cadences. Priority collapse is partially mitigated through venture-level resilience. Identity confusion is reduced by deliberate context transitions. Relationship strain is partially addressed by team structure.
What does not have a clean solution is the aggregate cost of carrying all of it simultaneously. Each venture is manageable in isolation. Six ventures simultaneously create a load that is not the sum of six manageable loads — it is something qualitatively different, because the things that break are precisely the cognitive and relational capacities that cannot be parceled out. Attention is not six times more available because I have six ventures. Thinking quality does not scale with venture count. The relationships that produce exceptional work require sustained investment that does not distribute across six simultaneous contexts.
I continue to run six ventures for reasons that are specific to this moment in the portfolio — interdependencies, compounding dynamics, strategic optionality — and because the alternative is not obviously better. Consolidating to fewer ventures would simplify the operational picture but would also foreclose options that are genuinely valuable. The cost-benefit calculation is real and I make it regularly.
But the framing I find most accurate is not that I have optimized for multi-venture operation. It is that I have built systems that contain the failure modes well enough that I can continue operating, and I have an honest accounting of what those systems cannot prevent. The optimization literature rarely provides that accounting. This is my attempt at one.
If You Are Carrying More Than One Venture Right Now
The use of this account, if it has one, is diagnostic rather than prescriptive. So here is the single thing worth doing this week if you are running more than one operation simultaneously.
Pick the two failure modes above that you suspect are most active in your situation — most operators recognize themselves immediately in two of the four — and for each, do one concrete thing. For attention debt, spend an hour going to the uninstrumented edge of your quietest venture: read the raw inputs, not the rollups, and see what is sitting there that no metric is watching. For priority collapse, identify the one process in your most fragile venture that genuinely cannot proceed without you, and write down what it would take for someone else to own it. You will not fix either problem in a week. But you will have converted a vague unease into a specific, named gap, and a named gap is something you can schedule work against. A diffuse sense that you are spread too thin is not actionable; the knowledge that ShoreSuite has no documented runbook for its onboarding handoff is.
The deeper point is the rate framing from earlier in this piece. Before you add anything to your portfolio, the question to answer honestly is not whether the new venture is a good opportunity — most of them are — but whether you have any noticing capacity, thinking quality, or relational presence left to give it. If the honest answer is that you do not, the new venture will not get a fraction of you. It will get the deficit, and so will everything already in the portfolio.
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:
- The Operating Model Problem: How to Run Multiple Ventures Without Losing Control of Any
- 18 Ventures, 1 Operating System: How Modular Architecture Scales a Solo Operator
- Managing Risk Across a Venture Portfolio
- The Indie Operator's Complete Guide to Running a Venture Portfolio
See how this plays out in practice across my portfolio of ventures.
