Shaping Up
Ryan Singer’s language for work changed how I think about building
This is a post about Shape Up by Ryan Singer, which you can and should read by going to basecamp.com/shapeup. This post originally appeared on The Slip Box.
Once again this week I found myself recommending Shape Up, by Ryan Singer of Basecamp. So far, every single person I’ve recommended this book to, who has actually read it, has given me some sort of positive feedback. Shape Up provides a vocabulary that anybody can use to reason about product decisions, even if you aren’t a product manager.
Shaping: shape raw ideas into work that is ready for assignment to a team. Shaped ideas are bounded and solved, but they’re also “rough” (i.e. they aren’t so concrete that a developer or designer has no room for creativity and problem solving.)
Shaping has really changed how I think about working with developers. Either we’re not shaping the work enough and developers are receiving something too abstract, or it’s too concrete and they have no room to be creative. Even in situations where you can’t implement the dedicated, mature process that Ryan describes for shaping at Basecamp, “roughness” as a north star is powerful. Trust developers, and empower them by giving them interesting (but doable) work.
Appetite and Betting: “appetite” is a “time budget for a standard team size”. “Betting” means that we gave the shaped work to the team for that amount of time, and empowered them to get it done. Just like poker, when you bet and lose, you have to choose whether to bet again. Bets are made at a “betting table”, consisting of all the people necessary to both empower and obligate the team to do the shaped work.
And herein lies an opportunity. The betting table is shining example of “enabling bureaucracy”. In the enterprise, the betting table is hard to find, assemble, and use. Data fiefdoms, compliance requirements, silos… it can become very difficult to even say what combination of people really is necessary to make a bet. Shape Up was developed at Basecamp for Basecamp and these aren’t their problems, but it’s worth considering how hard it would be to build a betting table at your organization. One place to start: in The Delicate Art of Bureaucracy, Mark Schwartz shares approaches and frameworks for making bureaucracy “lean, learning, and enabling.”
Uphill and Downhill Work: “Work Is Like A Hill” puts words to something everybody experiences, but developers may especially need language for. Where do we budget the time for tinkering, searching Stack Overflow, figuring out how the pieces fit together, and doing experiments? Thinking of work as a hill has made it easier for me to estimate the level of effort needed for work.
Despite all the benefits I’ve gotten from having this common language, I’ve never had a chance to do a “full” implementation of Shape Up. One thing I found out along the way is that Shape Up is just the framework Basecamp uses for building, whereas for deciding what to build they use Jobs To Be Done framework, and recommend Competing Against Luck. ( When Coffee and Kale Compete also discusses the framework.) I’ll continue looking for opportunities to build more of the practices from Shape Up into my daily work.
Originally published at https://theslipbox.substack.com.
