Plain-language definitions of the Drift framework and the agile and scaled-delivery vocabulary around it. The proprietary terms, the roles they sit between, and the long-studied gap the Drift belongs to. Search it, filter it, or link straight to any definition.
The distance between the Stated System an organisation documents and the Lived System it actually operates.
Reading the Drift is a leadership practice, not a clean-up project. The gap is not a failure to be tidied away; it exists because the Stated System was never sufficient on its own. The leadership move is to read the Drift, decide what it is telling you, and name who pays for it.
The organisation an enterprise documents: org chart, written process, planning cadence, reported metrics, prescribed roles, and the language used in steering committees.
It is the version of the company that appears on slides and in policy. It keeps producing reassuring output the whole time the organisation is drifting, which is exactly why the Stated System alone is never enough to tell you what is happening.
The organisation an enterprise actually operates: where decisions get made, how priorities are really set, whose calendars set the pace, and which channels carry the truth.
It only has answers in the heads of the people who do the work, and it surfaces through private conversation in specifics: names, channels, calendars. Most of the real coordination of a programme lives here, not in the documented process.
The leadership practice of naming the gap between the Stated System and the Lived System and deciding what to do about it.
It is the opposite of trying to tighten process until the gap disappears. Tightening rarely closes the Drift, because the Drift exists in the first place where the Stated System was insufficient. Reading it well means treating the gap as information about how the work really gets done.
A short sequence for reading the Drift in any specific context.
First, what does the Stated System say should happen here? Second, what does the Lived System actually do here? Third, who pays for the gap, and what would close it? The questions move from the documented answer, to the lived answer, to the decision.
The third Drift question. Drift is never free; someone always absorbs its cost, usually the people closest to the work.
Naming who pays turns the Drift from an abstract feature of the organisation into a concrete decision someone is accountable for. Until the cost has a name, the gap stays invisible and keeps being paid quietly.
A five-question diagnostic that gives a baseline for how far the Stated System and the Lived System have diverged in a given context.
It is available as an interactive in-browser check on the Tools page, as a printable worksheet on the Companion page, and as drift-cli, a local-only command-line tool that keeps every score on your own machine.
When a status board stays green and the cadence keeps running while the real work has moved elsewhere.
The reassuring output of the Stated System is precisely what hides the Drift. The status on the deck stays green, the roles are still on the org chart, but the work is being carried by people who are not named in the process, in forums that are not in anyone's calendar.
An unofficial intake path through which work enters a team without passing through the stated process.
It is a common early signature of Drift on a delivery board: a steady stream of items that never went through planning but still consume the team's capacity. Reading the side door tells you where the Lived System has routed around the Stated one.
The unofficial document a new joiner is actually handed in their first week.
It tells the truth about the Lived System precisely because it was never made official. Making it official starts its decay, because the moment it becomes part of the Stated System it stops describing how the work really gets done.
The servant leader and chief facilitator of an Agile Release Train in the Scaled Agile Framework (SAFe).
The RTE facilitates programme-level events, manages risks and cross-team dependencies, and helps the train deliver value on its cadence. It is one of the roles the Drift framework speaks to most directly, because the RTE sits between a written framework and the teams that must make it survive contact with reality.
The role that facilitates a Solution Train in SAFe, coordinating multiple Agile Release Trains and suppliers building a single large solution.
Common in automotive, aerospace, and other large engineering programmes where one solution, such as a vehicle, depends on many trains and external partners delivering together. The STE works at the seams between them, which is exactly where Drift accumulates.
A long-lived team of agile teams, typically 50 to 125 people, that plans, commits, and delivers together on a common cadence.
The ART is the primary value-delivery construct in SAFe. It aligns teams to a shared mission and a single Program Increment rhythm, so that many teams can ship a coherent result rather than a pile of disconnected parts.
A fixed timebox, usually eight to twelve weeks, in which an Agile Release Train delivers value.
PI Planning is the cadenced event that opens the increment, where the teams of a train plan together, surface dependencies, and commit to objectives. In practice much of the negotiation happens in the weeks before the event; the event ratifies it.
A widely adopted framework for applying agile practices across many teams and large programmes.
It is structured around Agile Release Trains, Program Increments, and a Lean-Agile operating model. The Drift framework is written for people running scaled programmes like these, where the framework on paper cannot simply be followed as written.
The role accountable for a team's effectiveness in Scrum: coaching the team, facilitating its events, and removing impediments.
Where the RTE works at train level, the Scrum Master works at team level. Both are the people who most often feel the Drift first, because they stand between the prescribed process and the team doing the actual work.
The gap between what an organisation knows it should do and what it actually does, named by Jeffrey Pfeffer and Robert Sutton.
The Drift is a practitioner's reading of the same underlying gap, narrowed to scaled engineering delivery and made operational with the Stated System, the Lived System, and the three Drift questions. Where the knowing-doing gap explains why the gap exists, the Drift is written to be acted on in a status meeting.
Chris Argyris and Donald Schon's distinction between the account people give of how they act and the rules their behaviour actually follows.
Espoused theory is what we say we do; theory-in-use is what we actually do. It is the intellectual lineage behind the Drift: the Stated System is an organisation's espoused theory, the Lived System is its theory-in-use.
No terms match your search. Try a different word or clear the filter.
The full framework: the two systems, the three questions, and who it is for.
EssayThe long-form essay that introduces the Stated System and the Lived System.
ToolThe five-question diagnostic, scored live in your browser. Nothing stored or sent.
The bookThe field guide these terms are drawn from. Out Summer 2026.