We work in 6-week or 8-week cycles at Basecamp. There are typically six cycles to a year. Two are 8-week cycles, during Summer Hours, and the rest 6-week cycles. This fixed cadence serves to give us an internal sense of urgency, work as a scope hammer to keep projects from ballooning, and provide a regular interval to decide what we’re working on.
The idea is not that everything we ever decide to work on has to take six or eight weeks or can be completed in that time. But rather that we think about how we can break big projects into smaller ones that can be done in that amount of time, and that we bundle smaller things into a presentable scope of work that can be discussed.
This is particularly important for the product teams. Here we like to designate the work we take on with the scope in mind up front. We think of a small feature as a 1-weeker or a big feature as a 6-weeker (or anything in between). This designation helps us avoid a 1-weeker snowballing into a 4-weeker, just because people keep piling on more scope. Work is thus limited by a budget, and the budget focuses our discussion about what’s reasonable and what’s not. When a project starts slipping on its budget, the first approach should be to judo the problem and scope hammer the domain – and certainly not make it up by working more hours! Most things we work on can fit within six normal weeks or eight summer weeks.
In between each cycle, we spend two weeks cooling down. That’s the time to deal with various backlogs or bug smashes, writing up what we worked on, and figuring out what we should tackle next. It’s some times tempting to simply add cooldown onto the end of the cycles, as a way to fit in more work. But the goal is to resist this temptation. Yes, sometimes a little spill-over will happen, but it’s helpful to think about the end of the normal cycle as “pencils down”. That means that by week 4 of a normal cycle, we should be winding down, getting ready to launch, make sure QA is lined up, and all the other work that happens during and after the launch of new projects.
It’s hard to keep up on what everyone is doing and what it means, if you just watch the stream of latest activity scrolling along in Basecamp. (It’s also a waste of time and source of stress to even try.) Instead, we have four chief mechanisms for keeping everyone in the loop about the work that’s going on.
First, there’s the daily question of What did you work on today?, which supplies the nitty gritty details, but as a personal narrative. They’re a great conversation starter if you see someone working on something you either care about or want to learn more about. Please do use them as such! You’re obliged to answer this question at least twice a week when you’re not out (or on team OMG).
Second, there’s the weekly question of What will you be working on this week?, which details your intentions for the coming week. Everyone except team OMG is obliged to answer this question when they’re not out.
Third, there is the heartbeats. These are the team versions of What did you work on this cycle? This is where we summarize and celebrate the work that’s been done. Every team lead is obliged to write, or designate someone on the team to write, this account one week after a cycle has ended.
Fourth, and finally, there is the kickoffs. These are the team version of What are you going to work on next cycle? This is where the plan for the coming six or eight weeks is presented. Every team lead is obliged to write, or designate someone on the team to write, this account before the start of the new cycle (again, OMG exempt if there are no big new initiatives kicking off).
These mechanisms work together to free individuals and teams to run their days and cycles with confidence and independence. We have six opportunities per year to make big decisions about what to work on, and the rest of the time should chiefly be spent carrying out those short-term plans. By having clear expectations for communication, it’s easier for everyone to build trust in where we’re going and why.
All these questions and write-ups will be posted in the What Works project for the current year.
Whether you work on the product development or not, your voice and observations can help determine what we should be working on. The way to exert this influence is through pitches.
Write-up your idea of a new feature, a change to a feature, or any other product development you think we should be considering as a fully considered post (the more specific, the better). This gives the whole company a chance to consider and respond to the idea, and then we’ll have the idea encapsulated in a post, available for reference at any time.
There’ll always be more pitches than we have time to field, though. So it’s important to have realistic expectations about what will happen after you posted your pitch. The default is simply that everyone involved with product development (and probably most everyone else in the company) will read and consider your pitch. That’s a win right there. Even if the full pitch doesn’t make it in, it can impact other product decisions by shining light on a weak point.
While a few pitches might instantly strike a chord loud enough to go on the plate for the next cycle, it’s more likely that your pitch will sit for a while first. We’re always working from a backlog of ideas and we have just a few things we can do every cycle, so chances are that even if everyone agrees the pitch is a great idea, it might not be the next most important thing for us to tackle. Don’t be discouraged by this. We’ve had many pitches that have sat for many cycles, if not years, before finally coming together and then happening.
Jason, Ryan, and David is the team evaluating pitches for inclusion in the next cycle. Before the start of every cycle, Jason’s kickoff will list all the pitches that have been selected to be worked on.