How we structure our work and teams at Basecamp

Six weeks • One cycle

An inside look at the specifics of how we decide what to do and then decide how to do it.

“How do you guys actually work? How do you choose what to do? How big are your teams? How do you structure the work itself” are questions I get all the time. I’ve been sharing the details in small group workshops and 1 on 1, but figured it was time to write something up so we can share it at large.

We landed on this process after a decade of refinement. Just like we’re always iterating on our product work, we’re also always iterating on how our company works. We consider our company a product too. When you begin to think of your company like a product, you can begin to improve it in entirely new ways. I feel like we’re on version 5.2 of “how we work”.

Let’s get into it:

We work in six week cycles

Roughly every six weeks we start a new cycle of product work. Each six week work cycle contains two type of projects:

• Big Batch: Big Batch projects are big features or stuff that’s probably going to take up the full six weeks to get done. We typically take on one or two Big Batch projects in a six week cycle.
• Small Batch: Small Batch projects are smaller things, tweaks, minor adjustments, and easy adds that should take anywhere from a day to two weeks to complete. We typically take on between 4 and 8 Small Batch projects in a six week cycle.

To give you a sense of what kind of projects might fit into Big and Small, here’s an actual internal post announcing a cycle’s worth of work.

Once a six week cycle is over, we take one or two weeks off of scheduled projects so everyone can roam independently, fix stuff up, pick up some pet projects we’ve wanted to do, and generally wind down prior to starting the next six week cycle. Ample time for context switching. We also use this time to firm up ideas that we’ll be tackling next cycle. More on this in a bit.

Note: These are not sprints. I despise the word sprints. Sprints and work don’t go together. This isn’t about running all out as fast as you can, it’s about working calmly, at a nice pace, and making smart calls along the way. No brute force here, no catching our collective breath at the end.

Six weeks… What if something’s so huge it’s going to take longer?

We believe there’s a great six week version of nearly everything. Occasionally some things fall outside of this limit — deep R&D projects, brand new tech we’ve never used before, etc. But we’ve come to discover that nearly everything important can be done in six weeks or less. And done well.

The secret to making this possible is something we call scope hammering. We take the chisel to the big block of marble and figuring out how to sculpt, nip, and tuck a feature into the best six-week version possible. It’s all about looking carefully at a feature and figuring out the true essence. Not what can it be, but what does it need to be?

Before any project is included in a cycle, we’ve already figured out what we think the six week version is. We don’t include planning in the cycle time — all the planning and consideration happens in the pitch. It has to happen before the work is slated to be done by a team. That way the six weeks is all implementation and execution. No time is spent on big unknowns — we try to make sure all the big stuff is known enough before we get started.

Who does the work?

Each Big Batch project is assigned a team. So if we take on two Big Batch projects during a cycle, we’d have one team working on one of the projects and another team working on the other project. Small Batch projects are all done by one team. Teams stay together for the full cycle.

A team is two or three people, depending on the type of work. Either one programmer and one designer, or two programmers and one designer. That’s it. No teams of four, five, six. Everything we take on has to be done by a team of three, max.

We think three is the ideal size for most things — complexity begins to increase exponentially beyond that.

Teams are assembled ad-hoc. Before a cycle begins, we ask each person what kind of work they’d like to do over the next six weeks. Teams either coalesce around areas of interest, or we assign people to a team based on their preferences. Teams often change up after the cycle so everyone gets a chance to work with different people, but sometimes they stick together for a few cycles. There are no hard and fast rules about this.

Do we have dedicated project managers?

No. The designer on the team leads the project, but there’s a very close working relationship between designer and programmer(s). They work together on everything.

No matter the role, everyone tracks work in the same place, communicates in the same place, etc. For us that place is Basecamp 3. When everything’s in one place, everyone knows where things are, where things stand, and everyone can be self-sufficient. Splitting work and communication and management across separate tools/products is 1. a highly inefficient, and 2. makes it very difficult for the whole team to see the whole picture.

Do we track time?

No. We don’t measure efficiency, compare actuals vs. estimates. We have six weeks to get something done. However a team decides to get it done during that time is up to them.

What is important is that we don’t run up to the end and figure out we’re out of time. We’re always looking at what’s done, what’s left, and how much time remains. Scope is ever changing — adjusting down if we’re running low on time, or ramping up if we find we have more time than we thought. It’s a negotiation. It’s a very fluid process. What isn’t fluid is the deadline — six weeks from when we started.

Where do ideas come from?

We don’t have distinct time set aside to come up with ideas. There’s not a distinct set of people who come up with all the ideas. Ideas come from all over, and are offered up any time. They come from us, they come from customers. Ideas are always in motion. There’s always a bubbling ocean of ideas. Every once in a while a bubble floats out of the ocean and lands on the shore. That’s when we begin to take a closer look.

Pitching an idea

When an idea feels formed enough, it’s turned into a pitch. A pitch is a fully-formed definition of the problem as well as a proposed solution.

Here’s an actual example of a pitch so you can see the general form they take. We don’t pitch in person — we always write up pitches and post them to Basecamp for review.

Why don’t we pitch in person? For a few reasons:

1. We feel it’s better to write something up completely. This forces the floor — the person who’s making the pitch can’t be interrupted. They are guaranteed to be able to present their story completely, exactly as they wanted.
2. Further, we believe writing things out makes you consider them at a deeper level.
3. We’re big believers in asynchronous communication — write it down now and other people can absorb it later when they’re ready. Real-time communication in person or virtually forces synchronization of schedules which is highly inefficient.
4. And last, when it’s posted to Basecamp as a message, all feedback and follow up questions are automatically attached to the original post. This keeps all communication about the pitch centralized in one place on one page so everyone has access to the same story. One version of the truth.

How do you decide which projects to take on?

Everyone’s curious about this. The honest truth is that more art than science. Ideas come from everywhere, but ultimately the decision about what makes it into a cycle comes down to me (ceo), David (cto), and Ryan (strategy). A week or so prior to the cycle start, we review all the pitches posted to Basecamp, share some of our own ideas as well, and often vigorously debate the options. And then we’ll often have a call (Skype or Hangout) for 30 minutes, debate some more, and make the final decisions.

What makes the cut depends on many variables — how complete the pitches were, where customers are feeling pain, where we have new ideas we want to try, where stuff feels janky and needs revisiting, business cases we’re trying to make, etc. But whatever the decisions, the good news is that in six weeks we can start all over again with another batch of work. So if something doesn’t make it in, it can be considered again in just about a month and a half.

How does the cycle get announced?

Once the cycle has been defined, and work grouped into Big Batch and Small Batch projects, I write up an announcement and post it to the “Building BC3” project inside Basecamp. The Building BC3 project is the master project for high level Basecamp-related product work. It’s where we talk big picture items, share pitches, discuss ideas, schedule the cycles, etc. Here’s a sample cycle announcement (it’s the same one I linked up earlier, but here it is again if you missed it).

How is the actual work organized?

Each Big Batch project gets its own Basecamp project. Here’s an example of the Templates project that was a Big Batch project. Note: Blackburn is the name of the cycle (we name the cycles after mountains)…

Every task, discussion, comment, announcement, deadline, note, and chat about Templates happens in this one project.

And all the Small Batch projects for a cycle live in a single project. Here’s an example of the Small Batches from the Blackburn cycle:

Each Small Batch project is managed on a single to-do list. Here are the four Small Batch projects for Blackburn cycle:

Every design task, programming task, and QA item lives on a single to-do list that’s named after the feature we’re working on. This way the whole team — no matter what the role — knows where things stand.

How does QA work?

There are two people on our QA team: Ann and Michael. They roam between ongoing projects, invited in by the teams when they want something checked and double checked. We’ve found that the earlier they’re involved the better. QA fits into the six week time frame too, so nothing busts a deadline like a pile of last minute QA findings. That’s why we don’t wait until the end to start QA. Most of the time at least.

How are you and David involved?

David and I (Jason) are involved at some level in nearly every customer-facing project and product update.

I work with the designers to explore ideas early and then help refine and simplify things as we go. I’m also working with the designers on copywriting — making sure the words we’re using make sense. Design reviews aren’t critiques, they are problem solving sessions.

David helps the programmers figure out the plan of attack — thinking through the models, maintaining our focus on performance and speed, and negotiating technical compromises that make six week time frames possible.

As mentioned, we’re also both involved in the product planning stage — pitching ideas and figuring out what work makes a given cycle. We work closely with Ryan to think through each feature and look at the product holistically to figure out what makes sense where and when.

There’s more to it, of course…

I’ve tried to outline the major pieces, but I’m sure there are gaps. Of course there are gaps — product work has a lot of it depends moments. But hopefully there’s enough here to give you a basic sense of how things are set up around here at Basecamp.

If you have specific questions, or want to hear about something related that I didn’t cover above, drop a comment and we’ll do our best to fill in the blanks. Thanks for reading — I know it was a long one!