How we work · 3 min read
How we plan
Small batches, short cycles, and plans that survive contact with reality: cadence without ceremony.
Planning has a bad reputation, and mostly it's earned. Too many teams confuse planning with prediction: an elaborate up-front document that's obsolete the moment real work touches it, defended long past the point of usefulness because someone spent a week on it. We plan differently, and lightly, for the same reason we do most things here: the goal is to keep moving in the right direction, not to produce an artifact that looks like control.
Short cycles, small batches
We plan in short cycles, on the order of a couple of weeks, not quarters. A short horizon isn't a lack of ambition; it's a bet that we can't see clearly much further out than that, so committing in detail past it is just guessing with extra confidence.
Inside a cycle, the unit is a small batch: a piece of work you can hold in your head and carry to done in that window. If something won't fit, that's information. It means the work is too big and needs cutting into slices, not that the cycle is too short. This is the same instinct that runs through how we work: small things ship, stay reviewable, and keep us close to a working state.
Plans that survive contact with reality
A good plan is one you can afford to be wrong about. We write plans to be revised, not obeyed. When the work teaches us something the plan didn't know, the plan loses and we update it, out loud, without treating it as a failure.
That's why we keep plans short. A one-paragraph plan is cheap to change when reality argues back; a thirty-page one develops a gravity of its own, and people start defending the document instead of pursuing the outcome. The point of planning isn't the plan. It's the thinking the plan forced, and thinking is allowed to change its mind.
Re-planning is not failing
Changing the plan when the facts change is the plan working, not the plan breaking. The only real failure is following a plan you already know is wrong because changing it would feel like admitting something.
No sprint dogma
We borrow what's useful from how teams organize work and leave the rest. Short cycles: yes. A ritual for every occasion, points, velocity charts, a ceremony to plan the meeting about the planning: no. Every one of those exists to solve a problem, and if we don't have the problem, importing the ceremony just taxes us to look like a "real" team.
We stay suspicious of process that arrives by default. If a planning habit isn't paying for itself, we say so and drop it. Cadence should feel like a rhythm that helps you know what's next, not a set of hoops you clear on a schedule. When a ritual becomes the point instead of the work, it's gone.
Pacing over pressure
Pace matters more than speed. A team that sprints flat out burns down, ships worse, and can't sustain the one thing that actually compounds: showing up steadily, cycle after cycle, for a long time. We'd rather move at a pace we can hold indefinitely than spike and crash.
Practically, that means we don't overfill a cycle to look busy, and we leave slack for the things planning can't foresee: the bug that surfaces, the good idea that lands mid-cycle, the day someone just needs off. A plan packed to the last hour isn't ambitious, it's fragile, and it turns every surprise into a crisis.
How this connects to deciding
Planning and deciding are close cousins, and they follow the same rules. A plan is a stack of small decisions about what to do next and in what order, and like every decision here it has an owner, gets made in the open, and can be revisited when the facts change. For the mechanics of who decides and how, see decisions. Planning is just deciding, laid out over the next couple of weeks.