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

Shape Up Roundtable

with Ryan Singer, Conor Muirhead, and Jeff Hardy
Listen now

Basecamp’s new book, Shape Up by Ryan Singer, explores the way designers and programmers at the company build and ship software. In this episode, Ryan, designer Conor Muirhead, and programmer Jeff Hardy go deep into Shape Up principles, talking about the parts of the process they find most useful and sharing real-life examples of both successes and setbacks.

Transcript

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

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

Shaun: (00:00:08) And I’m Shaun Hildner. Last week you heard from Ryan Singer, Basecamp’s, Head of Strategy. He has a new book out about how product development works at Basecamp. It’s called Shape Up: Stop Running in Circles and Ship Work that Matters. If you missed last week’s episode, please go back and check it out. It’s a great introduction to the themes in the book.

Wailin: (00:00:27) Today, we’re going even deeper into the product development process at Basecamp. Ryan is back, joined by two colleagues who work in design and programming. They’ll talk about how the principles in Shape Up play out in their day to day work at Basecamp and they’ll discuss some real-life examples.

Shaun: (00:00:44) Now you’ll hear some terms thrown around like scopes and hill charts. This is vocabulary from Shape Up and we don’t stop to explain them, so if you haven’t already read Ryan’s book, it might be helpful to go do that first. You can find the entire thing basecamp.com/shapeup and we’ll also link to the relevant sections of the book in the show notes if you want to follow along that way.

Wailin: (00:01:04) Okay. Here’s the round table discussion I hosted with Ryan, Conor, and Jeff.

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

Ryan: (00:01:18) My name is Ryan Singer and I do product strategy here at Basecamp.

Conor: (00:01:22) I’m Conor Muirhead and I’m a designer currently on the iOS team.

Jeff: (00:01:27) And I’m Jeff Hardy. I’m a programmer and I’m on the core product team.

Wailin: (00:01:32) Excellent. And Conor and Jeff, I was wondering if you could each talk a little bit about what methods of working and shipping work you had been trained in or used to doing from previous jobs. Just so we can kind of like set up a contrast of your life pre-Basecamp and post-Basecamp.

Jeff: (00:01:54) Right. My life pre-Basecamp was very Basecamp-y. I had been running my own business and so I already had this sense of “Hey, I have to own everything.” Like you have to be able to work across the full stack as we say. But I didn’t have a designer at the ready to do stuff. I would work with people asynchronously, would be the best way to put it. So coming to Basecamp felt really natural and we were small, much smaller then, and I was able to slot right in. And then I’ve been here a long time, so I grew up in that environment.

Conor: (00:02:27) Yeah. I’ve only had one other job in software, before Basecamp. They kind of did a mixture of the big methodologies, I think. They had some kind of Kanban stuff and some pieces of Agile. But we would, everybody in the entire product organization would get together every morning and we’d stand up for 30 minutes or however long it took around a whiteboard that had like magnetic cards that we would put on or whatever we’re working on. We’d move it across the board saying I’m at 35% on this project, or whatever it was. And we’d do things like that. And then it evolved over the few years that I was there.

(00:03:04) I even actually made like an internal tool with a couple of other people that allowed us to do some of that digitally instead of in front of the whiteboard because we had people remote and stuff like that over time. But, that’s kind of the world that I was coming from.

Wailin: (00:03:19) For you guys, what are the most radical parts of the Shape Up method compared with what you’ve seen as prevailing practices in the industry?

Jeff: (00:03:29) I think it’s this idea of slices and finding the thing that you can finish so that you have something to show. Like that if you cut out every other thing you were going to work on, like you still have this thing. As opposed to working around from the edges and you have a whole bunch of undone stuff, which is, I find pretty common when people work. Even in other domains, you focus in and you find a… we call it slices in the book. And find those slices and work on those so that you can mentally check it off as being done.

(00:04:01) That I still find is revelatory for people when I explain it.

Conor: (00:04:05) There’s just something so powerful about an early stage in a project, being able to have something that you could walk away from the rest of the project and say we’re not, we chose not to do anything else and we still have something to show that that could actually go out the door. The more you can have those moments along the way, the better. Just feels good. You have way less risk of failure, stuff like that.

Jeff: (00:04:26) It’s… I don’t know, like finding the closest place to the center. This is a lot like what we’ve called in the past epicenter design. If you take this thing away, you won’t have what you were trying to make so you can’t take it away and it makes sense to find it and then start there. The thing is, is that you don’t exactly know what it looks like when you start. It’s an exploration, but you have this idea of, if you’re working on a message board, and you can’t post a message, you have nothing. It doesn’t matter if you design the index and design all these other things that you would, you know, notifications and oh, I don’t know other UI bits. You really need to start at some core so that you can have something that works.

Conor: (00:05:05) Yeah, and in my mind I’m picturing this one illustration that you did Ryan, where there’s kind of two layers on top of each other and there’s a checkbox connection between both of them. It’s kind of like there’s a front-end slice and a back-end slice and what often happens, and certainly what it was like in my last job is the designers would kind of go away and they would do all this work and they would kind of be asked essentially, most of the time. to kind of design the entire does design or front end layer. And we would figure out all the details, work it all out. And then once we were kind of done, we would ask the back-end guys to do it. Now if at that point the back-end team said, oh this doesn’t work. Or maybe we started working on the project and three months or a month down the road we find that there’s some issue.

(00:05:55) I did a bunch of work that was never even necessary and it’s never going to see the light of day. And my work product was always something that was kind of useless on its own. It was only useful once the other half got connected at some point that was always unknown. And so I think what’s so useful about this part is the connection of doing those two parts at the same time so that I’m not doing a bunch of front-end work or design work that’s, never going to go anywhere, but I’m just doing what we need to get done in order to get a full working piece together. And then we can move onto the next one and do that together. And then the next one and so on and so on.

Ryan: (00:06:31) In the beginning days, I remember, this word done was kind of like a magic word for us or a sort of a holy word for us. This notion that if you do work that doesn’t make something done and it sits around then, you’re somehow on the wrong track.

Conor: (00:06:49) It’s like, we would always say like I want to get this to done is kind of the, it’s a weird way to say it, but we would often talk about like how can we get this to done? We can all feel good about it and we know we’ve completely removed one whole piece of risk from the project, right? Once one thing is done, there’s no more risk in that area and then we can work on the next one.

Ryan: (00:07:10) Totally. As opposed to having all this kind of half-done stuff lying around that’s supposed to magically come together at some point in the future.

Conor: (00:07:17) Right.

Jeff: (00:07:19) What’s interesting to me is that I don’t think you come up with the, doing a bunch of half-done stuff, if you’re working by yourself. Nobody fills out a bunch of random pieces all around the edges. You’re doing it all yourself and you kind of work in those like sort of vertical slices. You don’t have that unnatural sort of separation between back-end and front-end. It’s integrated the whole way. And I think at the time when I started, Ruby on Rails had come out and that was a really big deal because it made it super easy and enjoyable to work on it like that. You’re not just going to step out a bunch of screens and then hand them off and if you’re working on the back end, you’re not just going to invent a model and then hope that it’ll fit with whatever UI gets presented. There’s maybe, that’s another good thing to talk about is just how much back and forth and like trading concessions happens in that integration process. That front-end to back-end.

Ryan: (00:08:14) That’s huge. People talk about continuous integration and stuff like that, but it’s really, they’re just talking about integrating new stuff with old stuff. And I feel like we’re… our focus has always been like continuous integration between layers, between front end and back end, between UI and code. And then, we’re not really worried about six weeks later at the end of the project, okay we’re just going to merge that branch in. That’s not really a big topic for us, but it’s the integration between the different players that’s really more important.

Jeff: (00:08:45) Totally. That idea of “Hey, here’s what we want to do.” And then deciding how difficult is this going to be? We can come up with all kinds of, oh I dunno UI. We can come up with interface and it may look okay, but it may be unreasonably difficult to implement and then you might go with that interface for a long time and sort of think you’re done and then learn too late that it’s going to be expensive to integrate when all along there was no like particular reason for that UI. It was just the first thing that came to mind. It’s what you decided to do and if you had known that it would be difficult to integrate, you could’ve come up with something else, and so not waiting very long to figure that stuff out. And I mean by not long, I mean like hours, days. Like you figured this stuff out really quickly and then you sort of hone in on what the right mix is. What’s going to be going to get the job done and not be so difficult that it’s going to take you a really long time.

Ryan: (00:09:43) Yeah. That’s something that happens. The longer the gap is between design and programming, the more it’s like you can’t go back to anything because you have to package up your work so it can sit in a queue somewhere for somebody else to pull later.

Conor: (00:09:57) One piece of the book this really makes me think about is, is this affordances before pixel perfect screens part. Because I hear people who are doing Agile stuff and the designers are always feeling how can I get ahead of the cycles, right? Because as soon as the sprint begins, they’re kind of behind already because these people are ready, the programmer’s are ready to build something. And the designers are, well, I haven’t done a design yet. So they start working in these kinds of like one sprint ahead or something weird like that to try to get ahead of the curve.

(00:10:28) And I find designers often wonder, “Oh, how on earth can you start at the same time as your programmer because you haven’t done the design yet?” And when the design starts with affordances where you’re just putting a toggle on the screen, like there’s going to be two options, right? So I put a radio button and that’s it. And it’s got the labels beside it and it’s well now the programmer knows we’re going to be having a choice between these two things. We need to be able to save that choice, all these kinds of things. It opens up the door for both of us to start working and then I can start dealing with, how’s that going to look? Where’s it going to sit on the page? Is it part of the same page or part of a different page? All of these kinds of other things come out of it. But when you start with something that was so fundamental as just a basic affordance, it allows both people to start working right from the get-go as opposed to having this kind of one week or three day delay between one starting and the next.

Ryan: (00:11:19) I love how we kind of get those bones in really early and then once the affordances are in, the programmer can start wiring things and you kind of get this, almost like this boost in energy, and this boost in momentum. Because you’re like, “Hey, look, that button that I just stubbed in there, like when I click on it, now it does something.” Now I feel kind of even more excited to make it a good-looking button and put it in the right place. Because it’s live now.

Jeff: (00:11:46) Yeah. That idea of live is really important and it’s something that we focus on. Being able to get something in a working state that somebody other than you can look at and try. And the sooner that you do that, the better. And you need to hook things up for that to happen. If you just look at a screen that doesn’t do anything, oh, I don’t know. There could be like many things that happen when you click submit or when you navigate away and it’s easy to forget that all those things are important and think that you’re done because the screen looks good and polished. When you leave all that polish off, it looks undone and so you’re not tempted to fiddle around. You’re going to make it work in this basic way and that’s freeing because you also feel like all the hard stuff, like that really meaty, can we even do this stuff is solved.

Ryan: (00:12:40) That’s a huge thing that I think we’ve managed to start communicating and talking about with the hill charts is the fact that there’s a different tone to the work and a different feeling in your stomach, in the earlier parts of the project when you’re like, does this stuff even work? Is it going to come together? When those unknowns are in the air? It’s not just an estimate or some kind of a metric of knowing kind of what’s done and what’s not done. It’s this heaviness in your stomach of, “Ugh. I’m going to feel better when I know that this works.”

Conor: (00:13:09) I just think one thing that’s really nice about the hill charts and stuff like this is this ability to be able to articulate where things are and what the dependencies are, all that kind of stuff, to anybody at a moment. If my boss pops in and is wondering where things are at, it’s really easy for me to describe in a couple sentences the status of the entire project without getting bogged down in a bunch of details. You kind of have some short labels that describe the chunks of work and you have this hill thing that you can use to describe yeah, we’re still climbing the hill, we’re almost over the hill, we’re well on the way down. And just gives this vocabulary that makes it so much easier to talk about your work to other people who aren’t necessarily in the mud with you.

Jeff: (00:13:56) Yeah, I think that vocabulary is super important. There’s no structure to a grab bag of to-dos and you can check off tons of them and work is getting done but maybe not. Because they could be so granular that you really didn’t move the needle much. But when you’re talking about scopes, slices. I mean you’re trying to plot them on a hill chart and figure out why they’re not moving. Why can’t I slide this dot up over the hill and what’s taking it so long? And finding and refactoring those scopes. So maybe you have two concepts that are rolled into one and the exercise of finding it, pulling it out, and naming it is super valuable. Now you have a thing to talk about. If you never name that concept, it just remains kind of… it’s fuzzy. You can’t discuss it with people.

(00:14:46) You also can’t have the discussions about if you’ve done it right. These are scopes that should be removable if you need to. And it’s much easier to have the discussion, “Oh, you know what? We don’t need notifications, then. We’ll just cut notifications. We’ll cut subscribers. You can’t really do that kind of large scale like scope cutting or high level, I should say, scope cutting if you’re down in the weeds of a bunch of granular to-dos about implementation details that need to get done. You don’t have a sense of where you are.

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

Shaun: (00:15:16) After the break, we’ll get into some examples of how the Shape Up method was used to develop specific features in Basecamp, but first let me tell you about Basecamp. Basecamp is a software tool for managing projects and teams. Now you can ditch Slack, Asana, Trello, Jira, Dropbox or whatever messy jumble of products you’re currently using. Everything is right there in Basecamp.

(00:15:35) The other day, actually, our CEO, Jason Fried, told me this fantastic story about how his wife uses Basecamp in a really intriguing way.

Jason: (00:15:43) A few weeks ago, my wife got an email from, I think it was 23&Me, one of these genetic testing services that said that that that she has a close relative that she may not have been aware of. She found out that her father has a half-brother. She didn’t know about this and she was certain that her father didn’t know about it either, so it was a pretty big discovery.

(00:16:04) We’ve got a bunch of people who need to know about this and want to discuss this and want to share stories that we have like entire histories to tell each other now that we didn’t know about how can we do this, where could we do this? She’s like, would Basecamp be something we could use? And I hadn’t thought about it, but I’m like, absolutely. You could put all your… everyone can upload their own family photos or historical photos in folders and name them and say this is this person, this is this person. These are all the photos I have for this person, that person, et cetera. Here are all the kids. Here’s, actually, in fact, the family structure.

(00:16:31) They can use the message board to write up like personal histories perhaps and like share stories that way in an organized manner, not like blasting a bunch of emails around which are going to get lost, and it’s a total disaster after like the fourth person responds and it’s like this long quoted, horrible mess. And they could actually use to-dos to keep track of what they want to now organize a family to get together. And like all the things that have to happen to do that and where they should go and all the steps that have to do that. And also as new family members come in and discover this new family member, they want to be able to get up to speed pretty quickly.

(00:17:02) And so just by adding them to the Basecamp project, we’ll give them access to all the photos, all the conversations, and they can read things back at their own pace versus again, like trying to send a forwarded email thread of 60 responses to somebody new. It’s just a total disaster. So, again, I hadn’t thought about that until she mentioned it and I thought about it and go, what a perfect use for Basecamp. And it just reminds me of all the different ways people use Basecamp in ways that it wasn’t intended.

(00:17:28) In fact, I was actually recently speaking in New York at this Wall Street Journal event and I was doing a book signing afterwards. The woman running the book signing was like, “We use Basecamp to run our whole Bookstore,” and it was like another one of these things where, “Oh my God, I didn’t realize that.”

(00:17:40) So anyway, long story short is, people use Basecamp for a lot of things that people might not realize and it’s always a good thing to take a look at it again, if you have some event or some family thing or some store, or a set of projects that you need to get organized but you haven’t really thought about how to do it. Take a look at Basecamp. Even if you tried it years ago, give it a shot, again.

Shaun: (00:17:59) Basecamp is all you need for project management and internal communication. Try It for you today Basecamp.com.

Wailin: (00:18:09) Can you think of a time when something about the method really saved a feature in Basecamp or a particular cycle of work that you were engaged in? Like if someone was asking you kind of what’s been your biggest success story from using this method at Basecamp? Like what would you think of?

Conor: (00:18:27) There’s this one, where we kind of revamped the entirety of how clients are incorporated into Basecamp 3. And this one particularly comes to mind because we had previously had another attempt at this that we called Clients 2.0 or something and it basically, we spent an entire cycle on it and multiple teams and at the end of it we had to throw everything in the trash, essentially. And we didn’t ship anything. And it was kind of, for me at least, that first version was a major wake up call. And it’s kind of what actually got me starting to look deeply at some of the stuff that I was talking about and trying to figure out how I could really make it work for me personally on my teams and my projects. And then making the second attempt at Clients was kind of our chance for redemption and Jeff and I actually worked on that together. And it was a huge project and if you look at through the to-dos and stuff like that, there was just a ton of work and we kind of went at it with quite a bit of rigor using the hill charts and things like this and it came through incredibly smoothly, especially given the scope of the project.

(00:19:37) It kind of touched everything in Basecamp 3 in one way or another. and it just came off really smooth. We delivered in good time and always felt like we had a handle on where things were, how done things were, that kind of thing.

Jeff: (00:19:49) Yeah. The other thing that stands out about that project is the first one, the one we didn’t ship and how that was a difficult decision to make and not one we’ve had to make very often. Because usually we get stuff done on time or it’s… we try to make a decision at the end, if you’re running out of time and on the budget, like is this so close to being done that it doesn’t make sense to cancel it. And usually yeah, you’re within like a day or two or we have a cool down period between cycles and it like easily fits within that. And it doesn’t make sense to throw out six weeks of work because you underestimated. But with this Clients project, the first version, it was clear that it wasn’t just going to need two more weeks or three more weeks. Like it just wasn’t there. And deciding to can it was hard. It was hard.

(00:20:40) But that was the moment where it really hit home that yeah, these budgets matter. We’re not just gonna work on for six months. It won’t be worth it. To only have wasted like six or eight weeks is really nothing. I mean, it’s something, it wasn’t free, but much better to take that sunk cost than to keep pushing on something that’s not gonna work.

(00:21:03) And then, because we did that, we had the appetite to do it again. I think it was like six or eight months later we were like, okay, we’ve learned a lot from this first attempt and now we’re going to take another crack at it.

Ryan: (00:21:15) In the book we call it the circuit breaker, which is this notion that if the thing isn’t done at the end of the cycle, by default we really question it hard and don’t just pour more time into it. In addition to the fact that it felt like it was more than a day or two or a week away, it was the unknowns that were still in it. It felt like we might never solve this. We might never like where this ends up. Like we can’t see the end of this from where we are right now. We’re still going uphill on some of these open problems and it’s good that we cut it because when we came back to it six months later, we had a really different, really targeted idea that we shaped as the project that we were able to really execute smoothly because we had refined our understanding of what we wanted to do.

Conor: (00:22:04) It’s also interesting because I think the first attempt at the Client revamp thing, it had shaping problems as well as building problems. Like there were some rabbit holes and such that didn’t get fleshed out in advance that people totally tripped on.

Ryan: (00:22:22) I remember drawing on the chalkboard and kind of sketching out the main parts of the idea. But then there was this one part about how we were gonna allow you to navigate into different projects that belong to the same client on the home screen. And I remember we just punted on it. We were just like, “Well, I don’t really know how to do that, but it’ll come together.”

Conor: (00:22:44) And then also in our building, we, I know I, at least on my piece of it, I was spending a lot of time on things that weren’t that important that were really downhill tasks and I was covering them up front instead of working on the uphill tasks. And I’m pretty sure that at least for this one part of work that I was doing that was kind of orthogonal from a lot of the other stuff that we could have totally shipped it within the six weeks if I had known how to do hill charts and how to build using this kind of method at the time. And I’m confident that that part would’ve shipped, no problem. But I was working on things in the wrong order. I was spending inordinate amounts of time on the wrong pieces. And I didn’t really, couldn’t really see what I was doing because there was no visual to kind of see what my scopes of work were or how they related to each other or where they were on the spectrum of done or not.

Jeff: (00:23:39) That’s when we learned that just labeling something with 2.0 is a [inaudible]. It’s too big. It’s too wide of a scope. Like Connor just said, there was a slice that he could’ve seen that we could have peeled off and shipped. That was sort of orthogonal to the, to everything else and that’s a sign that you’ve got like too much stuff crammed into the bag and that you haven’t factored it well enough.

(00:24:02) We sort of now have learned to like when we tempted to think of something as a big 2.0 revamp, to factor that down into the three or four, many revamps that they probably are and avoid the pitfalls of trying to do it all at once.

Wailin: (00:24:16) What would you say this method does for your morale and your happiness at work?

Conor: (00:24:21) For me, one of the biggest differences that I felt is just having kind of a sense of control or just knowing that I’ve got a handle on things in a different way. And that’s mostly just because I feel like I understand what the different pieces are that are going on at a given time in a new way. I understand which ones make sense to work on at this particular moment. what the right order is, how much time should be spent on something. And just kind of those few different factors just give a whole different sense of calm and control or having a handle on something that I don’t feel like I ever had before. Before, I was just kind of, I’d work away and hope that it kind of all came together at some point. And one thing that really helped me gain the skills I feel like that I needed and that I was missing before for how to manage the work. And I don’t mean manage, like managing multiple people, just managing my own work, even. It’s like, with the hill charts, being able to see something and have a regular moment to reflect on where is this, do I understand where it’s going? Do I understand how it relates in importance to other things? And do I know how long it’s going to take me to get it to done or to good enough, for now?

Jeff: (00:25:44) Yeah. I think it’s that idea of knowing when you’re done, which I think is like a whole chapter in the book, right? Like how do you know when you’re done, because done is relative. Like there’s… we rarely have something like, no, nothing’s perfect. Basecamp is never done. We’re never done. We just decide when we’re going to finish. And you need a way to define that. And how do you know when you’ve gotten there? And I always like to think of it in terms of if I had to ship this right now, like if I had to deploy this right now, is it deployable? Like, of the changes I made, are they atomic, are they or have I broken the system by leaving it in this state? The system is very rarely in a broken state. It’s sort of like when you’re committing code, you want to have atomic commits, you want to have tests passing. There’s not a lot of transition steps where you’re like, “Hey, I’ve made a huge, massive everything and now we’re going to spend a bunch of time like putting it back together.”

(00:26:38) No, because if at any time you had to deploy this, you want to know would it work? What would happen? And we do this in practice. We use Beta servers. A whole fleet of them and we’re constantly deploying what we have so that we can try it out. And so that it’s not just, oh it works on my machine, or Hey, I’ve got this almost figured out locally. That’s where I find there’s a better sense of… a feeling of accomplishment and a feeling of calm because you’re on the same page. Everybody knows like where you’re at as opposed to it just being yeah, I’ve almost got this, a couple more days.

(00:27:13) When you’re in the almost got this stage, surely there’s things you could even duct tape together to make it work so that everybody can see it. And we are totally not afraid to use duct tape. Like I think that’s an essential part of being able to scaffold something and get it up and running so that you can talk about it, discuss it, and refine it together.

Ryan: (00:27:34) I love how you kind of articulate that test of if I had to ship it today, could I? Or where am I if I had to do that? I feel like the same thing is true on the shaping side. It’s like, if I had to go build this under deadline today, is it actually solved enough to do that or not? I feel like I use the same test there.

Jeff: (00:27:57) It’s about the boundaries, right? Because it’s not like we shaped something so rigidly that it’s a recipe that we’re going to follow. It’s no, we’ve come up with, I don’t know, the personality of the concept and we have a budget, which itself acts as a boundary. It’s going to limit how far you can go with it and then it’s up to you to figure out how do you make an effective version of this in the time that you have while staying within the boundaries.

Ryan: (00:28:25) That’s also why we talk about betting because there’s still risk in the shaped work.

Jeff: (00:28:30) Yeah.

Ryan: (00:28:30) It’s just that we’ve reduced as much risk as we could manage from the upfront point of view. And we’ve also done as much work as we can manage at the right level, in the upfront phase. But we still call it a bet because there’s still unknowns in there. We’re still leaving a lot for the team to work out.

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

Shaun: (00:28:52) REWORK is produced by Wailin Wong and me, Shaun Hildner. Our theme music is Broken By Design by Clip Art.

Wailin: (00:28:59) You can find show notes for this episode at rework.fm, and again Ryan’s book, Shape Up can be found at basecamp.com/ShapeUp.

This is an episode title

00:00 / 00:00