How we organize our work — Shape Up

The setup

2 years ago, we had 3 fresh new engineers in our tech team (5 in total), and at last, a real product manager who helped us square things up. We started planning sprints again, feeling good about the new process.

But things started feeling off. As a founder I was used to having a lot of freedom in how I planned my work, and I was used to owning the whole development flow, from design to implementation and deployment.

Now we were spending a lot of time in retrospective meetings, in planning sessions, splitting hairs trying to estimate points for user stories. It was a lot of work for our product manager to write these detailed specs and user stories for everyone, and it was not even pleasant for the tech team.

I felt that this way of working was mostly holding back the best people in the team and helping mostly the more junior people.

We were processing ticket after ticket and hoping that the end of the sprint would bring the whole epic together. What happened is that we ended up in integration hell and the parts developed in isolation did not fit together so well. It felt more like a mini-waterfall than an agile process.

There was no ownership in the tech team; every person was responsible for a small part of a feature, and then we tried to glue it all together.

With the team growing, things were only going to get worse if we continued on the same path. So I started looking around to see if there was another way of doing things, and I found Shape Up.

Shape Up

The tagline for the Shape Up book is “Stop Running in Circles and Ship Work that Matters”.

The basic idea is the following:

• New features are described in “pitches” where a pitch is a short document outlining the problem we are solving, why it matters, and what we intend to build to solve it. The specification of what we’re building is voluntarily light on details; it’s more precise than an idea but less than a full mockup.
• The development cycle is 8 weeks long, split into 2 parts: 6 weeks working on pitches, and 2 weeks of “cool-down” where the tech team can spend time working on technical improvements. The idea is that 6 weeks is long enough to tackle important work but short enough that you can feel the deadline. (Intercom also has a good article on why 6 weeks is a good cycle time)
• One or two devs work on a single pitch (“big batch”) or a few pitches (“small batch”) together during the cycle.
• A small team of core people writes the pitches (mainly the product manager in our case).
• Before the beginning of every cycle, we have a meeting called the “Betting table” where the co-founders and heads of all departments choose together which pitches will be selected for the upcoming cycle.

Dhinesh and Arthur hard at work on their pitch

Starting out

Once a few of us in the team had read a few articles and the Shape Up book, we were convinced that we could try it out for real. We shared some resources with the whole team, took time to explain what we were going to try and why. We wrote enough pitches to have a first full cycle, and we held the first betting table.

The first thing we gained from holding the betting table meeting is that it aligned the whole company on what we were building in the product. No more trying to add a “small feature” at the last minute to sign a customer.

What went well

Things went pretty smoothly from the start, and everyone felt a lot more productive. The product team had a lot more time to spend on discovery, the engineers could concentrate on one subject at a time.

There is a lot more ownership in the tech team. The goal is to solve the user’s problem during the cycle, and the pitch can and should be challenged to make sure we reach this goal.

During the past 2 years, the product + engineering team grew to about 25 people split in 4 teams and the method scaled nicely.

Adapting the method to our needs

Unlike Basecamp, we don’t serve only small businesses on the same pricing, and we have a high-touch sales cycle. In many ways the Basecamp model is closer to B2C; they can choose to ignore some of their customers much more easily. Our customers range from independent truckers to enterprise companies with thousands of users, so we had to adapt the method to our needs.

• The main thing we didn’t keep from the book was the idea to only fix bugs during the cool-down. We have a product that is critical for our users and most of the time we can’t wait a few weeks to fix a bug. At first, we had the whole team dedicated every Tuesday and Thursday morning to bug fixing. We found that this was not great in terms of focus (one of the main goals of Shape Up) so we’re now experimenting with a “Delight team”. The Delight team’s goal is to fix bugs and implement small features that can be blocking the onboarding of new customers, and generally help unblock the ops team any way they can.
• At first we tried not to commit to a roadmap, then we added an “orientation meeting” in the middle of the cycle to give visibility in advance to the rest of the team, and finally as we pivoted our product to a full transport management platform we returned to a roadmap as the objectives for the next ~6 months are very clear.
• We create one Slack channel per pitch, where the engineering, product, and customer success can talk about ongoing work on the feature.
• We do not use hill charts to communicate progress. More generally, each team can choose to organize their work how they see fit. Some hold daily standups, some only have a weekly meeting, some use Notion to track their work, some use Linear…

Still figuring it out

After each cycle we hold a retrospective and change our workflow to better fit our needs. As the team grows, new challenges arise and we have to keep updating the way we work.