Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience.

Basic truths vs. specific practices

To apply Shape Up to your company, it helps to separate out the basic truths from the specific practices.

Work has to come from somewhere, and it takes work to figure out what the right work is. This is shaping. Shaping the work sets clearer boundaries and expectations for whoever does the work—whether that’s a separate team or just your future self. If we don’t make trade-offs up front by shaping, the universe will force us to make trade-offs later in a mad rush when we’re confronted by deadlines, technical limitations, or resource constraints.

The same is true with betting. Six weeks might not be the exact time frame for your team. But the consequences of making unclear or open-ended commitments are the same for everyone. Regardless of the specific time frame we bet on, we should be deliberate about what we bet on and cap our downside with a circuit breaker.

In the building phase, there will be unknowns to deal with whether you track them on a hill chart or not. We need to distinguish the knowns from the unknowns so we can sequence the work in the right order and reserve capacity for the unknowns.

These truths apply regardless of the size of your organization. The specific practices, on the other hand, are scale-dependent. Let’s have a look at what it means to implement Shape Up at a very small start-up and an organization that’s grown big enough for specialized roles and more structure.

Small enough to wing it

When your team is just two or three people, everybody does a bit of everything. Since a few people are wearing many hats and performing many roles, it’s difficult to commit long chunks of uninterrupted time to specific projects. The person doing the programming might also be answering customer requests and dealing with an infrastructure issue all at the same time.

It’s also easier to communicate and change course when you’re small. You can drop something in the group chat or talk about it in person and everyone’s immediately on the same page.

For these reasons, a tiny team can throw out most of the structure. You don’t need to work six weeks at a time. You don’t need a cool-down period, formal pitches or a betting table. Instead of parallel tracks with dedicated shapers and builders, the same people can alternate back and forth. Be deliberate about which hat you’re wearing and what phase you’re in. Set an appetite, shape what to do next, build it, then shape the next thing. Your bets might be different sizes each time: maybe two weeks here, three weeks there. You’re still shaping, betting, and building, but you’re doing it more fluidly without the rigid structure of cycles and cool-downs.

A diagram depicting how the work transforms through four phases. First the work is like a cloud with a question mark in it. It's labled: Raw idea or request. Then the work acquires a defined outline with an empty interior. It is labeled: Shaped pitch. A vertical dotted line separates the next phase, and an arrow curling over the dotted line is labeled: Betting. Then the defined outline gets some dotted line boundaries inside to indicate scopes. One of them is checked off. Finally the interior is fully divided by scopes with many of them complete.

The phases of the work still hold true even if you don’t work in cycles or have dedicated people to do the shaping and building

Big enough to specialize

After you hire more people, all of this fluidity flips from an asset to a liability. Winging it with ad-hoc meetings and chat room discussions doesn’t work anymore. Coordination starts to eat up more of your time and things begin to slip through the cracks.

This is when it makes sense to take on the structure of six-week cycles, cool-downs, and a formal betting table. With more people available to build, someone needs to carve out more time to do the work of figuring out what to build. This could mean a founder spends more time shaping than building, or it could mean elevating an employee from doing in-cycle design work to more out-of-cycle shaping work.

At Basecamp’s current size (about 50 people in the whole company, roughly a dozen in the product team) we’ve been able to specialize roles so teams of designers and programmers can work without any interruption in the cycles. A dedicated team called SIP (Security, Infrastructure, and Performance) handles technical work that’s lower in the stack and more structural. Our Ops team keeps the lights on. We have technical people on the Support team who can investigate problems raised by customers. All this means that we don’t need to interrupt the designers and programmers on our Core Product team who work on shaped projects within the cycles.

With dedicated shapers and builders, the picture is more structured. Shapers work on an “out of cycle” track. Cool-down between cycles gives everyone room to fix bugs and address loose ends that pop up. The betting table is held during cool-down and then bets are placed for the next cycle.

Diagram depicting the two tracks and what happens at the same time. A horizontal dotted line marks the boundary between the two tracks. The upper track is labeled: Out of cycle and the lower track is labled: In cycle. The tracks are sliced vertically by blocks of time: a six week block followed by a two week block, then another six week block and so on. Arrows point from a box marked Shape in the six week block on the out-of-cycle track over to a Bet box in the two-week block. An arrow from the Bet box descends down to the lower track and points to a Build box in the following six week block. Between build blocks, the two-week gap is labeled: Cool down.

With more people, shaping and building happen on separate tracks and bets are made to fill six-week cycles

We built Basecamp to execute the techniques in this book. It puts all our project communication, task management, and documentation in one place where designers and programmers work seamlessly together. See How to Implement the Shape Up Method in Basecamp.