How we structure our work and teams at Basecamp

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. 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.

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. When everything’s in one place, everyone knows where things are, where things stand, etc.

No. We don’t measure efficiency, compare actuals vs. estimates. We have six weeks to get something done. However, a team deciding 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.

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. 

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

• The person who’s making the pitch can’t be interrupted.
• Further, we believe writing things out makes you consider them at a deeper level. 
• Real-time communication forces synchronization of schedules.
• All feedback and follow up questions are automatically attached to the original post. This keeps all communication about the pitch centralized in one place.

Ceo, David and Ryan make the decision about what makes it into a cycle. What makes the cut depends on many variables. If something doesn't make it in, it can be considered again in about a month and a half. The good news: in six weeks we can start all over again with another batch of work.

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.

There are two people on our QA team. 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.