The FitnessGram Pacer test is a multistage aerobic capacity test that progressively gets more difficult as it continues.

If someone told you that they're exhausted from running 421.94988 one hundred meter sprints, back to back, you might say that that's oddly specific and that it sounds like a marathon. You would be correct both literally and figuratively. This is not the first (or best) joke at the expense of Scrum's iteration structure, and it might be said that it willfully misrepresents how Scrum interprets the spirit of agile development. But most teams still take its "periods of work that last one month or less" to mean "one week sprints, forever" and most companies still have to run marathons and yet pause every block or so to wonder if they're heading the right way.

The complexity of a system only increases as it grows. This is true of communications, decision making, reporting structures, products, and technical architecture. Strategies that work well in small systems do poorly in larger ones and so must grow in complexity, too — a quick conversation between three founders becomes an hour long stakeholder discussion with laboriously prepared slides. This is also why adopting complex strategies from much larger systems tends to fail: they're not recognized as the best-alternative burden that they are and end up costing more than a small team can afford; I'm looking at you, microservices, five-stage interviews, and every other FAANG trend adopted by ~40 person orgs.

Have you ever initialized the first concept of a user in a new repository? Created the UX for a two-step sign-up process on a new product? Written the marketing campaign for a new tool that focuses on doing one thing really well? Have you ever worked to extend a system that has four connected products, two reporting tools, email and sms communications features, onboarding funnel drop-off retargeting, and three layers of stakeholders to work with? Delivering substantive value also becomes more difficult as a system grows.

Composition & Decomposition

The work to create the first integration into an email provider, and the work to add push notifications to a system that has multichannel communication preferences, compliance and privacy concerns, and a couple of observability dashboards to update, are both fun and interesting challenges. Both of these projects should be decomposed into small, knowable, workable tasks for execution. They should be time-bound to prevent over-investment. Whoever is tasked with the work should be trusted to make decisions and have the space to apply their creative expertise. They both benefit from discovery and focus.

They should not be composed in the same way. The former might fit entirely into one person's head and could be done within a one week sprint. The latter won't, and it probably doesn't really start to deliver value until it's mostly finished. This is not to say that the latter feature should be held separate, unmerged and increasing in technical risk, until it's finished. But it is to say that it's unhelpful to artificially pause every week or two in order to give folks the opportunity to change their mind on the value of a feature that's already been considered valuable enough for investment in discovery, planning, and the start of execution.

A fledgling organization maybe — maybe — needs the ability to change its mind every two weeks maybe. An established product requires the following:

• that context stick around in someone's head long enough to be set down among the varied complex concerns of a larger system
• that ongoing work won't leave a mess because it's been paused mid-flight
• that systemic changes to address related, mounting technical debt have time to be considered

Not every project requires six weeks to work from one end to the other, but more and more will as an organization grows.

The Castles in our Heads

On a team of five, in a young product, when most technical decisions are pretty easy, folks maintain enough day-to-day working context that their mental models might remain unperturbed by the organic growth of their company. Work can flow freely from one sprint to another, or even continuously in a kanban stream. But just as the delivery of value in a complex system is itself more complicated, a rigorous discovery and planning process becomes the necessity of a larger system. It's no mean feat to shape a project that will end up taking one or three folks' full attention for six weeks.

Dan, Harrison, and I have recently decided that we should start working in six week cycles for the time we spend directly on Go Between. You would be correct to say that this decision flies directly in the face of my earlier point about the trouble of adopting big tools for small jobs. For us, though, the cost of shaping work for ourselves is always worth it: as a focus for our part-time product hours; in the generation of planning artifacts that we can share with you fine folks; for the sense of accomplishment in setting and achieving a specific goal.

Late '24 is a busy time for Go Between: holidays, a new consulting client, and impending paternity leave will divide our focus a bit more than usual. We're nearing the end of our current audience building cycle and we'd like to get back to building, but we don't have a clear pitch for what, exactly, that should look like. Rather than risk flailing about through the end of the year without a clear goal, we're planning to spend the next six-ish weeks shaping work for our future selves to execute. More on that later — in the meantime, wish us luck. We've got a bucket to fill.

Thanks for your time and attention.