John Cutler recently wrote about three fundamental motions in management: exception, presence, and delegation. His framing is sharp and broadly applicable. This essay takes it somewhere specific: into data organisations, where the same three motions operate across two distinct kinds of team, and where getting the balance wrong has consequences that compound quietly until they become impossible to ignore.
Most data platform failures are not technical. The architecture was sound, the tooling was capable, the roadmap was coherent. What broke was something harder to name: a leadership model that treated the platform as something to build rather than something to operate. That orientation problem has an execution consequence: it leaves the three motions that sustain a platform without anyone responsible for holding them together.
Two kinds of team define the boundary: the platform team, which builds and operates the shared data infrastructure, and the domain teams, which use it to create value. The three motions apply to both, and the way they connect across that boundary is where most of the difficulty lives.
What the Three Motions Actually Are
Exception-based leadership means the system generates signals when something deviates from what is expected, and those signals reach the people who can act on them. For the platform team this means governance logic embedded in the infrastructure itself: automated quality gates, data contracts that enforce interface agreements, access controls that provision and enforce themselves. For domain teams it means the observability, lineage, and alerting built into their own pipelines: the signals that tell them whether the data they are producing and consuming is healthy, trustworthy, and moving as intended. When exception systems work well on both sides, they do not just catch failures. They build a shared causal model of how the whole system actually behaves, over time, as signals are observed, interpreted, and acted upon. The exception system is also the learning mechanism.
Presence-based leadership means staying close enough to the work to develop intuition that no signal can give you. For the platform team this means understanding what domain teams actually struggle with, not what they report in status meetings: which self-service capabilities break down in practice, where the governance layer creates friction that gets worked around rather than resolved. For domain teams it means leaders who are close enough to the data to know when a number that passes every quality check is still telling the wrong story. Presence is how tacit knowledge transfers. It is also how trust accumulates in the direction that makes delegation safe.
Delegation-based leadership means pushing authority to the people closest to the work, within boundaries that are understood and held. For the platform team, this means building infrastructure that domain teams can use without central mediation: deploy without approval, consume governed data without negotiating access, operate within clear contracts rather than through ongoing coordination. For domain teams it means genuine ownership of their data, their decisions, and their outcomes. The goal in both cases is the same: push authority to where the information lives, rather than pulling information toward where the authority sits.
Together, exception systems free the attention that makes presence affordable. Presence builds the calibration that makes delegation safe. Delegation creates the local knowledge that sharpens the exception system over time: knowledge about which signals are real versus artefactual, which thresholds are calibrated to the wrong baseline, which governance rules generate workarounds that the exception system cannot see.
When all three operate together, they form a virtuous loop. When one is missing, the other two become dysfunctional in predictable ways.
When the Loop Breaks
The most common failure in data organisations is strong exception systems with weak presence and nominal delegation. The platform team has built the quality gates, published the governance reports, automated the contracts. Platform leadership reads the signals and concludes it understands what is happening. Domain teams observe that the signals pass through without context and trigger unpredictable responses from the centre. They learn to manage the signal rather than the underlying reality. The exception system becomes a performance, and the performance becomes the work.
The second failure mode is strong presence with weak exceptions and hollow delegation. A platform leader who is in every domain review, close to every cross-domain decision, present at every escalation, eventually becomes the organisation’s coordination layer. Domain teams stop exercising their own judgment because it is never required unsupervised. The platform leader concludes that their involvement is necessary because the evidence, which their own presence produced, is that things go wrong when they step back.
A platform team that is indispensable to every cross-domain decision is not leading. It is load-bearing in a way that cannot scale.
The third failure mode is delegation without the other two: domain teams told they own their data, but without the exception systems that would make that ownership safe, and without platform presence close enough to the work to sense where boundaries are straining. Without shared signals to coordinate around, domain teams make locally rational decisions that are globally incoherent: pipelines built on diverging definitions, metrics that cannot be compared, definitions that have drifted without anyone watching, ownership claims that overlap or conflict. The coordination debt, the accumulated cost of decisions made without shared context, grows invisibly until the first cross-domain decision produces outcomes two parts of the organisation cannot reconcile.
These three failure modes are diagnosable because they each point to a missing motion. A fourth condition is harder to diagnose precisely because it makes the motions look present when they are not.
Every data organisation running a transformation is operating two organisational architectures simultaneously: the visible one, what is said, shown, and reorganised, and the invisible one, what is counted, rewarded, and punished. The invisible architecture is the incentive system, and it always wins. When the measurement system has not changed, exception systems are calibrated to catch what the old incentive rewarded, not what the new strategy requires. And presence, in an organisation where visible change has repeatedly outrun structural change, is received with the scepticism that the gap has earned. Whatever order the other changes arrive in, the measurement system lags. It is the last thing to move. The invisible architecture is still governing.
The Sequencing Error
Most data organisations do not choose one motion and ignore the others deliberately. They encounter them in sequence and mistake sequence for sufficiency.
Platform teams typically begin with strong presence: a small group, close to both the infrastructure and the domain teams using it, shared context, rapid iteration on what works. As the platform grows, they formalise: governance frameworks, quality metrics, reporting structures. Exception systems arrive. But presence thins as scale demands attention elsewhere, and delegation to domain teams happens by necessity rather than design. The three motions come apart not through any single decision but through the accumulated logic of growth: each motion feels sufficient at the scale it was introduced, and the cost of the missing one only becomes visible at the next scale up.
This is the sequencing error: treating the three motions as a maturity ladder rather than a system. The motions do not hand off to each other. They hold each other up.
The moment an organisation believes it has graduated from presence to exceptions, or from exceptions to delegation, it has already begun to lose the motion it thinks it no longer needs.
Operating All Three at Once
The distinction is between developmental sequencing, graduating from one motion to the next, and operational rhythm, cycling through all three continuously within the same period of work, not across periods. The Tight-Loose-Tight rhythm, developed in full in the companion essay on adaptive governance, offers one practical way to hold all three motions active at once. Each cycle moves through a tight phase of boundary-setting, a loose phase of genuine domain autonomy, and a structured “Stop! Think!” pause where presence reconvenes to examine whether the boundaries and signals are still watching the right things.
Holding the rhythm is harder than designing it.
Each motion generates pressure against the other two: exception systems create pressure toward central control, delegation creates pressure away from presence, and presence creates pressure toward individual judgment over systemic signal. Holding all three requires more than good intentions. It requires a rhythm that keeps them in tension with each other rather than letting any one dominate.
Exceptions without presence produce legibility without understanding: quality gates pass green, governance reports look clean, and the gap between signal and reality widens before anyone notices.
Presence without delegation produces dependency without capability: domain teams well-served but not self-sufficient, with all the fragility that implies when platform attention moves elsewhere.
Delegation without the other two produces autonomy without coherence: domain teams optimising locally while coordination debt accumulates across the boundaries between them.
Each of those three outcomes is reversible. But only if the missing motion is identified before the cost becomes structural.
The practical implication is a question most platform teams have not asked directly: which motion are we weakest in, and what has that cost us?
What the Motions Actually Demand
Holding all three simultaneously is not a matter of personal discipline, engagement, and restraint, though it requires all three. Each orientation is made sustainable by the infrastructure the other two motions build: the exception system that frees the attention presence requires, the delegation that gives presence room to function as scaffolding domain teams eventually no longer need rather than a permanent support structure they cannot operate without. What the three orientations demand, in practice, is that leaders design for the motions rather than perform them. Designing means building the exception systems before the governance crisis arrives, delegating before the coordination cost forces it, and staying close to the work before the signal drifts from the reality it was built to reflect.
A data platform is not a thing you build and hand over. It is a system you operate, continuously, through all three motions at once.
Coming: Two companion essays develop the failure modes introduced here in fuller depth. Each stands independently and develops one motion of the argument. “Why Your Governance Dashboard Cannot Tell You What Is Wrong” develops the exception motion. “The Scaffolding Problem in Data Organisations” develops the presence motion.
Further Reading
“The Incentive System Always Wins” — develops the incentive mechanism that sits inside the invisible architecture described here: why the measurement system changes last, and what that means for any transformation that relies on the motions operating as declared.
“Why the Best Governance Is Built Into the Platform, Not Bolted On” — develops the exception motion of the argument: what it means to embed governance in architecture rather than administer it through oversight.
“Why Team Autonomy Is an Architectural Decision, Not an Organisational Preference” — develops the delegation motion: why independence is a structural property, not a cultural aspiration, and how to measure whether you actually have it.
“The Scaffolding Problem in Data Organisations” - coming - (also referenced above as a companion) — develops the presence motion: the distinction between platform presence that builds domain capability and presence that replaces it, and why the difference is structural rather than a matter of leadership style.
“When Governance Has to Keep Up” — the adaptive governance argument that sits beneath the Tight-Loose-Tight rhythm described here.
Honest Endnote
This essay argues with confidence that the three motions are mutually constitutive, that sequencing them rather than operating them simultaneously is a structural error, and that each failure mode is predictable from which motion is missing. Those claims are tested across enough platform contexts to feel stable.
What it leaves open is more specific: what does minimum viable presence look like at scale? The rhythm helps, but it does not answer what presence means when the platform is too large for any single leader to be genuinely close to the work across all of it. If you are operating at that scale and watching the presence motion thin, the discussion section is the right place to bring what you are seeing. The companion essay on the scaffolding problem opens a related question: at what point in a platform’s development should the transition from load-bearing to scaffolding presence begin.