Review of Shape Up Stop Running in Circles and Ship Work that Matters: Key Insights

By Sofia M.

- 3 minutes read - 558 words

Not long ago, I finished reading Shape Up Stop Running in Circles and Ship Work that Matters by Ryan Singer.

The book teaches how to shape work and run projects effectively. I like that the book is full of concrete examples showing how 37signals works on real projects. It’s enjoyable to read because you can see how things actually happened. It’s not too long and not overly detailed.

I want to share some of the concepts described in the book that I liked.

Shaping the work before starting something new

A small, qualified group prepares the concept first and then presents it to the team. The concept should include rough sketches, clear descriptions, and a time boundary – how much effort is worth putting into this project - so the team knows what needs to be done. Presenting a well-shaped concept helps avoid the risks of rough, unclear ideas - for example, misunderstanding priorities - and sets more realistic expectations.

Keeping the shaping group small makes the process faster, but it’s crucial that the people in this group are experienced enough for the task. They should have both technical and business knowledge to shape the project effectively.

The correct level of abstraction

The shaped work should be clear and understandable, without sending people down rabbit holes. If it’s too abstract, it can create misunderstandings or lead to wasted effort. On the other hand, a description that is too detailed is also not ideal. The level of abstraction should give the flexibility for experts who are actually working on the thing to choose the best solution. There should be space for reasonable compromises.

Six-week cycle

Instead of two-week sprints, they suggest using a six-week cycle for one ‘project’. This timeframe is long enough to create something meaningful and complete. I like this idea because such a cycle is long enough to produce meaningful work, unlike two-week sprints, but, at the same time, it’s short enough that you see the end of the cycle clearly from the first day. I think it would be really interesting to try.

Developer’s responsibility

Developers are fully responsible for their own work. While processes such as code reviews by colleagues and QA testing can be part of the workflow, they are not mandatory. Code reviews serve mainly as an opportunity for learning and knowledge sharing, rather than as a way to catch mistakes. QA should primarily focus on uncovering edge cases. The developer remains responsible for delivering a high-quality feature without shifting this responsibility to others.

Do small finished chunks

This is about breaking tasks into smaller pieces. Ideally, you don’t split them into backend and frontend parts, but instead cut them like a birthday cake - so that each slice is complete and changes can be used right away. This approach helps developers see results early, which builds confidence in their work. It’s also nice for potential clients to see progress as soon as possible, as it shows them that the project is moving forward.

I would definitely recommend the book to everyone - not just to people who manage others, but also to anyone working on anything feeling they need to improve their process. After all, everyone manages their own work, and even if you don’t learn anything entirely new from the book, it’s nice to be reminded of some important rules.