Basecamp’s two-person teams

Jason Fried (of Basecamp and HEY) posted recently about why they use teams of two.

No feature takes more than 6 weeks to build, and each feature is assigned a maximum of two people: one designer and one programmer.

(Worth noting that designers at Basecamp are also expected to do some frontend development too.)

I’m a fan of a lot of Basecamp’s ideas and books. But they do have a habit of acting like they discovered fire when they’re talking about commonly used ideas. What they’re describing is what I call stage two of the five stage of team focus: “Stage 2: Nobody works alone. Every workstream has at least two people on it.” This isn’t a new concept.

They call it a “team” but I don’t think the word “team” means what Basecamp thinks it means. They aren’t putting two people together and keeping them together through multiple features over months/years. They combine them for the life of a six week workstream and then split them up. That doesn’t sound like much of a team. That’s just an epic with two assignees.

---

Anyways, moving on from the whole “we discovered pairing, we are literally gods” thing, let’s talk about their beef with teams of more than two:

Two person teams simply can’t be beat. Want to do more than two people can do? Add another two person team to to the mix on something else. That’s what you do.

Don’t add them to what you’re doing, add them to something you aren’t. Four people making progress on two different features at the same time, rather than four people struggling to deliver one thing on time.

I don’t hate that. I at least agree with the spirit of it. The book Joy, Inc. is basically all about that way of working (although in their case it’s mostly in-person) and it was compelling.

I especially like this part:

If it takes more than two people, it can’t. We won’t let it. We’ll clear it up, simplify it down, make more tradeoffs, find more elegance. If it can’t fit into two, it’s not ready to do.

It’s a forcing function to keep scope lean and ship early and often. You literally can’t have a long slog of a project. You have to create small value-adding milestones or else you can’t do the thing at all.

But all that said, I have some qualms:

• Loneliness: If your partner goes on PTO, gets sick, or runs an errand, then you’re all alone.
• Learning: Hard to learn from your team when only teammate has a totally different job role.
• Code review: Either your code doesn’t get reviewed at all, or someone without context reviews it.
• Quality: The best architectures usually aren’t created by a single programmer, and architecture reviews with cross-team folks can only get you so far.
• Planning: Most companies have teams do planning. Basecamp does planning before the work hits the teams. So this would be a fundamental shift that would be tough to many cultures to absorb.

Those feel like dealbreakers unless there are some genius processes in place to make them non-issues. And they would be at least partially solved in a team with two programmers and one designer.

I like small teams. I believe that a team should usually follow single piece flow. And small teams make that easier with less toe-stepping. But two people, each with different roles, which only lasts for 6 weeks? I’m not even sure if that can be called a team.

Add another one or two people and keep them together through multiple projects so they can jell. Then reduce those six weeks down to four to keep the forcing function for small, valuable milestones. That’ll still be lean and mean, but the qualms disappear.