Should Organisations Try to Eliminate Complexity, or Design for It?

The standard narrative about organisational complexity treats it as a symptom of poor planning. If you had designed the architecture better from the start, the story goes, you would not have ended up with seventeen data integrations, four overlapping approval workflows, and a governance model that nobody can explain in under ten minutes. This narrative is wrong in a specific and important way.

Complexity is not primarily a product of bad decisions. It is a structural property of any system with multiple interdependent parts. When DAVE, voolama's AI workflow orchestration product, moved from internal tooling to a product offered to enterprise customers, the complexity did not come from a bad architectural decision. It came from the fact that enterprise customers have different data residency requirements, different approval chains for AI-assisted decisions, and different definitions of what 'auditable' means. Each of those differences required a design decision about where the complexity would sit: in the product's configuration layer, in the customer's governance documentation, or in a shared standard that both sides agreed to apply.

The same pattern appeared when The DAM Republic, voolama's vendor-neutral digital asset management hub, was built. The complexity of evaluating ten or more DAM vendors simultaneously does not disappear because a hub exists. It is redistributed into the hub's taxonomy, comparison methodology, and editorial governance. If those are not maintained explicitly, the hub loses its value. The complexity is always there; the question is only whether it is owned or ignored.

Acknowledging this changes the design problem. The question is not 'how do we prevent complexity?' but 'where do we put it, and who is best placed to absorb it?' That is a design question with a tractable answer. The prevention question has no good answer, because the complexity is coming regardless.

Disclosure: voolama LLC is a holding company whose portfolio spans AI workflow orchestration, digital asset management, consulting, and airport SaaS. The argument made here, that portfolio structures and shared governance create durable advantages in managing complexity, reflects voolama's commercial model. Readers should weigh that interest accordingly.

When organisations that scale well are studied closely, the pattern is rarely that they eliminated complexity. It is that they moved it to where it could be managed most efficiently. This is redistribution, and it is the core discipline of durable organisational design.

Redistribution takes several forms in practice:

• Into tooling: Automating a complex, repetitive workflow does not eliminate the complexity of that workflow; it encodes it into a system that can execute it consistently without human attention on every instance. The complexity is still there; now it lives in the tool's configuration and the governance rules around it. When building DAVE's workflow orchestration layer, the design question was not 'how do we make the workflow simple?' but 'which parts of the workflow complexity can be encoded reliably, and which require human judgement at the point of execution?' The NIST AI RMF 1.0 GOVERN function (published January 2023) formalises this distinction as organisational roles and responsibilities for AI risk: moving a decision into an automated system does not remove the need for human accountability over the system's design and outputs.
• Into specialist roles: A legal, compliance, or security function absorbs complexity that would otherwise be distributed across every team that touches those domains. For a portfolio operating across AI, DAM, consulting, and airport SaaS, a single shared legal and compliance function absorbs regulatory complexity that would be uneconomic for each venture to manage independently. The fixed cost of that expertise is distributed across four ventures; the benefit is available to each at a fraction of the standalone cost.
• Into governance structures: A well-designed governance framework makes explicit decisions about who is accountable for what, under which conditions, with which escalation paths. ISO/IEC 42001:2023 section 5 (Leadership) and section 6 (Planning) provide a concrete template for this kind of accountability mapping in AI-assisted organisations. Applying that structure to DAVE's AI decision workflows meant that when a customer asked 'who is accountable if the AI recommendation is wrong?', the answer was documented rather than improvised.
• Into the parent entity: In a portfolio structure, the holding company can absorb complexity that would be disproportionately expensive for an individual venture to manage alone: regulatory monitoring, shared infrastructure, cross-venture data standards, and capital allocation frameworks.

The failure mode is redistribution without acknowledgement. When complexity is moved into tooling or governance without being explicitly named and owned, it becomes invisible. Invisible complexity is the most dangerous kind, because it accumulates until a system event makes it suddenly visible, usually at the worst possible moment. In Rarovera's consulting work, the most common root cause of stalled digital transformation programmes is not technical: it is a process that everyone knows is broken but that nobody owns, because the ownership question is itself too complex to resolve without a governance decision that nobody has made.

One of the most persistent confusions in organisational design is treating clarity and simplicity as synonyms. They are not. Simplicity is a property of the system: fewer components, fewer interactions, fewer dependencies. Clarity is a property of the communication about the system: how legible it is to the people who must act on it.

A complex system can be made clear. A simple system can be opaque. The goal of good organisational communication is clarity, not simplicity, because the underlying system is often genuinely complex and pretending otherwise produces distortion rather than understanding.

Clarity requires three things that simplicity does not:

1. Explicit interfaces: Every point where one team, system, or process hands off to another should be documented: what is passed across the interface, in what format, with what quality standard, and who is accountable if it is wrong. The EU AI Act (Regulation (EU) 2024/1689, in force August 2024) requires exactly this kind of interface documentation for high-risk AI systems under Article 9 (risk management system) and Article 13 (transparency and provision of information to deployers). Organisations that have already built explicit interface documentation for operational reasons find compliance with these requirements significantly less disruptive than those that have not. Building that documentation into DAVE's product design from the start, rather than retrofitting it for compliance, is a concrete example of complexity being placed in the right location early.
2. Named accountability: For every significant decision or outcome, there is a named role, not a team, not a committee, a role, that is accountable. Accountability does not eliminate the complexity of the decision; it eliminates the complexity of figuring out who should be making it. In Rarovera's consulting engagements, the single most reliable intervention for a stalled integration programme is naming one person accountable for the handoff between the old system and the new one during the transition period.
3. Honest tradeoff documentation: When a design decision absorbs complexity in one place by creating it in another, that tradeoff should be written down. The organisations that manage complexity best are the ones that can articulate, in plain language, what they chose not to simplify and why.

voolama's stated mission, bringing clarity to complexity, is a commitment to this discipline rather than a promise to make hard things easy. The complexity of enterprise AI, digital asset management, airport SaaS, and consulting does not disappear because a portfolio holds them together. What the portfolio can offer is a more mature infrastructure for making that complexity legible and manageable.

One of the less-discussed advantages of a portfolio structure is that it creates compounding returns on complexity-management capability. Each venture a holding company builds or acquires arrives with its own complexity: technical, commercial, regulatory, and operational. Managing that complexity generates knowledge. The knowledge, if it is captured and transferred, reduces the cost of managing complexity in the next venture.

This compounding effect operates across several dimensions:

• Governance templates: The accountability mapping built for DAVE's AI decision workflows, using ISO/IEC 42001:2023 sections 5 and 6 as the structural template, did not need to be rebuilt from scratch when Airport Online required its own governance documentation for uptime and incident response. It needed to be adapted, which is a much smaller investment than creation.
• Tooling standards: A shared approach to workflow orchestration, data integration, or security monitoring, once established, reduces the integration complexity of each new venture that joins the portfolio. When Airport Online joined the voolama portfolio, the workflow and integration patterns already in use across DAVE and Rarovera provided a starting point that avoided rebuilding foundational infrastructure from scratch.
• Pattern recognition: The signal that complexity is accumulating in a dangerous place is usually the same across ventures: a process that everyone knows is broken but that nobody owns, because the ownership question is itself too complex to resolve without a governance decision that nobody has made. Recognising that signal early, before it becomes a crisis, is a capability that develops through repetition across multiple ventures.
• Talent infrastructure: Specialist roles, legal, compliance, security, data architecture, that would be uneconomic for a single early-stage venture become viable when shared across a portfolio. The fixed cost of that expertise is distributed; the benefit is available to each venture at a fraction of the standalone cost.

The compounding effect is not automatic. It requires deliberate knowledge transfer: post-mortems that are actually read, governance documents that are actually updated, and a parent-entity function that treats complexity management as a core competency rather than a side effect of running multiple businesses. voolama has operated across these four ventures since 2016. The honest assessment is that the compounding effect took several years to become visible. The first venture absorbs the full cost of building the infrastructure; subsequent ventures benefit from it, but only if the infrastructure is maintained rather than allowed to atrophy between uses.

This article makes a case for treating complexity as a design constraint rather than a problem to eliminate. It is worth being explicit about where that argument stops.

• Early-stage single-product businesses: For a business with one product, one market, and a team of fewer than twenty people, the right move is often to reduce scope rather than design for complexity. The redistribution mechanisms described here, governance layers, shared tooling, specialist roles, carry overhead that is not justified at small scale. This framework is most useful from the point at which a second product, market, or regulatory environment is added.
• The human and cultural dimensions: Structural design for complexity is necessary but not sufficient. Organisations also need leaders who can communicate complexity clearly, teams that are psychologically safe enough to surface it, and cultures that reward honest tradeoff documentation rather than punishing it. Those are change leadership challenges that go beyond the scope of this article.
• Sector-specific regulatory complexity: The frameworks referenced here, including ISO/IEC 42001:2023 and the NIST AI RMF 1.0, provide useful starting points for governance design. They do not substitute for qualified legal and compliance advice in specific regulated sectors. The EU AI Act obligations for high-risk systems (phasing in through August 2026) are particularly sector-sensitive and require specialist legal review.
• Technical complexity in AI systems: The argument here is about organisational and operational complexity. The technical complexity of AI model behaviour, adversarial robustness, and alignment is a separate domain that requires specialist expertise beyond organisational design.