Understand where maturity is uneven — and which lag matters now.
Read Technology, Organisation and Trust together, identify the dependencies between them, and determine which dimension is becoming the binding constraint for the next transition.
Deep-tech systems rarely stall because nothing is improving. They stall because improvement is uneven. The SSMF makes that imbalance visible — showing where maturity is lagging, where fragility is accumulating and what deserves investigation next.
Read horizontally to see how each dimension evolves. Read vertically to see whether the system is maturing coherently or whether one dimension is lagging behind the others. A lagging dimension is a candidate binding constraint: a signal for where to investigate, not an automatic prescription for what engagement must follow.
| L1 · Initial | L2 · Managed | L3 · Defined | L4 · Adaptive | |
|---|---|---|---|---|
| Technology | "We'll clean it up later."Prototype-centric. Ad-hoc development. Technical debt accumulates invisibly. Cadence slows under the weight of decisions made for speed. | "If we ship faster, we're scaling."Technical coupling. Reactive delivery. Architecture limits scale. Local acceleration hides systemic fragility. | Architectural runway. Designed for growth.Parallelism is safe. The system absorbs change without losing coherence and cadence. | Continuously optimised.Open interoperability. Scales without redesign. Other teams extend it autonomously. |
| Organisation | "Speed means we're aligned."Decisions through founders. Heroic coordination. No system behind the people. Alignment based on individuals doesn't scale. | "Process equals maturity."Formal process, implicit decisions. Delivery depends on heroism. Coordination cost moves from architecture into the org chart. | Delivery without heroism.Coordination at scale. Explicit decision systems. Escalation is the exception, not the default. | Adaptive governance.Scales without refounding. Leadership multiplies. The system onboards its own successors. |
| Trust | "It works because you know who to call."Personal trust. Fragile at distance. Breaks when key people leave. Trust debt accumulates invisibly. | Trust in people, not process.Strong internally, opaque externally. Institutional buyers can sense it but can't verify it. The trust runway hasn't been built. | Structural, evidence-based.Selling reliability, not potential. Assurance artifacts any procurement team can verify — independently of any relationship. | Trust as system property.Self-reinforcing. Survives change in people. The system maintains the trust record continuously. |
The SSMF whitepaper explains the Scaling Trap, the three coupled dimensions, the L2→L3 transition and how the framework is used to reason about scale-readiness.
Each level is a qualitative shift in how the venture behaves under pressure — not an incremental improvement in process.
The self-deceptions at each level are the signal: the rationalisation founders reach for when the dimension is lagging but the pressure to keep moving is high.
"Architecture is not about structure; it determines whether future options expand or collapse."
Maturity here is measured as the system's ability to absorb change without losing coherence and cadence. The binding question at each level is whether the architecture is accumulating debt or building runway.
"We'll clean it up later" — but later compounds, and cadence slows under accumulated technical debt.
"If we ship faster, we're scaling" — but coupling grows faster than throughput, and local acceleration hides systemic fragility.
"We can fix it later by adding more integrations" — but integration amplifies whatever the architecture already is. Acceleration exposes constraints; it doesn't remove them.
"If technical architecture defines system boundaries, organisational architecture defines authority boundaries — and misaligned authority creates the same fragility as misaligned interfaces."
Deep-tech systems fail usually at the decision level, not just the technical level. The patterns of founder routing, heroic recovery and informal override are the organisational equivalent of technical coupling.
"Speed means we're aligned" — but alignment based on individuals doesn't scale.
"Process equals maturity" — but process without clear decision rights only increases latency. Coordination cost moves from architecture into the org chart.
"Everyone is responsible" — but when everyone owns it, no one does. Scaling is not only about what the system can do; it is about who is allowed to decide.
"Trust is the least visible and most decisive dimension — and it has two faces that mature and fail differently."
Treating the two faces as one is the most common reason this dimension is mismanaged. The transition from personal trust to systemic and structural trust is what separates fragile growth from scalable growth.
The system is not predictable enough to be trusted by default, so people compensate with heroics, escalations and checks. "It works because you know who to call." Once trust becomes scarce, scaling becomes political.
Credibility built deliberately ahead of need: the evidence, predictability and delivery discipline that let institutional buyers rely on you before a relationship exists. Without it you win the demo and lose the deployment.
The most important scaling step is not prototype to product. Many ventures look mature enough to scale — and then fall back into Level 2 behaviour the moment pressure hits.
Founders override decisions. Teams renegotiate commitments informally. Escalations bypass structure. Execution returns to heroics. This is not a failure of intent — it is a failure of structural design. Across the full SSMF, that redesign has to hold across architecture, authority and trust.
On the organisational side of the L2 → L3 crossing, three things must become explicit that at L2 often remain implicit, personality-dependent or urgency-driven:
Clear inputs, outputs and quality thresholds between teams — so coordination doesn't require constant mediation.
Explicit decision rights and escalation paths that hold under pressure — not just in calm periods.
Deadlines and goals as reliable contracts — not negotiable intentions that depend on who's watching.
A venture adds process but reverts to heroics under pressure. More planning cadence, more governance rituals, more formal roles — for a while it looks more mature. Then pressure hits and the system snaps back.
The signal: the same decisions keep re-escalating, the same people keep getting pulled in, the same commitments keep slipping. Not because the team is weak — because the structure isn't load-bearing.
"Structure that only works in calm periods is not structure. It is choreography. A venture that adds process but reverts to heroics under pressure is not in transition — it is oscillating, and oscillation compounds cost in trust, speed and valuation."
Nine questions, roughly ten minutes. The Check applies a lightweight version of the SSMF to behaviours you can recognise in your own organisation. Answer for where you are, not where you aspire to be. The result gives you a per-dimension maturity profile, highlights likely binding or coupled constraints where visible, and flags possible oscillation. Use it when the real constraint is still unclear.
The Check is optional. You do not need to complete it before discussing a situation or starting a CompoundWorks engagement.
Each question describes a situation your organisation faces. Select the answer that best describes what actually happens — not the ideal version. The result gives you a per-dimension maturity level, highlights a likely binding constraint where one is visible, and flags any oscillation patterns.
If the real constraint is still unclear, a Diagnostic Sprint can investigate the system across dimensions. If the problem is already sufficiently bounded — product, architecture, deployment, investment or another defined decision — start directly with the relevant engagement. The SSMF informs the work; it does not force every situation through the same sequence.
The Scaling System Maturity Framework applies systems thinking to the challenge of maturing a deep-tech company. Technology, Organisation and Trust are three different dimensions of the same scaling system. All three matter.
They do not have to evolve at the same pace. A technology venture will often mature the Technology dimension first as it develops the core technology, reaches an MVP and proves that the system works. But technical maturity alone is not enough. If Organisation or Trust lags too far behind — or if Technology itself fails to build the architecture needed for what comes next — the imbalance can become the constraint that jeopardises the next stage of the venture.
Read Technology, Organisation and Trust together, identify the dependencies between them, and determine which dimension is becoming the binding constraint for the next transition.
Once the constraint is visible, focus on the architecture, operating system or trust mechanisms that have to catch up so the company can move forward without destabilising what already works.
Use READ when the company needs a stronger structural view of what is really constraining it. Use RESOLVE when the lagging dimension and the decision are already clear enough to work directly.
See READ & RESOLVE →The Check is an optional lightweight way to look across Technology, Organisation and Trust before deciding what deserves deeper attention. It is not a prerequisite for working directly on a known problem.