The Scaffolding Problem in Data Organisations
Platform presence that builds capability and presence that replaces it look identical from the outside.
This essay is the second of two companions to "A Platform Is Never Finished." If you have not yet read the first companion, "Why Your Governance Dashboard Cannot Tell You What Is Wrong," that is the better starting point. It develops the presence motion: what it means for a platform team's presence to function as scaffolding rather than a permanent support structure, and why the difference is structural rather than a matter of intent. The scaffolding framing for presence originates with John Cutler, whose work the parent essay builds on; this essay develops that framing into an extended argument about how to recognise and make the transition.
The most capable platform leaders are often the ones most likely to create the problem this essay is about. Not because they make bad decisions, but because they make good ones, reliably, in every cross-domain situation that requires them. Domain teams learn to route difficult questions to the platform leader who will resolve them quickly and well. The platform leader, reading the evidence that their involvement produces better outcomes, concludes that their involvement is necessary. The cycle can continue until the platform team has become the organisation’s coordination layer, indispensable to every decision that crosses a domain boundary.
The platform has not failed. It has become load-bearing in a way that cannot scale.
This is the scaffolding problem: the failure to distinguish between presence that builds domain capability and presence that replaces it. Both look like good leadership from the outside. Both produce better short-term outcomes than the alternative of stepping back and letting domain teams struggle. The difference only becomes visible at scale, when the platform team’s involvement has become the structural dependency that prevents the organisation from operating at the speed the platform was designed to enable.
What Scaffolding Actually Means
In construction, scaffolding is temporary by design. It enables work that could not happen without it, provides the structure that lets the permanent building take shape, and then comes down. A building that requires its scaffolding to remain standing is not a finished building. The scaffolding has become the building.
The same distinction applies to platform presence. Presence is scaffolding when it is doing work that domain teams will eventually do themselves, when its purpose is to transfer capability rather than to supply it indefinitely. The platform leader who joins a domain review to model how to read a governance signal is doing scaffolding work. The one who joins because the domain team cannot read it without them is doing load-bearing work. Both are in the room. Both are producing the right outcome in that meeting. The difference is what happens at the next one.
Scaffolding presence builds the intuition, the shared vocabulary, the pattern recognition that makes delegation safe over time. Load-bearing presence substitutes for that intuition indefinitely, producing domain teams that are well-served but not self-leading, capable within the boundaries of what the platform team mediates but unable to operate at the boundaries without mediation.
The distinction is not visible in any single interaction. It is only visible in the trajectory: are domain teams becoming more capable over time, or are they becoming more dependent?
How Load-Bearing Presence Develops
Load-bearing presence does not develop through bad intent. It develops through the accumulated logic of short-term good decisions. Each answer the platform leader gives is correct. Each prevents a mistake. Each also prevents the domain team from developing the judgment to answer it themselves. The platform leader is not making a mistake. They are making a series of locally correct decisions that produce a globally incorrect trajectory.
Scaffolding does not remove the difficulty of building. It holds the structure steady while the difficulty is worked through. Remove it too early and the structure fails. Leave it in place after the work is done, and the load it was carrying never transfers to the building. That is when the scaffolding becomes the structure.
The Delegation Trap
The standard response to load-bearing presence is to announce delegation. The platform team declares that domain teams now own their data, their decisions, their outcomes. The platform leader steps back from the reviews. The escalation paths are formally closed.
What this misses is that delegation without scaffolding is not empowerment. It is abandonment at an inconvenient moment. The trap can spring without any prior period of load-bearing presence: a team delegated to from the start arrives at the same incoherence by a different route.
Domain teams that have been receiving load-bearing presence do not have the capability the delegation assumes. They have been making decisions within a system where the hard calls were reliably resolved for them. Withdrawing that support without first building the underlying capability produces the third failure mode the parent essay names: domain teams optimising locally and drifting apart, making locally rational decisions that are globally incoherent, accumulating coordination debt at every boundary where shared context was assumed rather than maintained.
The delegation was real. The capability it required was not there yet. And the exception systems, as the first companion essay argues, were not calibrated to catch the drift that followed.
This is the trap in its most common form: load-bearing presence prevents the conditions for genuine delegation, and removing presence without first building capability produces the very failure the presence was preventing. Either way, the failure is the same: delegation without the conditions that make it safe.
Delegation Theatre
The trap has a recognisable organisational form, common enough to have its own name: delegation theatre. The visible architecture has changed: autonomy declared, structures reorganised, escalation paths formally closed. But the measurement and reward systems have not changed. The invisible architecture, the system of what gets measured and rewarded, has not moved. Only the visible one has. Domain teams are autonomous in their decisions and accountable to a system designed for centralised control. The result is a combination that is worse than either full centralisation or genuine autonomy: accountability without authority, and declared freedom that the conditions of the organisation make impossible to exercise. Delegation theatre does not look like a failure of delegation. It looks like underperforming teams, and the response it triggers is usually more oversight, which completes the cycle.
What Scaffolding Presence Requires
The transition from load-bearing to scaffolding presence is not primarily a matter of stepping back. It is a matter of changing what presence is for.
Load-bearing presence is for outcomes: the platform leader is in the room because their involvement produces better decisions. Scaffolding presence is for capability: the platform leader is in the room to transfer the judgment that makes their involvement unnecessary. The conversation in a load-bearing review asks “what should we decide?” The conversation in a scaffolding review asks “how did you reach that decision, and what would you check next time before bringing it here?”
That shift requires the platform leader to tolerate outcomes that are locally suboptimal in service of capability that is globally necessary. Within the boundaries the exception system is designed to hold, a domain team that makes a decision the platform leader would have made differently is not failing. It is learning. The platform leader who steps in to correct it is choosing short-term quality over long-term capability, which is a rational choice for every individual intervention and an irrational choice for the system.
The structural mechanism for this transition is the Tight-Loose-Tight rhythm. It moves through three phases: a tight phase where boundaries are set clearly enough that domain teams understand what they are being delegated; a loose phase where genuine autonomy is released and domain teams encounter the full difficulty of operating within those boundaries without platform mediation on every decision; and a structured pause at the close where scaffolding presence reconvenes, not to correct what went wrong, but to examine what the period revealed about where the boundaries need adjusting and where domain capability needs developing. Over time, the rhythm makes the next loose phase require less scaffolding than the last. The further reading entry for "When Governance Has to Keep Up" develops this rhythm in full
The Structural Test
Whether platform presence is scaffolding or load-bearing is not a question of intent. It is a question of trajectory, and trajectory is measurable.
Three indicators reveal which kind of presence a platform team is actually providing. The first is escalation direction: are domain teams bringing fewer questions to the platform over time, or the same number? The signal is meaningful only relative to the domain team's current work cycle: a team reimplementing a major component will escalate more, and a team in maintenance will escalate less, for reasons unconnected to capability transfer. The more useful question is whether the nature of the questions is shifting from operational dependency, keeping the existing service running, toward boundary negotiation and new capability development. The second is decision confidence: when the platform leader is unavailable, do domain teams make decisions and own them, or do they defer and wait? Both of these measure the outcome of presence, not the kind. A declining escalation rate and growing decision confidence could reflect genuine capability transfer, or they could reflect a platform leader who has simply pre-solved all the hard problems.
The third indicator is the genuine discriminator, and it cannot be mimicked by pre-solving: are domain teams developing their own frameworks for the decisions the platform used to resolve, or are they still applying the platform’s framework to their own domain’s problems? A domain team with scaffolding presence will begin to adapt the platform’s approach, question its assumptions, and develop vocabulary for problems the platform never named. A domain team with load-bearing presence will wait to be told. Scaffolding builds judgment. Load-bearing presence builds dependency on someone else’s.
A platform team that cannot answer these three questions about its own domain teams does not yet know which kind of presence it is providing.
What the tests reveal, taken together, is not just the state of any individual domain team. They reveal whether the platform itself is becoming more or less necessary over time.
The platform leader who cannot answer the third question is not yet leading. They are still in the room for the wrong reason.
The companion essay, “Why Your Governance Dashboard Cannot Tell You What Is Wrong,” examines the exception motion of the same argument: what happens when exception systems operate without the presence that would make their signals interpretable.
Further Reading
“A Platform Is Never Finished” : the parent essay: exception, presence, and delegation as a simultaneous system, and what each failure mode costs.
“Why Team Autonomy Is an Architectural Decision, Not an Organisational Preference” : develops the delegation motion: why independence is a structural property of the platform, and how to measure whether domain teams actually have it.
“The Incentive System Always Wins” : the invisible architecture argument: why domain teams that receive load-bearing presence will use any delegated authority in service of whatever the measurement system still rewards.
“When Governance Has to Keep Up” : develops the three-phase rhythm described in this essay in full, including the boundary-setting, autonomy, and structured pause that make the scaffolding transition possible over time.
Honest Endnote
This essay argues with confidence that load-bearing and scaffolding presence are structurally distinct, that the difference is visible in trajectory rather than in any single interaction, and that the transition from one to the other requires tolerating short-term suboptimal outcomes in service of long-term capability. Those claims are grounded in how platform teams actually develop and how domain capability actually transfers.
What it leaves open is the question of timing: at what point in a platform’s development should the transition from load-bearing to scaffolding begin, and what signals indicate that a domain team is ready for the loose phase of the rhythm? The argument that the transition must happen is defensible. The precise conditions that make it safe are more context-dependent than this essay can resolve. If you are operating a platform team and watching domain teams apply the platform’s frameworks to their own problems rather than developing their own, the comments are the right place to bring what you are seeing.