Skip to content

Reading Shape Up by Ryan Singer (Basecamp)

–

I've been a fan of the guys at Basecamp for a while, and read most of their books, so I'm thrilled get this one started.

It's also the first book I'll read in html! The only doubt I have is how I'll manage to take highlights as I usually do. We'll see.

Activity

Task started

I've already tracked the progress on reading some books in my website before: Musashi, Los Tónicos De La Voluntad and Digital Minimalism. But the truth is that after those I didn't think I'd do it anymore.

I've realized one of the reasons why I don't read as many books as I'd like to is friction, and I end up reading blog posts instead. This friction comes in many forms: Having to read a non-digital book, having to journal about it, having to take notes, having to read all of it, having to read it linearly, etc. Most of those are self-imposed, so I'll try a different approach. I've also been inspired to do this by listening to others' habits like Naval Ravikant and Doug Belshaw. In fact, I already started reading Emotional Intelligence by Dale Goleman without keeping track here (I even skipped some chapters!).

But that doesn't mean I don't see the value in journaling and all the things I mentioned. And that's why, for some books, I'll do it.

This is one of those books.

The introduction is already awesome. I knew most of what they do, but still, they keep delivering on my expectations. On this note, I'll say (if it wasn't clear already) that I'm a huge fan of Basecamp. Maybe too much, actually.

I've been pondering about my own thinking, and I realized that sometimes I'm of extreme opinions. I either like something a lot or I don't like it. And I don't think extremes are good, so this time I'll try to find something to disagree with. I've been reading their content for a long time, so maybe challenging their assertions will give me a new perspective on their content.

I've finished reading Part 1 (Chapters 2-6), focused on shaping. I understood shaping as the preliminary work done before getting started with a task. I would recommend anyone who wants to learn more about the book to go read the chapter and sub-chapter titles, because they are quite self-explanatory and you can learn a lot from that already.

I think their suggestions for shaping up work are great. They really spend a good ammount of time thinking about a problem, contemplating different possibilities, and avoid getting lost in minute details. In particular, I enjoyed learning about breadboarding, given that I always do wireframes. Sure, low fidelity wireframes, but I'm still conditioning the UI from the get go.

As I said in my previous comment, I will also try to poke some holes in their arguments though. And something I don't completely buy into is how to choose what ideas to shape up. They mention that the book isn't about how to choose what to build, but I am missing some interaction with users on the whole process. Maybe they can be excused because they are heavy users of their own product (Basecamp), so they already have that point of view built-in. But I don't think that's the best strategy for everyone.

They also mention not using a backlog and I'm also not completely convinced. Of course I agree that backlogs can be a dread, and they can grow out of proportion. That's why I think backlog grooming is important and you can be as extreme as you want with that. But I don't think I'd be confortable with not having a backlog at all. The next part seems to go further into why they don't do backlogs, so we'll see what else I can learn.

Part 2 was short but to the point.

After learning more about their process, I can see the value of "not having a backlog". But I write it in quotes because it seems to me like they do have a backlog, it's just that they don't call it such. What I mentioned about going extreme with backlog grooming is what they do when they talk about bringing pitches to the betting table. When a pitch is not picked to be completed in a cycle, there is some record of the pitch that can be brought forward for another cycle. And they also track bugs, so I'd consider those things together to be a backlog. But something that is different which I like is that this is a distributed backlog. Each person in the company can keep track of whatever they believe to be important, and pitches can be brought to the betting table by anyone.

What is not completely clear to me is how they choose what to shape, and how they assign people to do it.

Something I didn't agree with at first is a couple of sentences where they mention that some bugs may not be fixed if not many customers complain about. I didn't agree because it seemed to me as discrimination. The fact that a few customers have it doesn't mean it isn't important for them. But after some reflection, I realized they are just being honest with themselves. Because nobody fixes all the bugs, myself included. So it's important to be aware of that and do the best given the reality. Without losing focus on judging bugs on multiple perspectives and not just "popularity".

If there's something I'd want to disagree with on this part, that would be the long-term. They mention repeatedly how they reset the planning every cycle and how they like to keep a clean slate. I can't help but wonder what happens with the company vision, mission and all that. Sure those sound like bullshit at times, but I think a company should have a goal and a purpose, something to achieve. And maybe I'm just saying that from the point of view of an entrepreneur, someone who likes to start things and search for solutions. If they've already achieved whatever they wanted, that's great, but I don't think this can be applied for a start-up or companies still validating hypotheses.

But again, this book is supposed to be about how to build things, not what to build. So it makes sense it won't apply to everyone.

And that's it for Part 3! This part was big, and it focuses on building.

For starters, I really share their view on autonomy for developers and designers. As explained on chapter 7, they assign projects, not tasks. I've referred to this in the past as "missions", and I think it's super important in order to keep everyone motivated. It doesn't matter how interesting tasks are, if all you're doing is checking off tasks on a list you didn't define, you'll eventually lose motivation. I also think it's very important that everyone gets first-hand experience making trade-offs and owning up to them.

Another concept that's introduced here are scopes, and I found them very insightful. Truth be told, most of the time what I call "tasks" are actually scopes, and I often create sub-tasks to track more granular todos. Throughout the book I've found this with different concepts, things I already kind of did but didn't have a word for them or hadn't thought them through completely. So I found reading this book not only great to learn new concepts, but also good to better understand and improve some things I was already doing subconsciously.

The last thing that got my attention were hill charts and imagined vs discovered tasks. Again, something I already sort-of did. But I was not seeing it with so much clarity. I was aware than more tasks appear as a project makes progress, and I saw it as the cost of doing business. But the reality is that it's part of the process, so it makes sense not only to expect them but embrace them. I've always been aware that estimates are off most of the time, but my way to deal with them was to increase the estimated effort depending on uncertainty. So a task that I would value at 4 but there was uncertainty I'd put it at 6 or 8. But it's true that it doesn't make sense on a per-task basis, I was just making up a buffer for the whole project.

Overall, I liked the book a lot. And I'd recommend anyone to read it whole (it isn't even that long). If you don't want to read everything, I'd suggest at least reading the chapter titles and go into the ones that grab your attention. Also check out the summary appendix. For me in particular, these are the parts I enjoyed the most:

There were two other things I wanted to do on this task. One was experiment reading an html book, and I liked it. It was easy for the most part, the copy-pasting for highlights wasn't too painful, and being html I could have easily manipulated it if I wanted to. And the other was put my judgement glasses on and try to find things I disagreed with. Unfortunately (or fortunately) I couldn't find many. And the ones I found are intentional. In particular that not all these tips can be applied to any context and the importance of choosing what to build.

Now, before I close this task, I'll listen to two episodes of the Rework podcast, where they talk about the book. After that, that's it for this task!

After listening to the podcast episodes, I can definitely say they are a good complement. I also got some extra insights that weren't evident in the book. For example, Ryan explains the importance for managers to have time to think, and how separating the shaping and building tracks enables it. They also introduce some more examples of how applying the method helped them improve their process in the past.

Task completed