Most governance systems fail in one of two directions, and the failures look nothing alike.
The first failure is bureaucracy: applying the same rigor to every action regardless of risk or scope. Architectural review for a typo fix. Security signoff for a copy change. Three approvers for a one-line bug correction. The system is consistent. It is also unworkable. Teams either work around it — producing the workaround culture that quietly replaces the official process — or they slow to the point where the cost of governance exceeds the cost of the failures it prevents. Bureaucratic governance does not protect the system. It teaches the system to route around governance.
The second failure is anarchy: applying no consistent rigor at all, leaving each action to be governed by individual judgment. Each developer decides what review is needed. Each team decides its own quality standards. Each project applies whatever process feels appropriate to whoever happens to be leading it. The system is fast. It is also unaccountable. Failures happen and there is no structural memory of why. Patterns repeat across projects because no shared mechanism exists to capture and apply lessons. Anarchic governance does not enable the system. It just hides where the failures are accumulating.
Across 19 years of program delivery — founding the PMO at OpenText, founding the PMO at Full Potential Solutions, directing multi-million-dollar programs at HPE, scaling a US startup from $8-10K per month to $500K-plus across 500-plus FTEs — I have watched both failure modes destroy teams that were otherwise capable. The pattern is structural, not behavioral. Most governance designs assume the choice is between high rigor and low rigor. The actual design problem is matching the rigor to the work.
This article explains how proportional governance works across an 18-venture portfolio, why uniform rigor fails at any scale, and where the model breaks.
Why Uniform Rigor Fails
Three structural patterns explain why governance systems that apply the same standards to every task collapse under their own weight.
The Friction Tax. When every action carries the same governance overhead, the overhead becomes a tax that scales with the volume of work, not with the risk of the work. A team doing one hundred small tasks pays the friction one hundred times. The friction was designed for the high-risk task, but it applies to every task. Within months, the team has learned that getting work done requires either accepting the friction tax — which slows the team to a crawl — or finding ways around it. Either outcome destroys the system.
At one of the Australian agency offices I diagnosed during a delivery turnaround, the quality assurance process applied the same review checklist to every deliverable, regardless of size or scope. A one-page brand asset got the same review as a multi-week web build. The reviewers were genuinely diligent. The process was consistent. The result was that small work either bypassed the review entirely — because nobody could justify the overhead — or piled up waiting for reviewer capacity that was being consumed by reviews disproportionate to the work being reviewed. The agency was running at -40% to -60% on those projects. Uniform rigor was not the only cause, but it was the structural property that prevented the team from operating at the cadence the work required.
The Ceremony Compression. When governance must apply uniformly, it compresses to whatever level of rigor the lightest task can tolerate. The architectural review for a major migration cannot be more rigorous than the architectural review for a configuration change, because the same process applies to both. To make the configuration-change review tolerable, the migration review is reduced. The high-risk action gets the rigor designed for low-risk actions. The system has consistency, but consistency at the lowest common denominator. The work that actually needed governance is now governed by a process that is too light for it.
This is the failure mode I see most often in governance frameworks that started rigorous and degraded over time. The framework was originally designed for the highest-risk work. It was applied uniformly. The friction tax made it unsustainable. The framework was simplified to be more workable. The simplification stripped out the protections that the high-risk work depended on. The framework is now uniform and lightweight — which means the high-risk work is no longer governed at all, even though the framework formally still applies.
The Judgment Bottleneck. When rigor is uniform, every action requires the same judgment from the same gatekeepers. The senior architect reviews every architectural change. The lead engineer signs off on every deployment. The security team approves every external integration. The structural design assumes the gatekeepers can scale linearly with the volume of work. They cannot. As the system grows, the gatekeepers become bottlenecks. Work queues behind them. The bottleneck either slows the entire system or, more commonly, the gatekeepers start approving work without substantive review because the queue has become unmanageable.
When I directed multi-million-dollar programs at HPE, the architectural review process had this property. Every architectural decision, regardless of scope, required formal review by the same senior team. The team was technically excellent. They were also a fixed resource. As the program portfolio grew, the queue of decisions awaiting review grew with it. The reviews compressed in depth to keep the queue moving. The compression was invisible — every decision still received "architectural review" — but the substantive verification that the process was designed to provide had quietly degraded. The same process now produced different results depending on queue pressure, which is to say it produced different results at exactly the times when consistent results mattered most.
These three patterns do not yield to incremental improvements. Adding more reviewers to address the judgment bottleneck creates more friction tax. Reducing the friction tax compresses the ceremony further. Compressing the ceremony makes the high-risk work less governed than it needs to be. Each fix triggers a worse failure elsewhere.
The problem is the assumption that governance must be uniform to be consistent. It does not. Governance can be deterministic without being uniform — if the determination of which rigor applies is structural rather than judgment-based.
The Tier System
The DIOSH framework I use across the 18-venture portfolio is built on a principle that resolves the bureaucracy-anarchy tradeoff: governance rigor must be proportional to scope, and the proportionality must be deterministic.
Every task is classified into one of three tiers before any governance loads. The classification is not a judgment call. It follows from observable properties of the task — number of files affected, domains touched, whether the change crosses architectural boundaries.
Tier 1 — Surgical
A Tier 1 task touches one or two files within a single domain. A typo fix. A copy change. A single-component style adjustment. A bug correction confined to one function.
The governance overhead is minimal. The base rules in the canonical governance document apply. No additional governance documents are loaded. No registry scans are required. File-path routing determines which best-practice patterns to apply, but no full skill chain runs. The task executes immediately.
The philosophical position is that governance overhead must be smaller than the cost of the failure it prevents. Tier 1 work has small failure costs. A typo introduced by a typo fix can be corrected in seconds. The governance applied is calibrated to that risk profile. Applying full governance to Tier 1 work would create the friction tax described above without preventing failures of corresponding magnitude.
Tier 2 — Standard
A Tier 2 task touches three to ten files, or crosses a small number of domain boundaries. A new component with associated styles and tests. A schema change with the corresponding API and frontend updates. A feature flag rollout with related instrumentation.
The governance overhead is moderate. One or two additional governance documents load based on the domains touched. The relevant domain registry is scanned for prior lessons. A workflow chain runs — typically architecture-design-implementation-verification — to ensure the task progresses through the appropriate stages rather than skipping straight to code. Lesson capture is recommended at the end of the task.
Tier 2 is the most common task tier and the one where the proportionality matters most. Too much governance and Tier 2 work becomes unworkable. Too little and the system loses its ability to learn from the work that comprises most of its activity.
Tier 3 — Full
A Tier 3 task touches ten or more files, or crosses multiple architectural domains. A new venture initialization. A major lifecycle phase advancement. An architectural pattern change that propagates across the portfolio.
The governance overhead is full. All matching governance documents load. The full skill chain runs. Subagent-driven development may be required to parallelize the work safely. Lesson capture is mandatory. Phase gates are evaluated explicitly. The work is treated with the rigor that the scope demands.
The philosophical position is the inverse of Tier 1: the cost of failure at this scope is high enough to justify the full governance overhead. A flawed architectural decision propagating across the portfolio costs weeks of rework and may compromise multiple ventures. The governance applied is calibrated to that risk profile.
Deterministic Routing
The critical property is that the tier classification is not made by the operator. It is made by the system based on observable properties. File path patterns route the task to the appropriate skills automatically. A change to a migration file activates migration safety skills. A change to a UI component activates design token compliance. A cross-domain change at scale activates the interconnected systems analysis.
The operator does not decide what governance to apply. The operator decides what work to do. The governance follows from the work. This eliminates the failure mode where governance is selectively applied based on individual preference or convenience. The same change always loads the same governance, regardless of who is making it or when.
Scope Inflation Detection
Proportional governance has its own failure mode: a task that begins as Tier 1 may expand into Tier 2 or Tier 3 as the work proceeds. A "small fix" turns out to require touching twelve files. A "single component change" turns out to cross domain boundaries. If the tier is set at the start and never re-evaluated, the work proceeds under inadequate governance.
The protection is structural. The system tracks scope as the task proceeds. If the file count crosses a tier boundary, the system surfaces the change and requires the operator to re-tier. The default rule is that scope inflation always tiers up, never down. A task that began as Tier 1 and crossed into Tier 2 territory pauses and reloads under Tier 2 governance. This prevents the most common failure mode of proportional governance, which is that the proportional classification is made once and then becomes wrong as the work expands.
Operational Evidence
Scale. The 18-venture portfolio under HavenWizards 88 Ventures OPC operates under one shared governance framework with proportional tiering. Bayanihan Harvest, with 66-plus integrated modules serving Filipino agricultural cooperatives, operates under the same tier system as a single-page content property. The proportionality is what makes shared governance possible at portfolio scale. Without it, the cost of governance per venture would be unsustainable. With it, each venture pays governance overhead proportional to its complexity, and the shared framework amortizes infrastructure costs across the portfolio. One framework. Eighteen ventures. Different rigor levels per task, deterministically applied, never negotiated.
Recovery. When I directed the turnaround of an Australian digital agency network running at -20% to -60% losses, one of the structural problems was uniform rigor applied across mismatched scopes. The recovery involved tiering the work — small briefs, mid-size projects, major builds — and applying proportional governance to each. The small briefs got streamlined review. The major builds got full architectural and quality governance. Profitability reversed to +40% to +60% in part because the proportional model freed reviewer capacity to focus on the work where the review actually mattered, while letting the smaller work proceed at the cadence it required. The agency was not under-resourced. It was uniformly governed in a way that consumed resources where they did not need to be consumed.
Prevention. In one venture's development phase, what was initially classified as a Tier 1 task — adjusting a single component's styling — was detected by the scope tracker to have expanded across seven files as related styling concerns surfaced. The task was paused and re-tiered as Tier 2. The Tier 2 governance loaded the design token compliance skill, which caught a pattern of hardcoded color values that the Tier 1 governance would have permitted. The fix was extended to address the underlying token compliance issue rather than just the surface styling. The structural detection of scope inflation prevented a small problem from being patched superficially when it was actually a symptom of a broader pattern.
Compounding. Across hundreds of sessions over the portfolio, the tier classification rules have themselves accumulated lessons. Patterns emerged about which Tier 1 tasks tend to inflate into Tier 2. Patterns emerged about which Tier 2 tasks were under-protected and needed elevation criteria to Tier 3. The classification rules are not static. They are inputs that compound as the portfolio operates. The rules in use today are stricter and more precise than the rules that existed eighteen months ago, because each significant scope-inflation event has been captured as structural input to the next iteration of the tier definitions.
Where This Does Not Apply
Proportional governance assumes that the work being governed has variable scope and risk. Several contexts violate this assumption.
Uniform regulated environments. In some heavily regulated contexts — certain medical device development, certain aerospace systems, certain financial transaction processing — the regulator requires uniform rigor regardless of scope. A one-line code change in a medical device codebase may require the same review and validation as a major feature addition because the regulatory framework treats them identically. Proportional governance can violate the regulatory requirement. Uniform governance is mandatory. The model in this article does not apply.
Single-task systems. A system that does one thing repeatedly does not benefit from tier classification. There is only one tier. The governance is whatever is appropriate for that one type of work. The proportional model assumes a varied workload. Without variation, proportionality has nothing to proportion against.
Teams that distrust the classification rules. Proportional governance only works if the operators trust that the classification is fair and not being manipulated to avoid governance. If a team suspects that the classification rules are being gamed — that work is being decomposed into Tier 1 chunks to avoid Tier 2 governance — the system loses its protective function. The rules can be tightened, but the underlying problem is organizational, not governance design. In low-trust environments, uniform governance may actually be the right answer because it removes the surface area for gaming.
Crisis or rapid response contexts. During a genuine crisis — production outage, security incident, regulatory deadline — the tier classification system can become an obstacle to the rapid response the situation requires. The override protocol exists for exactly this. But the override has its own overhead, and in the most acute crises even that overhead may be too much. Honest acknowledgment that proportional governance is not the right tool for every moment is more useful than insisting it applies everywhere.
These boundaries are not failures. They are the edges of the design. Any governance framework that claims to apply universally is either lying or has not been tested against the cases where it does not.
The Principle
Governance is not a single setting. It is a function of scope.
The diagnostic question is whether your governance framework treats a typo fix and an architectural migration the same way. If it does, one of two things is true. Either the framework is bureaucratic — applying high rigor to low-risk work and creating the friction tax that produces workaround culture. Or the framework has compressed to the lowest common denominator — applying low rigor to high-risk work and providing no real protection where protection matters.
Neither outcome is acceptable. The structural fix is to make the rigor a function of the work, and to make the function deterministic. The operator does not negotiate which governance applies. The system determines it from observable properties of the task. The same change always produces the same governance. The variation is in the change, not in the discretion of whoever is making it.
Proportional governance is what allows one framework to serve eighteen ventures, ten countries, and four decades of project complexity without either drowning the small work in overhead or leaving the large work unprotected. The proportionality is the protection. The determinism is what makes the proportionality trustworthy. Build governance that scales with the work — or watch the work either route around the governance or collapse under it.
