The Operating Guide

Get three homes in place before your first climb: a story map the whole team can edit (we use storymaps.io), a work tracker whose states are your gates, with the spec living in the ticket body, one ticket per self-contained unit of work (we use Linear), and an agent-orchestration layer that can run scoped work async (we use iloom.ai driving Claude and Gemini). The functions are the requirement; the brands are our worked example. That’s the whole stack — don’t add more until something actually hurts.

Set up your Linear states to mirror the gates, not the old workflow. You want states that say where on the climb a piece is: Mapped, Shaped, Specced, Drafting, Reckoning, Shipping, Live. The state is the gate. Moving a ticket forward is a deliberate act, never automatic.

“What has to exist first” in the article is the principle; this is what it cashes out to for us. Everything runs on Node and TypeScript, end to end, so the same people can move across the whole stack without switching languages mid-climb.

Supabase is the database and auth. Vercel hosts it and gives us a preview build on every branch, which is the thing that makes “let’s just see it” cheap. Linear holds the work, Slack is where we talk, and Claude is the agent we build with. That’s the base camp, and it was standing before any of the climbs in this guide made sense.

Speed doesn’t cancel testing. We still write unit tests for the logic that matters, and Playwright drives the end-to-end checks against the running app, so a build we throw away in Reckon never takes the safety net with it.

Start every climb at the map, even small ones. The discipline of stating the problem as stories before touching code is what keeps you from building the wrong thing fast. Ten minutes here saves a plateau later.

In Explore, set a hard timebox and a hard option count. “Three to five directions, one afternoon.” Without the cap, exploration becomes a sinkhole and the whole point (cheap, fast, disposable) erodes. The cap is what keeps it disposable.

In Breakdown, write tickets that are buildable from the ticket alone. The test: could a competent stranger build this with no other context? If the ticket needs a meeting to explain, it’s not done. Vague tickets are where whoever picks them up has to guess, and guessing surfaces in QA at the worst time.

In the Plateau Loop, build the skeleton first, always. The instinct to perfect one screen before the next exists is the old expensive-build instinct. Get the whole thing running rough, then refine where it bites. You learn more from a running mess than a polished fragment.

Reckon is a real meeting with a real decision, not a status check. Put the running build on a screen. Ask one question: is this close enough to climb on, or did we learn enough to do it right from scratch? Say the answer out loud. “We’re rebuilding this” is a normal, healthy sentence. A team that never rebuilds isn’t disciplined, it’s sunk-cost.

The failure mode of speed is leakage. Build these habits or the climb diverges from what’s recorded.

Capture in the moment, always. A story surfaces mid-build, it goes into the map or a ticket before you climb on. Not after standup, not “I’ll remember it.” The three seconds it takes to log it is the cheapest insurance you’ll ever buy.

Make pulling someone in a logged act. A Linear mention or a thread tied to the ticket, never a hallway ask or a DM that dies in someone’s inbox. The record is what lets the person arrive with context instead of needing a meeting to catch up.

Treat every gate as a drift check. When a ticket clears a gate, confirm the work still matches what everyone thinks it is. The gate isn’t just quality, it’s the moment you catch the climb wandering off the map.

Default to async. Synchronous time is reserved and rare, because “pull in anyone at any altitude” only works if it doesn’t require everyone to be awake at once.

Only two meetings are genuinely worth gathering for: Shape (deciding the direction live) and Reckon (the keep-or-rebuild call). Both are judgment, not status. Everything else runs in threads tied to the work.

Kill the daily standup. The work tells you its status through the Linear states. A meeting to recite what the board already shows is the relay’s ghost. If someone needs status, they look; they don’t convene.

The test of whether your async is working: someone takes a day off and the climb doesn’t stall. If it does, something important was trapped in a synchronous moment, and that’s the thing to fix.

Recreating sprints with new words. If your week has a planning meeting, a daily standup, and a retro, you’re running Scrum in a Switchback costume.

Skipping the map because the work “seems obvious.” Obvious work is the easiest to build in the wrong direction. The map is cheap; build it.

Treating throwaway as failure. The wireframes you discard in Explore and the Draft you rebuild in Reckon were never waste. They were the cheapest way to learn. Mourning them is the old expensive-build instinct talking.

Hoarding the pen. If one discipline insists on owning a step, the blur breaks and the relay creeps back. Pull in who the climb needs, then let go.

Product → story → project → task → subtask, and the phase that owns each level. The warm thread is the trace back to the story.

One map per product, not per feature. The backbone is the top row: the user’s journey as verb-first activities (“plan a flight,” “review performance”), five to nine across for a whole product. Under each activity sit its steps, and under each step hang the stories, ordered by priority. Horizontal slices cut the map into climbs: the MVP line first, then a slice per climb after it. The backbone is the part that almost never changes; the stories under it churn constantly, and that’s the map working.

Every story is one sentence in problem language:

. No solutions, no screens, no field lists — the moment a story says “dropdown,” someone picked a path before seeing the options. If a story can’t be said in one sentence, it’s an activity that needs splitting, not a longer card.

A story is always in exactly one of three states, and the map shows all three at a glance: mapped (it exists, nothing’s committed), in flight (it exported to Linear at Breakdown and carries a link to its tickets), and live (its tickets cleared Release and the map says so). The map holds the shape and the altitude; Linear holds the detail. Never the reverse.

Tag every story that arrived mid-climb — surfaced by a switchback rather than planned at a mapping session. The tag costs nothing and buys you the most honest metric this method has: how much of the map the climbing discovered.

One Linear project per climb, opened at Shape when the direction is picked. Every ticket inside it is one self-contained unit of work from Breakdown, and every ticket has the same four-part anatomy: the story reference back to the map, the spec in the body (what, contracts, states, acceptance criteria, out of scope), a running switchback log, and links — branch, preview URL, PR. A ticket missing one of the four isn’t done being created.

The switchback log is the part the old workflow never had: a dated, one-line entry for every turn the work took. What surfaced, where it was routed, what changed. Six months later the ticket reads like a flight recorder — not just what got built, but every fork on the way and why the climb went the way it did.

Four labels carry the taxonomy: substrate (it outlives the climb), throwaway (it won’t, on purpose), switchback (this work arrived mid-climb), and base-camp (equipment, not product). Label at creation; they’re how you later ask “what did this climb leave behind” and get an answer from a filter instead of an archaeology project.

Two acts are always deliberate and always leave a comment: clearing a gate (“Gate: spec reviewed — passed, two criteria tightened”) and pulling someone in (an @-mention with the trigger and the ask, so they arrive with context instead of needing a meeting). Everything else on the ticket can be automated; these two are signatures.

Slack is the campfire, not the filing cabinet. State lives in the map and in Linear; Slack carries the conversation and the echoes of state, and nothing that matters is allowed to exist only there. The standing rule: if a decision happens in a thread, it gets written back to the ticket — by the automation when one is watching, by the human who made the call when not.

Four channels cover the whole method. Not per-discipline channels — that’s the relay’s org chart sneaking back in as a sidebar — and not per-ticket channels, because the ticket already has a home. Channels follow the trail, not the team.

One rule governs all of it: automate the echo, never the judgment. Automations move records between homes; humans move work through gates. The moment a bot advances a ticket past a gate, the gate has stopped being a check and the drift detector is off.

Run that rule over the whole climb and the lattice falls out — every moment that used to need a standup, a status ping, or someone remembering to write something down:

Three layers carry the eight, and all three ship in the Switchback SDK. Native integrations and plain CI steps carry the pure echoes — gate states, previews pinned by the no-agent preview-trail workflow. The skills carry the in-session trails: /switchback and /gate write their own log lines through the Linear and Slack integrations when they run. And the headless routines carry the scheduled record-keeping — the Reckon brief, the morning digest, the stale-trail sweep, and release notes — each run by a GitHub Action on cron. None of the three ever moves a ticket through a gate.

The numbers to hold yourself to

The signals above are felt; these are measured, and they’re what you report upward. Three is enough:

Time from map to first plateau. The whole economic argument lives in this number. Target: under a week by day 60. If it isn’t falling, the base camp is missing, not the discipline.

How much of the climb survives someone being offline. The async test, made countable: a day off should cost the climb nothing. Every stall traces to something trapped in a synchronous moment — find it, free it, count again.

Rebuild rate at Reckon. The healthy band is some-but-not-most. Zero rebuilds means sunk-cost thinking survived the transition; mostly rebuilds means Discover or Breakdown is running too thin. Either edge of the band points at the exact phase to fix.

If none of the three has moved by day 90, stop and ask the honest question: did the base camp — previews, safe migrations, a component system, solved scaffolding — actually exist before you started the clock?