← All Episodes ← Prev Next →
EPISODE 0047 - JUL 23, 2019 Shape Up

Shape Up

with Ryan Singer
Listen now

Basecamp’s head of strategy, Ryan Singer, sits down to discuss his new book, Shape Up: Stop Running in Circles and Ship Work that Matters. The book is a culmination of Ryan’s 15+ years working at Basecamp and explains how small teams of designers and programmers can ship great work in six-week cycles. Ryan’s book is about product development and software, but many of its ideas around working with the right level of abstraction, embracing constraints, and making smart bets are applicable to other creative pursuits.

Transcript

(00:00:00) Broken By Design by Clip Art plays.

Wailin: (00:00:02) Welcome to REWORK, a podcast by Basecamp about the better way to work and run your business. I’m Wailin Wong.

Shaun: (00:00:07) And I’m Shaun Hildner. Now, you might have noticed that we here at Basecamp like to write books and we have a new one that was just released a couple of weeks ago. This time by Ryan Singer, our head of strategy, it’s called Shape Up: Stop Running in Circles and Ship Work that Matters. You can find it at Basecamp.com/ShapeUp.

Wailin: (00:00:27) The book is a detailed guide to how product development is done at Basecamp. Designers and programmers work in small teams doing six-week cycles and the process that Ryan describes is about structuring work in such a way that these teams don’t have a huge backlog or any hazily-defined morale draining projects that stretch on and on. Shape Up talks about bets instead of plans and appetites instead of estimates.

Shaun: (00:00:52) The Shape Up process grew out of 15 years of making software and Ryan’s been here the whole time. He joined the company when it was still a web design firm called 37 Signals. In this episode, Wailin sits down with Ryan to talk about his career and some of the big themes in Shape Up.

(00:01:06) Broken By Design by Clip Art plays.

Ryan: (00:01:13) My name is Ryan Singer. I work at Basecamp doing product strategy. So, sort of figuring out what the product should be and what it should do.

Wailin: (00:01:22) I wanted to spend a little time talking about your career trajectory cause I think it’s an interesting lead-in to the book since the book itself is a culmination of the things you’ve figured out and worked on at Basecamp. So how did you get hired at Basecamp?

Ryan: (00:01:40) I was a big fan of 37 Signals as a young web designer, I think it was maybe 2003 at that time. Everything was very flashy, like dense graphic design in a little box. That’s kind of how web design was. And I was really into this kind of like usability-focused, like just what matters. 37 Signals’ website at the time was just text. So I was a fan of what Jason was doing and he announced that he had a position open. I applied for it. And then, he brought me into the sort of final round and then he asked a few of us to redesign the Verizon website at the time. And it was kind of like, if you could redesign the site, how would you do it? And he liked the redesign. So that’s how I started working with him.

Wailin: (00:02:28) And then how did you go from that to Head of Strategy? And obviously we’re covering a big chunk of time here.

Ryan: (00:02:35) Yeah. Well there were kind of a few natural jumps. So first of all, when David started programming Basecamp, he did it in this new framework he made called Ruby on Rails. And the thing that was really unique about Ruby on Rails was that a designer could actually kind of work on the programming directly because it was just the html that we already used to make web pages. And it was like the code of the app had html in it, which just a little bit of extra code sprinkled in. And so instead of going to David and saying, “Hey, here’s my design, can you please turn it into the real app?” And then seeing it and then being like, oh, that’s not right. Can you move that to the left? That’s, that’s a really painful process. So it was like, I’m just going to learn this myself. And it seemed so much easier than it ever had seemed before, thanks to how Rails was put together.

(00:03:25) So, that was my entry into programming. So I started to learn programming and I found out that in the programming world everybody had figured out a lot about what they do. There was a lot of clarity around how to structure the program, how to break it into different parts, how to do the problem solving versus on the design side of things, it was a bit more kind of cross your fingers and be creative and hope for the best.

(00:03:52) As I got more between sort of the design and program, with one leg on each, it became natural for me to be kind of this person in the middle. Jason was the design lead, David the programming lead and then as the company started to hire a few more people, I was this person who could kind of speak both languages and understand the meeting point, you know? So then when it came into questions of how do we get stuff built? How do we manage the process of building a feature? I kind of understood both sides enough to help facilitate that more.

(00:04:28) But now the question becomes, well, how do we know if the thing we’re making is the right thing? Those were the conversations that I was having with Jason and David that felt like they were the most important conversations, you know? So then it became more natural for me to put more and more of my time into that side of things.

(00:04:43) Jason suggested to me that he thought it was time to write a book and share what we figured out about how to work. And we sat down for a little one-on-one and he’s like, I think you should write a book about this. And I was like, okay. Like, great idea. And then I walked away from the meeting and I was like, “Oh man, like, oh, am I going to do this?”

(00:05:04) And I kind of sat down, thinking I would try to outline something and it just felt impossible. I know how we do it, but I don’t know why other people should care. And I don’t know what they’re struggling with and if I don’t know what they’re struggling with, I don’t know how to connect the dots between what we know how to do and what they’re trying to do. Which is like the fundamental question of product design. It’s like how do I create the fit between what I know and what people need.

(00:05:35) So I decided to hold a workshop as a prototyping device and I made it expensive enough that everybody who came would be really, really motivated. So it was like 1000 bucks a seat and it was a single day. What was amazing was that I got the opportunity then, first of all, just to take whatever I thought was meaningful to explain. So like how we shape work, why we work in six weeks, how we think about assembling the projects and how the teams work together to actually build it. The main ideas, I was able to try and put out in front of people, but I was totally surprised by some of the things that they responded to.

(00:06:18) So there’s this one thing I talk about in the book called breadboarding. It’s a way to draw a design that’s much, much rougher than a wire frame.

Wailin: (00:06:26) Had you come up with the term breadboarding? You had read about it in like an industrial design engineering context and [crosstalk.]

Ryan: (00:06:32) When I was a kid, there was a Radio Shack by my house and the Radio Shack had this like one wall with, with little electronics components for hobbyists, and there were these breadboards that were like, you could stick little pieces of circuit components together without having to melt the metal and solder them in and everything so you could experiment more. And they had these little books by this guy, Forrest M. Mims III. And every book was hand drawn.

Wailin: (00:07:03) Oh, wow.

Ryan: (00:07:03) It was like they were on graph paper and he hand wrote it and then interspersed it with his little circuit sketches and cartoons and stuff. And apparently these are like the—millions and millions and millions of these things have sold. And I really remembered that, and that’s been in my head the whole time working on this project, actually.

Wailin: (00:07:18) I love that.

Ryan: (00:07:21) And he always kind of gave me—those books gave me the confidence that things don’t have to be this polished professional looking thing. It can be more of a, something that you’d have next to you in the garage. That spirit. But anyway, so the breadboard is this notion of I don’t know how this would look if it was a finished product. If you were making a piece of electronics, you’d have like what material do I use for the case and what is the button, what is the knob gonna feel like? And what color is the knob and, and how many millimeters from the left edge. Is it positioned right?

(00:07:57) But the breadboard is just like, there’s a knob, there’s a battery, it has to get wired to this. And then when you flick this switch, that thing has to go on, right? It’s all about the connections between things. And so when I was trying to describe like what is it that Jason and I are doing in the room, when we’re talking through the like the real rough early phases when you don’t even know what the idea is yet, it’s really about like what are those components, what are those pieces and how could they be wired together so that we could imagine that this thing would actually work to solve the problem that we’re talking about

Wailin: (00:08:32) And you said people in the workshop really glommed onto it in a way you didn’t expect.

Ryan: (00:08:36) Yeah. So first of all, it was something everybody could kind of learn and copy because the notation was very simple. We did an exercise where people went into a room and I gave them a problem to solve, a design problem, and they all did this breadboarding technique on the walls and they were able to see kind of how fast you can move, like how quickly you can try three totally different ideas of this’ll be connected to that and then it will go here and then it’ll go there. So the speed of it was something everybody was really excited about.

(00:09:03) And then the other thing was that, I didn’t know this was a problem before the workshop, that what happens is people feel like they get pushed into too much detail too early. So they’re talking about making a piece of software and then you need an interface. So somebody designs a wire frame, but the wire frame is kind of already too finished. It’s showing the proportions and the layout and this is on top of that and to the left of that, and this is bigger than that. And here’s where the headline goes and all that. And then what happens is somebody would design a wire frame and then they’d give it to the designer and they’d say, don’t make it like this, but this is the idea, but don’t make it like this. How do you give them this in between rough representation of the main parts of the idea while still leaving room for them.

(00:09:52) So people in the workshop were saying like, Oh, this is going to give room to my designers.

Wailin: (00:09:56) Interesting.

Ryan: (00:09:58) And I was like, oh, okay. And then another thing that came out of the workshop was at the end I, I interviewed everybody where you don’t ask them, why did you come to the workshop? You say, what’s been going on with you at work and what was happening when you heard about the workshop, what seemed relevant to you? And then they all told stories about what they were struggling with.

(00:10:20) And it was so interesting to hear patterns come out of, yeah, when we were just three people or four people, we just shipped stuff all the time. Whatever we thought of. We just built it and shipped it and it was awesome. Right? And then we started to do well and we started to hire some people and now it’s like, how do we do stuff? How do I define a project for another person to build? Or how do I manage multiple people building something instead of just sort of winging it the way that we did when we did it ourselves?

(00:10:52) And the people working in the teams, they were getting stuff, that was too detailed telling them what to do, like these wire frames. So they felt a little bit disempowered, kind of like code monkeys was one quote that came out. They’re just taking a ticket that tells them what to make and they build it and then they check the box. And then on top of it the programmers and designers felt like they were in these never-ending projects that never quite felt done.

(00:11:15) So some themes started to come together of, oh wow, if you grow from a few people who just do things instinctively to having more people and now you need to work together, you need some kind of a process and the off the shelf process people were taking, which is kind of this like two weeks sprint stuff. It’s not, it’s not working for people. It’s really not working.

(00:11:35) Broken By Design by Clip Art plays.

Shaun: (00:11:36) After the break, we’ll continue Wailin’s conversation with Ryan and we’ll talk about deadlines and the actual process of writing the book. But first let me tell you a little bit about Basecamp. Basecamp is the one stop shop for managing projects and teams. Instead of cobbling together a of different chat, email and scheduling apps, everything is in Basecamp.

Wailin: (00:11:56) I actually use Basecamp for my daughter’s Daisy Scout troop.

Shaun: (00:12:01) Tell me more.

Wailin: (00:12:03) There are four troop leaders and we have our own project to talk about troop leader stuff, so planning future events and finances and things like that. And then we have a project where all of the parents of the girls are invited and it’s the way that we disseminate information about meetings and events. It’s the way we collect permission slips. People can download the permission slip and re-upload them to the project so we can have everyone’s information on file. After each meeting, we always post a message with a recap where we have pictures and it’s really nice because parents can just see it in their email. They don’t even have to sign into the app. And also a lot of the parents are very busy working parents so this is a way where they can stay on top of their child’s or one of their child’s extracurricular activities and kind of see what their kid’s been up to at scouts. So it’s been really helpful for organizing our troop that way.

Shaun: (00:12:59) Basecamp is all you need for project management and internal communication. You can try it free today basecamp.com

(00:13:05) Broken By Design by Clip Art plays.

Wailin: (00:13:11) At Basecamp, designers and programmers work in six-week cycles. CEO Jason Fried has talked before about the rationale behind six weeks on this podcast and we’ll link to that episode in the show notes. The six-week deadline is one of several constraints that we impose on this process.

(00:13:28) One thing that I think is a major theme of the book because it’s a major theme that runs through, I think, everything we do at Basecamp, is working with boundaries and constraints and really embracing them and seeing them as like a helpful tool rather than a roadblock. And I was wondering if you could talk a little bit more about this notion of the default response to a raw idea being a soft no?

Ryan: (00:13:50) It kind of comes back to how we think about scheduling. And a big difference with how we schedule is that we don’t have this giant list of things that we have to do one day. Everybody creates this big backlog of stuff and there’s more things in the backlog than you’ll ever be able to do, but you’re somehow supposed—you feel like you’re supposed to do all of it. So you always have this bad feeling of like, we’re not there yet, or we didn’t do what we supposed to do, or all the stuff we didn’t do yet, that’s… It just sucks. You know what I mean?

(00:14:29) So instead we have this, different process where we have, in the book, I call it the betting table. And the notion is we’re only gonna make a commitment six weeks at a time. And the only way that something is going to come in front of us for consideration to bet on is if a person personally advocates for that thing and does the, does the pre-work on it to shape it so that it’s a good bet.

(00:14:56) So what happens then is instead of having this long list of a hundred things that we haven’t done yet, there’s like four things on the table. There’s four things that are timely. That are based on what’s going on in the business right now. And this way we’re always looking at stuff that’s timely, that has a context, that has a person behind it who is saying, this is why I think we should be doing this. And it’s not this like backlog grooming thing, you know?

(00:15:22) And so when you brought up the question about the soft no, it’s more that we can’t say yes to everything. We just can’t. And we need to give the ideas and the different requests coming in sort of room to prove themselves to be important and room to sort of compete with all the other things. And then you give it that time to really understand where this issue is coming up and how, instead of just sort of knee jerk reacting to it. So in a way, a short-term no can be a really meaningful long-term yes. Because you’re allowing your understanding of that thing to really unfold to the point where you can make a more meaningful response to it.

Wailin: (00:16:03) Yeah. Yeah. And I really liked the concept of the betting table as well. Can you talk a little bit more about this idea of betting versus planning or bets versus plans? Because that I could tell that was a very deliberate word choice.

Ryan: (00:16:15) Yeah. So, first of all, I wanted to introduce the feeling of risk into the words, because a plan has a feeling of certainty. But the reality is that you don’t know what’s going to happen really. And the whole time, the whole process of how we’re doing product development we’re not just betting on some words, like let’s build a calendar, because it’s too hard to know what those words mean within a constrained period of time. So if we said let’s build a calendar and we had the rest of our lives to build the ultimate calendar, then we could just keep working on it forever, until we die or something. And just keep making it better, you know what I mean?

(00:17:06) But, but in reality, we don’t want to build with a calendar forever. We, we have a certain what we, in the book, we call it appetite, as opposed to an estimate. So instead of saying how long does it take to build a calendar, we say, how much appetite do we have for building a calendar? And that’s based on who’s asking for it? How many people are asking for it? How it relates to our understanding of the market, blah blah blah, right?

(00:17:31) Because we’re thinking of it as a bet. We’re seeing risk in it. And so we’re saying, if I’m going to bet six weeks of time on this thing, I need to do something to improve my odds. I need to figure out, out of the hundred things that a calendar can do, what are the 10 things that are relevant for this situation we’re trying to solve? So that’s the shaping process. We say we’re going to do the pre work on this idea to figure out what exactly is it that we think we can build in the six weeks that’s going to scratch the itch.

(00:18:07) The other thing is that a bet should have a payoff. So there should be this notion of like if we dedicate the six weeks to this, it’s not just two weeks after two weeks after two weeks of kind of filling the box with tasks and then hoping you get somewhere. It’s a notion of like, no, if we’re gonna bet six weeks on this, at the end of the six weeks I want to high five somebody. I want to feel like, wow, we got that thing done. Doesn’t that feel great? We move forward.

(00:18:32) And then the other thing is that a good bet should have a limit to our loss. The most I’m going to lose is the amount that I bet, and unfortunately a lot of software projects don’t work that way. You say, well, you know we’re going to build this and we think it’ll take two months and then eight months later everyone is… you know what I mean? You have to peel people off the floor because the morale is so bad.

(00:18:55) If our appetite for something was only six weeks, because we said, look, only 10% of our customers use the calendar and so on and so on. If we spend a multiple of that six weeks to build that thing, that’s dumb. So we have this notion that we… In the book, I call it the circuit breaker, which is a very severe policy, a very effective, but severe policy, which is that if the thing doesn’t get done in the time we give it, it’s automatically canceled. Because the notion is like something was wrong with our bet. There was something when we shaped the project that we missed that was a hidden complexity or an interdependence or something like that. There was something with the team that was an issue. So whatever that thing is that we missed, instead of reinvesting in the thing that doesn’t work, we’re going to cut it, do something else for the next cycle.

Wailin: (00:19:48) Yeah.

Ryan: (00:19:48) And then in the meantime, we have separate tracks for shaping and for building.

Wailin: (00:19:55) Right, because shaping is done at a senior level between you and Jason, a couple of other folks. And building is what the teams of programmers and designers do.

Ryan: (00:20:04) Yup. And we have these different tracks. So on the next track, when the next cycle comes, it’s like, okay, let’s just do something else that we know we can succeed in, that people are going to feel good about. And then on the shaping track, let’s look at what’s wrong with that thing that didn’t get built

Wailin: (00:20:23) Right. And then it has to go through the same process, vetting process if it wants to get another six weeks of work.

Ryan: (00:20:30) Exactly. So now, because who knows what’s going to happen in the business six weeks after six weeks. So by the time you might have a new idea for how to fix that problem or do that project differently so it’s going to succeed, it still should have to compete with everything that’s current, that’s important. It doesn’t, just because it was important in the past doesn’t mean it’s relevant now.

Wailin: (00:20:51) I like how so much of these techniques which are just about not just, but these techniques are about getting work done and being productive and doing good work and they’re very, very practical. Like it’s so practical, but at the same time I like how it accomplishes this other thing of kind of protecting the intrinsic motivation of the people in your company doing the work. I actually find a pretty strong emotional component to it, which I don’t know if you intended or if that’s just a happy byproduct. But when you talk explicitly about, when you’re thinking about your appetite. You’re thinking, how do I want to feel at the end of those six weeks? Even the idea of something like a circuit breaker, which seems kind of harsh, it actually still is about protecting how people feel because you don’t want people to feel like garbage at the end of six weeks of work.

Ryan: (00:21:40) Absolutely. Yeah, absolutely. So much of these problems that we frame as functional problems, the thing didn’t get shipped, we didn’t hit the deadline, like the tool, the feature doesn’t do what it’s supposed to do and we never fixed that bug. These functional things are issues, but the real issue is always how it makes us feel. So for example, I hear so many stories from people where they’re a product manager, they’re responsible for trying to take the product to a better place strategically. They’re supposed to have some vision for where the product’s supposed to go, but they don’t have any time to think about where the product is supposed to go because they’re in meetings all the time. And then on top of it, people are coming to them with questions like, how should this be? How should that be? And so they end up facing the question of on the weekend it’s like, do I spend time with my kid or do I do the work that I didn’t get to do during the week? You know what I mean?

(00:22:41) Or like when my, my friend invites me out for a drink on a Thursday night and it’s like I can’t do that cause I have to work at night because I didn’t get to work during the day because it’s the only chance I’m ever going to get to actually think.

Wailin: (00:22:54) Yeah.

Ryan: (00:22:54) You know? So much of the book is actually about that. If you shape up a project that’s at the right level of abstraction, so it’s not so concrete that you’ve done all the work for the team and it’s not so fuzzy that they don’t know what it is, but you use the techniques that we show in the book to, to shape the project at the right level of roughness. Then it shows them the boundaries of kind of here are the main components, here’s how it’s going to work and here’s why we believe in it.

(00:23:23) And they can see the solution at this very sketchy level. If you have that, if you’ve done that pre-work, you can give that to a team and say, here’s the rough solution. There’s a million details for you to work out within that. I’m going to give you six weeks to do that. And if it doesn’t happen, there’s no second chances. So take it seriously. And at the same time, I promise to never interrupt you.

Wailin: (00:23:52) Yeah.

Ryan: (00:23:52) What an amazing thing, right? Because then what happens is the team gets empowered. They have the skills to make all the implementation decisions, whether it’s design or coding. And by giving the teams, not only you give them the shaped project, but you don’t give them any tasks. You just give them a really, really clear goal. And you say you guys create the tasks, you all figure out together what you need to do to make this happen.

(00:24:19) And then they’re figuring out what the work is. And because of that, they’re not done when they check off the box that some that somebody gave them. They’re done when the thing makes sense. And then while the team is autonomously building out this thing for a whole six weeks, you don’t have to manage them. That’s the beautiful thing about… you empower them and then that frees you, right?

Wailin: (00:24:43) To do more shaping?

Ryan: (00:24:45) Exactly. So now all of a sudden you actually have the room for that shaping track so you have the whole six weeks to think strategically.

Wailin: (00:24:51) Did you use this framework to write the book? Did, like was it applicable to putting the book itself together? I did use the methods of the book on the book. I tried to, but what’s interesting is that you come to this point when you give work to a team or your future self, in the case of like writing a book.

(00:25:12) You can’t give a team an R&D project and a deadline. And this this comes back to the notion of shaping. If you know what you want, then you can define the boundaries of it and then set expectations and then give it to a team and say, please fill this thing in with all the work that’s needed to fill it in with. But if you don’t know what you want, no method can help you. And this is actually why we have the two tracks, the shaping track and the building track. Because the work that happens in the shaping side is inherently unpredictable. It’s, you are in the furthest end of the unknown. And the output of that work is that you hopefully arrive at projects that are shaped enough that other teams would just nod their heads and say, oh yeah, I know what to do with that.

(00:26:05) And, so what I found was that I had to play both sides as I worked on the book. I needed to get to a point where I understood what the task was before I could really say, yeah, I’m going to sit down next week and write four chapters. So really to do that shaping work, I ended up going out to Detroit and spending time with Bob Moesta and Chris Spiek, my good friends who been a huge help in this whole thing. And what we did was they kind of asked me a lot of questions about what I was trying to explain and challenged me to unpack it. And then we filled a whiteboard with a system that explained how does the work get from, we don’t know what we’re doing to this thing shipped.

(00:26:51) And once I had that giant thing written out on a whiteboard that became my outline for the book.

Wailin: (00:26:57) Okay.

Ryan: (00:26:59) And then I felt like this is shaped up to the point where like, I know what to talk about, I know what to say. Right? And now I just have to write this chapter. I need to write like a bad chapter that talks about this thing.

Wailin: (00:27:11) Yup.

Ryan: (00:27:11) And it gets you from this step to that step, you know? And then, that’s how the skeleton, the book kind of came together.

Wailin: (00:27:18) So where can people find the book?

Ryan: (00:27:20) They can find the book at Basecamp.com/shape up.

(00:27:24) Broken By Design by Clip Art plays.

Shaun: (00:27:32) REWORK is produced by Wailin Wong and me, Shaun Hildner. Our theme music is Broken By Design by Clip Art. You can find show notes for this and every episode at rework.fm and you can follow Ryan on Twitter @rjs

Wailin: (00:27:46) Next week. We’ll have a round table discussion between Ryan and a designer and a programmer here at Basecamp. They’ll go into more detail about the Shape Up process and how it’s played out in their work. And remember, you can find the book at Basecamp.com/shapeup. See you back here in a week.

(00:28:02) Broken By Design by Clip Art plays.

(00:28:12) “You’re the One That I Want” from Grease plays.

“You better shape up
‘Cause I need a man
And my heart is set on you
You better shape up
You better understand
To my heart I must be true
Nothing left
Nothing left for me to do.
You’re the one that I want…”

This is an episode title

00:00 / 00:00