The Error in your Mental Model
Most coordination work is designed around a single assumption: if we plan well, communicate clearly, and hold people accountable, execution will stay on track.
It doesn't. And the response is always the same — more planning, clearer communication, stricter accountability.
The assumption is wrong. Not because planning and communication are bad tools. Because drift isn't a planning failure. It's physics.
Intelligent systems under execution pressure move away from original intent. Predictably. Continuously. In specific directions that can be named, anticipated, and designed around. The question isn't how to prevent drift. It's how to design a system where drift is caught early and recovery is cheap.
The Gearbox Model
Think of execution as driving a car. The execution frame is the car. The gearbox has four labeled positions — but there are eight actual forces acting on the wheel.
Four are visible. Four are invisible.
The Four Visible Vectors
These are the forces every project manager plans around. They're visible because they have obvious names, obvious symptoms, obvious owners.
D — Drive
The delivery vector. The more you do, the more you're pulled toward DONE. In early stages this looks like progress. At high drift: obsessed with shipping the solution, forgotten the original problem. The team is producing, measuring velocity, closing tickets — and moving steadily away from intent.
Sequence: DO → Discuss → Define → Design → Develop → Deliver → DONE.
P — Park
The planning vector. The more you prepare, the harder it becomes to start. At high drift: the project is parked. Too much analysis, too many unknowns, too expensive to begin. Procrastination disguised as diligence. The plan is excellent. Nothing ships.
S — Sport
The systematizing vector. Standardise, Secure, Scale. At high drift: building reusable frameworks before the specific problem is solved. Abstracting before basics work. The team is producing infrastructure for a product that doesn't yet do the thing it needs to do.
R — Reverse
The Requirements and customization vector. The more you discuss requirements with actual users, the smaller the feature scope becomes. Real users direct UI and process, not product strategy. At high drift: original intent compressed into UX optimization. Scope shrinks to what the loudest requester asked for last week.
The Four Invisible Vectors
These operate without acknowledgment. They don't appear in project plans, risk registers, or retrospective agendas. Which is exactly why they're dangerous — the team experiences the pull but doesn't have language for it.
Engine Light
Experience / Expertise vector. Experts insist on standard solutions regardless of intent. "We always build it this way." The pull is toward the known, the proven, the previously successful. At high drift: the team delivers a technically excellent solution to a slightly different problem than the one that was asked. Nobody is wrong. The expertise is real. The fit isn't.
Oil Light
The Owner / Oracle vector. The sponsor's attention is a force. Continuous alignment with the owner pulls execution toward what the owner currently cares about — which may have shifted since the work was scoped. At high drift: the PM is managing stakeholder perception, not delivery. The work that gets done is the work the owner noticed last.
Fuel Light
Fear of failure, fear of unfamiliar territory, fear of making a mistake that's visible. At high drift: delays disguised as diligence. Extra checks, extra reviews, extra sign-offs. The work gets done slowly, carefully, in the direction of least exposure rather than greatest impact.
Low
Low Motivation, low capacity, low perceived importance, low confidence in own capability. At high drift: deprioritized, minimal effort, "not really my problem" thinking. This one is invisible because it looks like reasonable resource allocation. The work isn't refused — it just never quite becomes urgent enough to do well.
Why Eight Vectors Matter
Most coordination frameworks account for D and P — delivery pressure and planning paralysis. Some add S (scope creep) and R (customer-driven drift).
The invisible four — Experience, Owner, Fear, Low Motivation — operate in the background of almost every execution failure. And because they're unacknowledged, they're unmanaged. The team experiences the pull without having language for it. Corrections target the visible symptom, not the actual force.
Three principles follow from the eight-vector model:
All vectors are equal. Mindless doing (D-drift) is not better than planning paralysis (P-drift). Both pull the execution frame away from intent. A team shipping fast in the wrong direction is not performing better than a team that has stalled.
Detection from inside is impossible. At sufficient drift depth, new information gets interpreted through the drifted frame rather than correcting it. The data that should trigger recovery gets explained away. This isn't resistance — it's how drifted frames work. The frame that would do the detecting is the same frame that has drifted.
Point of no return exists in each direction. Past a certain depth, the cost of recovery exceeds the cost of abandonment or restart. Catching drift early isn't just efficient — it's the only reliable recovery mechanism.
The Iteration Loop
If drift is physics, you design with it. The iteration loop is the structural answer.
┌─────────────────────────────────────────┐ │ │ │ Execute │ │ ↓ │ │ Snapshot (frame anchor) │ │ ↓ │ │ Compare N vs N-1 │ │ ↓ │ │ Drift visible? │ │ ↓ ↓ │ │ YES NO │ │ ↓ ↓ │ │ Which vector? Continue │ │ ↓ │ │ Intervene at depth │ │ ↓ │ │ Execute │ │ │ └─────────────────────────────────────────┘
Each cycle: execute, snapshot, compare, detect, name the vector, intervene at the right depth.
The snapshot is the mechanism. Not memory — a written artifact capturing current understanding, what was actually done, what's uncertain. Compare it against the previous snapshot. Drift invisible from inside the frame becomes visible in the diff.
Naming the vector matters. "We're drifting" is not actionable. "We're in D-drift — shipping without checking against original intent" is. "This is Fear-drift — the delays are about exposure, not quality" is. The name points at the force, which points at the intervention.
Recovery depth matches drift depth. Light drift (single vector, recent) recovers from a redirect. Medium drift (multiple sessions, frame shifted) requires reprocessing — reloading original intent with accumulated experience, not starting over. Deep drift (frame locked, data being explained away) requires full reset: fresh context, original problem statement, accumulated decisions treated as constraints rather than frame.
Recovery as Rhythm
The most important reframe: recovery is not a sign something went wrong.
Traditional view: planning prevents drift, recovery signals failure, retrospectives are emergency response.
Research finding: drift is constant, recovery is the designed mechanism, retrospectives are the rhythm.
Every cycle drifts some amount. The question is how far before the next check. Monthly cycles with built-in reprocessing catch drift before it compounds. Quarterly planning with no mid-cycle check lets drift accumulate for twelve weeks before anyone compares current state against original intent.
The economics are simple. Catching D-drift at week two — "we're shipping the wrong thing" — costs one redirect conversation. Catching it at week ten — after the thing has been built, tested, and presented — costs a rebuild. The drift distance is the same. The recovery cost is not.
Same principle documented in AI coordination research: an AI that drifts in session one recovers in one exchange. The same drift detected in session six, after the frame has locked, requires a full context reset. Prevention didn't work either way. The cost was determined by when it was caught.
What to Watch For
Each vector has a tell — a behavioral signal that appears before the drift becomes expensive.
D-drift: Velocity looks good, but check-ins about original intent become rarer. Team answers "are we on track?" instead of "is this still the right thing to build?"
P-drift: Planning meetings multiply. Each one surfaces new dependencies. Launch dates keep moving right for reasonable reasons.
S-drift: Conversations shift to architecture and reusability before the core problem is solved. "We should build this as a platform" arrives before the first version ships.
C-drift: Scope conversations happen more with users than with strategy. Feature requests are being prioritized over original design intent.
Experience-drift: Pushback on approaches that differ from established patterns. "We've tried that before" and "this is the standard way" appearing frequently.
Owner-drift: Work that's visible to the owner gets done. Work that isn't visible doesn't. Team energy tracks sponsor attention rather than strategic priority.
Fear-drift: Review cycles lengthen. Sign-off requirements increase. "Just want to make sure" appearing as a prefix to delays.
Low-drift: Responses get shorter. Commitments get vaguer. Energy for the work drops while energy for adjacent work stays high.
None of these signals mean failure. They mean a specific force is operating at a detectable level. That's useful information. The frame anchor surfaces it before it compounds.
The Design Principle
Don't design coordination systems that try to prevent drift.
Design systems where:
- Drift is expected and named
- Snapshots make it visible before it compounds
- Recovery is built into rhythm, not triggered by crisis
- The intervention depth matches the drift depth
The goal isn't a team that never drifts. It's a team with a short drift cycle — catch early, recover cheap, reload intent, continue.
Eight vectors. All equal. All predictable. All catchable before the point of no return, if you're looking at the right data at the right intervals.
Go Deeper
Implementation tools, product management methodology, and research documentation.
Related Reading
- LLM Skills Repository — Point your AI to the framework GitHub repo
- Product Management — Applying drift control to product delivery
- Research Paper — The full research documentation