The Focus Leak | Article 9: The Requirement Drift
Engineers are hired to build a specific architecture, but they are often forced to move the foundation while the concrete is still pouring. While the “Feedback Lag” (Article 8) is about waiting, Requirement Drift is about the mid-flight pivot that acts as a “Force Quit” for the brain.
The Problem: The “Force Quit”
In an OS, a “Force Quit” kills a process instantly without saving its state. When a requirement changes while an engineer is in the middle of a Maker Block, it does exactly that.
The brain has spent 90 minutes building a specific mental model of how data flows from Point A to Point B. If, at minute 91, the requirement changes to “Point A must now go to Point C,” the entire mental model becomes corrupted data. It cannot be “adjusted”; it must be deleted and rebuilt from scratch.
The Reality: Task Resistance
Frequent drift creates a psychological state called Task Resistance.
- The Logic: If an engineer knows the requirements might change tomorrow, they will subconsciously refuse to enter “Deep Flow” today.
- The Leak: They stay in “Shallow Mode,” writing “safe” (slow) code and checking Slack more often. Why build a high-performance engine if the manager might ask for a boat tomorrow?
The Reality: Changing a spec “mid-sprint” isn’t being “Agile”; it’s a “System Crash.”
The Patch: The “Locked State” Protocol
To stop the leak, the team must move from “Constant Pivot” to “Discrete Iteration.”
1. The “In Progress” Lock Once a ticket is moved to “In Progress,” the requirements are Read-Only. If a stakeholder realizes they missed a requirement, it cannot be added to the current task. It must be created as a new ticket for the nextcycle.
2. The Abort & Restart Rule If a requirement change is truly an emergency and cannot wait, the current task is not “edited”—it is Aborted. The engineer is told to stop, take a “System Cool Down” (a break), and start a fresh 20-minute warm-up the next morning with the new spec. This prevents the “mental ghosting” of the old logic from infecting the new logic.
3. The “Definition of Ready” Firewall A task cannot enter a Maker Block unless it is 100% defined. If there is a “we’ll figure that part out later” note in the ticket, the engine should not be started. Uncertain requirements are the leading cause of “Logic Smoke.”
Submit a Bug Report
How many tickets in your current sprint have had their description or “Acceptance Criteria” edited after work started? Each edit represents a Force Quit on an engineer’s brain.