November 23
Sunday morning, preparing for our first alpha tester arriving Monday. Sprints reorganizing. Issues moving between epics. Priorities shifting.
In my session log: "Inchworm Position: 3.1.4.1"
That notation told me exactly where we were. Not vaguely "working on alpha prep." Precisely: the current rung in a nested work hierarchy, with explicit labels for each level:
(3) ALPHA foundation
(3.1) Initial alpha testing - v0.8.0
(3.1.4) Sprint A9 - final alpha prep
(3.1.4.1) Frontend permission awareness
The inchworm's current position on the branch.
The inchworm metaphor
An inchworm moves by anchoring its front, pulling its back forward, then anchoring its back and extending its front. One segment at a time. Slow but certain. Always knowing exactly where it is on the branch.
Project progress works the same way, especially when it hinges on the attention of one single human being (and there is always some subtrack of every project that does, for what it's worth). You can't be everywhere at once. You're at one specific position, working on one specific thing. The discipline is knowing exactly which thing, and having the whole branch mapped so you know what comes next.
The position notation captures this: where you are in the structure of work, not just what you're doing.
The exact numbering and order of subbranches changes all the time. It has to. This is not a waterfall tracking system. This is my equivalent of externalized "where were we?" memory in a form that I can manage with my linear attention, by walking the branches. The tree holds the complexity.
The anchoring discipline
The inchworm anchors before extending. In project terms: you don't advance your position until current position is complete.
This creates productive constraint. You can't be at position 3.1.4.1 while still having incomplete work at 3.3.2.6. The position asserts: everything before this is done.
Incomplete work at previous positions means you're lying about your position. The inchworm that extends without anchoring falls off the branch.
Sprint A9's intended order made this discipline explicit: frontend permission awareness first, then alpha docs, then production push, then user onboarding. Each move had to land before the next one could legitimately begin. Michelle could arrive as the first user only because the three preceding moves had landed first.
Position vs. status
Status meetings ask: "What's the status?"
Position thinking asks: "Where are you?"
Status is vague. "Making progress." "Almost done." "Working through some issues." Status can be true and useless.
Position is precise. "3.1.4.1." Either you're at that position or you're not. The notation forces honesty about where you actually are versus where you wish you were.
When someone asks position, the answer is coordinates. When someone asks status, the answer is narrative. Coordinates are verifiable. Narratives are not.
Mapping the branch
Position only works if the branch is mapped. You need to know what 3.1.4.1 means — what came before, what comes after, how the segments connect.
This requires upfront work. Before execution begins, map the branch:
- What are the major segments (sprints, phases)?
- What are the tasks within each segment?
- What are the subtasks within each task?
- What are the dependencies between positions?
The map might change — branches grow, get pruned, fork. But you update the map, you don't abandon position tracking.
Our Sunday morning included sprint reorganization. S1 closing (security foundation complete). A9 created (alpha final prep). The branch map changed, but we still knew our position on the new map.
The daily anchor
Each session starts with position check: "Where are we?" Most of the time I'd mention "we're on 3.1.4.1" or whatever. Occasionally I'll reshare the current state of the tree. I used to keep it outside the project in a Notes file, then adopted a Mac app called Bike that is pretty easy to use but pastes plain bullet lists. But that's just tooling. It could be on paper.
This is as much for me as it is for the bots.
Inchworm as ratchet
Interesting thing about inchworms: they're slow but they don't backtrack. Every position advance is permanent progress.
Teams that lose position tracking backtrack constantly. "Wait, did we finish that?" "I thought you were handling that part." "Wasn't that already done?"
Each backtrack costs time. Worse, each backtrack creates uncertainty about other positions. If we were wrong about 3.2.1, are we sure about 3.3.1?
The inchworm that knows its position doesn't backtrack. It doesn't wonder what's done — it knows what's done because it knows its position. Slow is smooth and smooth is fast.
The Monday anchor
Sunday evening, the frontend permission work — Sprint A9's first move — was complete. Michelle's account was provisioned and ready for her arrival in the morning.
Monday morning, Sprint A9 advanced to its onboarding move. First session with first alpha user.
That session didn't wonder "are we ready?" The completed-and-labeled position answered the question for us. We were ready because we were at the position that meant ready.
The inchworm had traversed the branch. Michelle logged in. The position tracking that seemed like overhead had created the certainty that enabled calm.
Next on Building Piper Morgan: Audit and Talk — the day an IAC talk on ethics-as-architecture and a CIO methodology audit converged.
How do you track project position? When has knowing exactly where you are enabled progress? What systems help you avoid position drift?