Shape Up with Ryan Singer of Basecamp

Episode Transcript

The following transcript has not yet been edited. I am slowly editing them, identifying speakers, and cleaning up issues; but I haven't gotten to this one yet. For now, it's helpful for some Ctrl+F action to find a pull quote.

Show Notes

Transcription

Brian: Hey, everyone. And welcome to Bright & Early, the podcast for people building early-stage startups. I am your host, Brian Rhea. I talk to entrepreneurs, product people, designers, and marketing pros to learn what works, what doesn’t, and why. Giving you at least one thing to apply to your business first thing tomorrow.

My guest today is Ryan Singer. Ryan is Head of Product Strategy at Basecamp, where he has designed features used by millions and invented processes used by their team to design, develop, and ship the right things. He shares many of those processes in his new book “Shape Up” and we’ll be discussing that today. Ryan, welcome to Bright & Early.

[00:00:48]

Ryan: Hey, there. I’m happy to be here.

Brian: It’s my pleasure. I was telling you before we hit record, I have been following your work for well over a decade. And so, this is quite a treat to have you on, so thanks so much.

Ryan: Sure thing.

Brian: So, I want to talk about “Shape Up”. This is only gonna be a 45-minute interview. But there is a solid 20 hours’ worth of questions and conversation that I would love to ask you about. But the first thing is, I do want to hear a little bit about your experience. You have been at Basecamp for, is it 16 years?

[00:01:23]

Ryan: Yeah, it’s been 16 years now.

Brian: So, and if I have my history right, you started off doing UI design when the company was still a design agency.

Ryan: Right.

Brian: So, what was that like, in the early days?

[00:01:36]

Ryan: It was awesome. I learned so much at every stage of the company’s growth, so far. When I first came in, I was just a really big fan of Jason’s work. 37signals, at that time, really stood out from the crowd because, in the early web design scene, a lot of the design was sort of a very dense graphic design kind of packed into a little box in the middle of the screen. And a lot of images that were stitched together, so that you could click on one part of the image and it would be a button, but the rest would be sort of the background around the button, this kind of a thing. And there was a lot of people doing interesting work in that style.

But you would go to 37signals’ website at the time, and it was just text. And it was just about the statements that they were making, the values that they had, the opinions they had. And it was much more about how things work instead of how they look, even though they also looked really sharp. But it was a much more usability-focused, functionality-focused, clarity-focused style.

At the time, I don’t know who has been around long enough to remember, but I was a big fan of UseIt.com, Jakob Nielsen’s site. He was one of the early proponents of usability, when that term meant a lot more at that time because of the context we were in. The web was so graphic, and kind of all over the place and so immature, that to have somebody trying to say, “Hey, things should make sense. Things should be clear,” that was actually new. Now, it’s so seeped into the culture of web design that it’s quite normal to see beautiful and really usable and well thought out sites. But that wasn’t so much the case at the time.

So, I was really admiring Jason’s work there. And then, when I saw that he was looking to hire somebody, I reached out and tried to get the job. And it turned out that we were very like-minded, but he was also ahead of me, in a lot of ways. And I learned a ton, from working under him, on a variety of short projects before we started doing Basecamp.

[00:03:54]

Brian: Yeah. Were you in Chicago already?

Ryan: Yeah, I was in Chicago at that time.

Brian: Okay, got it. So, it’s interesting, talking about the state of web design in the early 2000s and in the mid-‘90s and whatever. When the concept that a web browser would be able to display an image was just such a revolution, and that was so great, it was such an improvement. It matured to the point where it started to affect usability, right? Are there things that you see now in web design, given your experience, that technologically a huge advancement, great that we can do that. But that are being overused and are actually starting to negatively affect what people like us do for a living?

[00:04:40]

Ryan: You know, I am not sure I would say– I am sure there’s things that we could point out that are problems with web design today. But the main thing for me, just because of where I come from, when I look at the web today, I am just blown away by– I am just blown away. The level of graphic design, the level of technical engineering, it’s just incredible. Every corner you turn, when you look at a really properly professionally-produced site, it’s just incredible the amount of skill and expertise that’s been integrated together to do that. And it’s so far ahead of stuff that I was doing when I was learning years ago.

And I didn’t stay in the field of what’s the new HTML CSS technique? I didn’t stay there, my interests kept moving. I moved from being interested in web design to web UI plus programming, to product, to strategy, and then, occasionally, dipping back again. But for people who have actually stayed in the weeds of what’s technically possible and how to do things better– We have a Marketing Designer named Adam, for example. And Adam’s work is, it’s not only 10X, it’s like 100X better than what I could do if I were tasked with the same thing because he has so much more skill down in the details of all of that type of work.

[00:06:11]

Brian: Yeah, that’s really fascinating. Well, I want to talk about “Shape Up” because it has, predictably, I think it’s fair to say, made quite a splash in design and development circles that we run in. So, congratulations, it is a fantastic work.

Ryan: Thanks a lot.

Brian: Yeah, of course. So, for listeners who maybe haven’t read it just yet, can you give just the quick gist, the key idea that you were hoping to share in writing it?

[00:06:40]

Ryan: Yeah. “Shape Up” is born out of our 15+ years of trial and error, figuring out how to do product development for Basecamp. And the book is, it is sort of two things in one. On the one hand, it’s a handful of specific practices that we use. So, these are the phases of the work that we go through to go from raw idea to something that we can schedule, to something that’s getting built, to something that ships. But, at the same time and, actually, more importantly, the book is also spelling out what we think are some basic facts about the universe.

Brian: What do you mean by that?

Ryan: Well, whether or not you work in exactly six weeks like we talk about in the book. Or whether or not you write a pitch with the five points that we recommend to include in a pitch when you’re presenting a possible project to bet resources on, for example. The underlying key points are about truths about work that you can’t get around. If you want to make an omelet, an omelet starts with raw eggs. And there’s a million ways to make an omelet, but that’s just a fact, right.

And, in the same way, work that a team builds, projects that teams take on, they start with raw ideas. They start with unshaped, “Hey, maybe we should do that. Hey, the CEO had this idea in the shower yesterday. The customers are requesting this. We got this feature request from Sales.” These inputs come in, and they are not actually ready to bet on until we do something more to them to clarify what they are, to define what they are and what they’re not.

To set bounds and expectations on them, so that if we are to delegate that work to a couple of people to go execute, that we know what they’re executing, that they know what they’re executing. And everybody has some confidence that we’re really going to release more or less what we wanted at the end of a time period that we schedule for. And we don’t just get that by magic. We have seen different extremes of how to deal with that over time.

There has been the sort of waterfall extreme of, “Let’s specify every little detail of what this thing needs to be upfront.” Which is too concrete and that doesn’t work because you don’t know all of the details upfront of how to really put it together, down to the tiniest detail. So, that blows up in your face. And all of the things you think you had to do turn out to be different than what you really have to do once you get your hands dirty, right.

That’s another fact of the universe. We don’t know upfront when we’re working with something that is a novel problem that we haven’t exactly solved before, and there’s interdependencies in the problem that we can’t quite see in advance there is going to surprises, right. So, we can’t over-specify the solution upfront.

Then, on the other hand, there is the other extreme of what Agile turned into, which is “We don’t know anything, let’s just let the team figure it out, and hope for the best. And then just swing at it two weeks at a time and, eventually, we’ll figure something out,” right. And that’s not strategic. It’s true that you don’t really know in advance, so it’s good to give more room to change course. But, at the same time, if you’re making an investment, you have to know what you’re investing in, and what you’re pursuing. And why you’re doing this instead of something else, and what you’re going to get out of that investment. So, if we just say, “Hey, go build this feature and figure out what it really is by sprinting at it,” or whatever, then we’re being too abstract and we’re being too fuzzy about what it is.

So, this word shaping refers to the work that we do on a raw idea to reduce our risk and increase our clarity by setting boundaries around it and figuring out what the key points of the solution are, while still leaving enough latitude inside of it for the team to work out the details. So, it’s a level of roughness and a level of abstraction, where we are getting clear about what the work is. And we’re thinking harder about what the work is before we get to the point of doing real design and doing real programming. And then the outcome of shaping is that we have some work that we could potentially bet on.

So, now, we have some work that we have better odds of success. And especially when we talk about betting, we have this notion of this applies to, both, the shaping and the betting process; we have what we call an appetite. So, an estimate is where you start with a design and then you say, “How long is it going to take to do that?” So, you start with the design and then you get to a number. And appetite is where you flip that around; you start with a number and then you go to a design. So, you say, “How much time is this worth to us, strategically?” So, there might be something that comes up that’s worth doing. But it’s only worth two weeks of everybody’s time, it’s not worth an eight-week project.

And so, in that case, if you can declare that up front, then you’re setting some boundaries on the design process. And you’re creating a situation where people who are downstream from that, who are going to do the work are going to have to make trade-offs in order to get that thing done, different trade-offs than they would make otherwise. And what I mean by tradeoffs is, a steak might be better than a hotdog in terms of a quality meal, right?

[00:12:37]

Ryan: But if you only have five minutes, a hotdog is better than a steak, right?

Brian: Right.

Ryan: So, the constraints totally change the definition of value and what’s good and what’s bad. So, the outcome of the shaping process is that we have a potential bet that fits within the appetite for what we think this thing is strategically worth. And, now, we can look at this potential better and say, “Do we have the right people around? Is this the right time? Is this something that we want to do or not? Have we shaped it sufficiently to remove enough of the risks that we can manage?” You can never eliminate all of the risk, but, “Have we done our best to improve our odds?” So that when we make the bet, that we’re successful.

And then, that really comes into, how is betting different than planning? And how is it different than just sort of scheduling time and pecking away at something one sprint after another? When you make a bet, a bet has a capped downside. If you say, “I am going to bet a 100 bucks that this thing happens.” The most you lose is $100, right?

Brian: [crosstalk 00:13:49] Yes, yeah.

Ryan: And that’s the logic of the whole thing, right. We want to have the exact same logic apply to our scheduling and our resource allocation. So, if we say, “This particular feature or this particular improvement is worth six weeks’ of a team’s time.” And that team is, let’s say, a designer and two programmers. We’re making that upfront, as this is how much we’re willing to commit to get this outcome.

If that thing starts to get out of control or it turns out to be more complicated than you thought, or something goes sideways on the project, that doesn’t mean that that project starts to become worth more, right. So, it doesn’t make sense to automatically increase your cost and increase your commitment just because it got harder. The fact that it got harder and the cost got higher doesn’t change the value at all.

So, we have this thing we call the “circuit breaker”. And that means that if a team, for some reason, doesn’t successfully ship and deploy that piece of work that was shaped and bet on for that period of time, then, by default, it’s canceled. By default, it’s just over and it didn’t happen.

[00:15:03]

Brian: As opposed to the traditional default, which is to extend more time to it.

Ryan: Just throwing bad money, after bad money, after bad money. And that’s, in this case, I guess throwing bad time after bad time, right. And what we want to do instead is we want to say, “Look, we shaped this to get very clear about what we were doing and what we’re not doing.” And also, by the way, when we give work to a team, we leave them alone. So, another aspect of betting, is that when you make a bet, you honor it, right. And so, if you bet that these people are going to work on this thing for six weeks, then you leave them alone. You don’t pull them away to do something else. You don’t interrupt them and say, “Hey, just this one thing.” Because not only do you lose the time that you pulled them away for, you lose the momentum that they had built up and you lose the time it takes them to spin up that momentum again.

[00:16:04]

Brian: And future belief that that commitment will be honored and that they know when they start to work on something, it will [crosstalk 00:16:09].

Ryan: Great point, the credibility, too, right.

Brian: Credibility, yeah.

Ryan: Absolutely. So, instead, we say, “Look, we did everything we could do to create the best conditions for success. We left the team alone. And then, at the end of the six weeks, something didn’t go the way we thought it was going to.” So, now, the solution is drop the project, do something else in the next six weeks that we have better confidence in. And then, if we still think that thing if we really wish that that thing had happened, even though we didn’t get it done in the amount of time, then we can have a new conversation. A new betting conversation about, “Well, actually, it would be worth it if we could give it more time.” But, then, before we make that commitment, we should reshape that work because something was wrong.

[00:16:53]

Brian: Something was off, yeah.

Ryan: Right. And then we have to be able to debug that. And that’s where we get into part three of the book, where we have the different practices for how a team can be successful when you leave them alone and you give them more autonomy, and you task them with sort of self-managing the execution. And, here, the #1 difference is that we don’t give the team tasks.

So, I talk a little bit in the book about the paper shredder, sort of the traditional approach in Scrum teams and stuff like that, is that somebody turns the work into tasks and those tasks, or stories, or cards, or whatever–

[00:17:31]

Brian: Whatever you call them.

Ryan: Get slotted into some kind of a sprint, and then the team is basically pecking away at a queue of things they are supposed to do. And this is sort of the code monkey grunt work type of a scenario. It’s not good for morale. And it’s not good for successfully completing the project because you put the project through a paper shredder. Now, you have to hope that all of the little strands glue together again and makes sense in the end, right. But you didn’t have the full information in the beginning, as we talked about.

So, what we’re doing instead of that is we’re giving the team, instead of giving them tasks, we give them the whole project. And they discover the tasks, and capture the tasks, and track the tasks because they’re the ones who actually have their hands down in the system. And they have the hood open, and they are figuring out what’s connected to what, and what’s actually going to work.

And then the final piece there is that in order to talk about progress, and to talk about whether we’re on the right track or not, we don’t look at what’s complete and what’s incomplete. We look at what’s known and what’s unknown because it’s the unknowns that sink a project. If you have something that’s a known and it’s just taking a little longer than you thought, but there is nothing unsolved about it, it’s just labor, then, no problem. You stay up a little later or you throw an extra day at it, or you give it an extra week and everything is fine.

If there’s something that comes up in the project that doesn’t actually have a clear solution, or people don’t know how to do it. Now, you’re in a completely different risk regime. Now, it could be six weeks before they solve it, it could be another 12 weeks before they solve it. It could be unsolvable. It could require ripping up some other foundations somewhere else because of some interdependency that’s supposed to be external to what’s being changed in the project, right.

So, we introduced the language of uphill versus downhill work, using this metaphor of the hill [chart 00:19:25]. Uphill, where you don’t quite see where the top is until you get there. So, you’re trying to figure out how do I do this? What’s the right approach? How does this fit together? And then, for a given piece of work, you reach that point where you’re standing at the top of the hill and now you can see down the other side.

And that feeling of being able to see down the other side, it’s a little bit like that point when you’re assembling the IKEA furniture. And there is, [laughter] you look down and there’s six pieces of wood around and there’s exactly eight holes in there. And you look in your hand and there’s eight screws in your hand and you are like, “Okay, I know I am gonna be okay.”

[00:20:04]

Brian: Yes, right, exactly.

Ryan: You know what I mean? But, in the early phases of the project, it’s not like that. It’s much more unclear where things are going to go and how things are going to fit together.

Brian: There are boards everywhere and piles of screws all over the place. [crosstalk 00:20:17]

Ryan: Yeah. And you don’t even know where to start, right.

[00:20:20]

Brian: Yeah, I love that metaphor. So, I just want to summarize that. That the phases of your approach, of your process, are shaping, betting, and building.

Ryan: Mm-hmm.

Brian: And then, you all, at Basecamp, you actually go into some detail in the book, but let’s just keep it simple here. That, basically, there are six-week cycles and then a two-week cooldown. And it carries on in that way. And so, you go into each of those stages in-depth in the book, and it’s described at a perfect level of detail. I want to ask you about appetite, which you mentioned just a bit ago. That the way that you all– A key differentiator in your process is that during shaping you determine the appetite first, as opposed to, as you said, starting with the design, and then arriving at an estimate.

Ryan: Right.

[00:21:17]

Brian: So, I think a reasonable critique is that it seems like that could result in delivering less than what the customer really needs. Like, it doesn’t matter, Ryan, if you don’t have the appetite, if you don’t feel like spending three weeks on it - that’s what it will take. And so, if I don’t like the color of my house, I just can’t paint a third of it and then call it done because that’s what I had the appetite for. So, how do you balance? I think that the rational description that you gave for, “This is why we start with an appetite instead of a design.” How do you balance that against, “Well, sometimes it is going to take that long whether we like it or not.” How do you all talk about that?

Ryan: Yeah, that’s a really good question. The difference is, at the end of the day, you can’t ever really escape estimation. Because you have to be able to say, “Is this, whatever we came up with–” Even, let’s say, in the case where we start purely with an appetite of how much time do we want to spend, and then we come up with some sort of a design for that. We still need to be able to estimate what we designed to see if it’s feasible inside of the appetite. So, there is no way to get away from estimation. The question, so it’s not about estimation is bad; it’s about where do we sequence estimation in our process?

So, if we start with a design and then we estimate, then, the design gets fixed in the beginning. But the thing is that, that one design is not the only way to go about solving a problem in the universe. So, the important thing is we want to put ourselves in a situation where we are able to find more latitude in the design. So, I use the example in the book of building a calendar.

[00:23:10]

Brian: The calendar, yeah.

Ryan: And the calendar is a good example because I just saw a tweet yesterday about some new calendar app. And this calendar app was talking about how it is the very, very best for figuring out where overlap is between two people’s schedules. So, it was basically saying, “You don’t have to email each other anymore to determine who is free when and where the overlap is.” That alone is an entire product trying to solve that problem, right.

Now, there could be another calendar where it’s all about, I want to have the best month grid view on an iPad. And I want to have the best high-fidelity dragging interactions for how I can move something from one day to another. A totally different space, a totally different problem set, right?

[00:24:02]

Brian: Right.

Ryan: Now, if we ask ourselves, “What is a good calendar?” Then, a good calendar is all of those things, right. But then, we say, “Well, strategically, are we a calendar company or not?” And when we get asked to build a calendar in Basecamp, we knew from the past that a certain percentage of customers ever used the event and scheduling features that we had in past versions. We had some understanding about what we think is driving people to use Basecamp, what problems it’s particularly good at solving etc., etc.

And, based on that, we were saying to ourselves, we don’t want to spend six months again building a calendar because we had done that in the past on a prior version of Basecamp. And we believed, this comes back to your question, we believed that it wasn’t possible to build a calendar that was any good in under six months. So, this is a case where the customer is saying, “I want a calendar.” We are kind of putting an estimate on that and saying, “Well, I don’t think I can do that in less than six months.” And then, we’re looking at our appetite and we’re saying, “We don’t want to spend six months.” So, we just didn’t do it. We just kept not doing it.

Then, the question kept coming from customers. And so, it just kind of bothered me, I didn’t feel great about the fact that we weren’t doing anything about it. So, I wanted to dig in a little bit deeper. And so, a couple of us, Chase from our Support Team helped with this, did some interviews with customers. And what we discovered was that, as is often the case, when they said, “We want a calendar,” they didn’t mean, “Give me a completely full-featured alternative to Google Calendar, or Apple Calendar, or whatever.” This isn’t what they were asking for.

Once we better understood what they were asking for, we had a much more narrow definition of what progress would look like in the circumstance that they were in and then we were able to say, “Hmm, you know, there might actually be a smaller version of this. And if we could do this in six weeks instead of six months, we would actually feel good about spending that time. That’s an investment we’re okay with,” right.

So, then the question became, is there actually a solution in that period of time? And we found one, we found something that we thought was good enough. If you compare it, objectively, to other calendars by some sort of objective standard, then, no, it’s not nearly as good as other calendars. But if you compare it to the baseline of what customers had before and what specifically they were struggling with, I think we have brought people to a place where they were better off. And we see that in the form of fewer complaints and fewer requests on this subject.

[00:26:46]

Brian: Yeah. And it’s well-understood and recognized that constraints, having more constraints often leads to a more creative solution [anyway 00:26:58].

Ryan: Totally, totally.

Brian: That’s pretty good.

Ryan: [crosstalk 00:26:59] And there will be things that come up, where you cannot imagine any other version of the thing, and it costs what it costs. You know, that does happen, but that’s the exception. Most of the things that we do in product development are where we get to decide what we’re going to build, and we make the trade-offs. And we should be more conscious about what tradeoffs we’re making, and what is really important to this thing, and what’s not necessary, and what’s valuable, and where we want to spend our time. It just comes back to be being more deliberate about what we spend time on.

This whole thing about Agile is that decision making got pushed down from leadership to the team, and this is unhealthy. Leadership wants to say yes to everything. And then they just push it down to the teams and then the teams are supposed to sprint on it and figure it all out. And what we want to do is we want to take more responsibility, at a leadership level, for what we’re betting on and what we think is strategically valuable. And then we can put the team in a better situation to be successful because they are not constantly crammed with having to build everything and get it done yesterday. [crosstalk 00:28:11] It’s a really big thing.

[00:28:13]

Brian: Yeah, okay. Man, there is so much other stuff I want to ask about, but I want to follow up on that. Because a lot of people would say that pushing, or allowing that decision making to go down to the team has actually been a good thing; that that’s democratic, inclusive. I feel like I am part of the company mission, etc. And so, to take that away, and bring it back up to leadership and say that leadership is going to make those determinations, that might feel like taking away some purpose or autonomy at the developer level.

Ryan: I think this comes from a misunderstanding of how hard development is. It is so hard to make anything work, making it work is hard. And the programmer’s job is mainly to make it work. And making it work is just really, really difficult and it requires a lot of judgment. So, if you are giving the team little fine-grain tasks to do, and it’s all grunt work because they are just pulling tickets off of a queue. Then, that is way too far on the end of not enough autonomy. And that’s happening in a lot of companies today because of Scrum.

If you go the other way, and you say, “Everybody on the team needs to be involved in the decision about what’s important to the customer, and they all need to understand the customer.” That’s wrong, too, because the team is already tasked with a huge job, which is, make it work and figure out how to make it work well, and make it make sense.

So, it’s leadership’s job to be strategic. It’s leadership’s job to steer the company and figure out what’s worth doing next? And if you have more respect for how difficult development is, and all of the little design decisions that have to be made, then, you give the team room to solve all of the sort of– They are not even small, but they are the local decisions that need to be made when you fill in the shaped work. You give them the boundaries of what to do and what not to do. So, like with the calendar, it’s less about availability overlap, and it’s less about high-fidelity interaction. And it’s more about being able to identify an open space to schedule a resource.

[00:30:42]

Brian: Yeah. And I want to follow up on something there, too, is respect. Respect for how difficult development is, for sure. That, and then respect in the other direction as well, respect for how difficult leadership is and how difficult those decisions are.

Ryan: Exactly. [crosstalk 00:30:58] It takes time and work to figure out what to do. And this is the thing where shaping is such an important idea because it means that figuring out what the work is, is work. So, if somebody is spending time figuring out what the work is, that’s extremely valuable. And, today, so many people who are designers, or product managers, or product owners or whatever, who are supposed to be figuring out what the next feature looks like or whatever. They feel like if they’re not building the actual wireframe, or they’re not building the view, then they’re not doing real work.

But the thing is, if you skip the work of shaping, then all of your real work is going to produce waste because you haven’t thought enough about what’s actually the right thing to do. So, leadership, we need to value how hard it is also to work out the concept. And talk to customers, and look at what’s going on competitively and figure out what is the right thing to do now versus later in the year or maybe never. So, that stuff takes time and effort.

It’s not just arbitrary that you’re the boss and, therefore, you stick your finger in the air, and feel the way the wind is blowing, and then make a decision today. And I think the more that we frame this in terms of different kinds of work, the more that we can have respect for each other for the skill set that we bring. And the more that we can set up tracks, in terms of our careers.

If I am a designer and I feel a little bit frustrated moving this to the left and moving this up, down, and moving it below. And I feel like figuring out the proportion and making it look right is not totally satisfying, and I am more curious about is this the right thing to be building? I could start to think of myself as aspiring to do shaping. And, now, that I have a word for that and someplace to learn about that, I can say, “Oh, what is shaping?” Shaping is where I integrate more understanding of business strategy and I integrate a little more knowledge of what’s technically feasible. And I bring those together and design it at a different level of abstraction.

So, now, if somebody wants to go down that path, they have an option. And if somebody doesn’t feel like that’s where they want to go. And they are like, “You know what? I, actually, really enjoy solving that CSS puzzle and figuring out how to get this thing to render properly. And wow, look, it all plugs together and it all works. It’s so beautiful.” Then that person can go deeper into that role and we can have mutual respect for the fact that we’re doing different kinds of work.

[00:33:34] [Music Plays]

[00:33:39]

Brian: Hey, friends, this is a good time to pause and let you know that Bright & Early is brought to you by Transistor.fm. Transistor offers you professional podcast hosting and analytics. They host this podcast. And I have said it before, y’all, it just could not be any easier. And if you’re listening to this interview with Ryan Singer, chances are pretty good that you have heard of DHH, David Heinemeier Hansson, who recently mentioned on Twitter that they are moving the REWORK Podcast over to Transistor.

“The plan is to move to Transistor,” says DHH. “I feel pretty confident that MIJustin,” that’s Justin Jackson, “and crew are not going to sell out to listener-targeted advertisement schemes.” So, that’s just one reason, if you are thinking about starting a podcast, look no further than Transistor.fm. And if you decide to spin up a podcast with them, let them know that Brian sent ya.

[00:34:40]

Brian: I want to ask a specific question about something you share in the book. You share this [anecdote] of a time that Basecamp missed a rabbit hole in the shaping process. And none of you were able to find a suitable six-week design solution. And so, you abandoned it.

Ryan: Right.

Brian: How often does that still happen for your team? I am just kind of curious about an acceptable failure rate for teams who are just starting to implement this to be like, “Are we still learning stuff happens?” Or, “Whoa, we are fully busted, and we have gotta figure that this is well out of the range of acceptable.”

Ryan: That’s a good question. If I just think back right now, over the last few years, I only have two projects that come to mind where that happened.

Brian: Okay, wow.

[00:35:37]

Ryan: So, that’s fairly rare. We are quite well-practiced in all of this, so I am not saying that that should be the standard to measure oneself by. I think the bigger question is, “Are we more often shipping things that we bet on?” Because all it takes– Honestly, I have seen this in companies who have been early adopters of Shape Up. All it takes is one project where six weeks go by, and the thing ships, and everyone is really proud of it. And the designers and programmers were more engaged than in the past because they had more latitude. And it was shaped, so everybody knew how to focus their energy together.

One of those projects will reset everybody’s expectations about what success feels like. You finish one of those projects, and you are like, “Man, that was awesome.” And what you want to do is reproduce that success again. And so, from time to time, you are going to have the next one, and then you’re going to flub something. And it’s like, “Oh, we missed that. Or we didn’t understand that. Or we kind of rushed and we didn’t totally shape that right.” And then it doesn’t quite go off as well. And you’re like, “Oh, well what did we do–? What can we do better next time?”

Because you only, here is the thing. Software companies are wasting so much time and burning so many, just so many hours building the wrong things and dealing with technical debt. And all kinds of things that come from working in a way that isn’t working. That if, once in a while, a six-week project doesn’t quite work and you either are on the downhill, and you invest another two, three weeks, and then you get through it. Or you identify a major rabbit hole in it, and you table it, and you do something else, and then that next thing ships in six weeks.

Think about it, you had a little bit of a rocky six weeks. You take a cool down. You pick off something that’s better-shaped. And then, in six weeks, again, you have this huge success where everybody is like, “Wow, man, we finished it and we’re proud of it. And we did it, that was great.” I just want to emphasize how big the successes are.

And then because you have the language and the ability to articulate what went wrong, you can look back at a project that doesn’t go right and you can say, “Was it because of the constraints that we created? Or was it because of the performance of the team that was working within those constraints?” Now, we can start to untangle the problems when we’re doing the troubleshooting to figure out what actually went wrong here. Did we miss something in the concept? Or was there something that we expected the team to execute, that it turns out that they didn’t? And did we schedule the wrong person? Or is there a performance issue we have to figure out? Or did we just make a bad bet, right?

And, now, you can go back and that feedback loop doesn’t just loop back on the same team, who kind of had a big committee meeting to figure out what to do and, now, it’s everybody’s fault and nobody’s fault. Now, we can say, “That was a shaping issue. Who shaped this?” Or, “That was a betting issue. Who decided that these were the people who were going to do the work on this?” Or, “That was an execution issue. What happened with this programming decision?” And, now, these times where we get into trouble, they can feel more productive.

[00:39:11]

Brian: Yeah, absolutely. So, I want to ask a question about betting and how that works. So, just real quickly, after something has been shaped, it’s taken to the betting table where the shaper pitches, describes the problem, and the solution, and do we want to work on this, etc. You have this line in the book that is basically [inaudible 00:39:31] “What if the pitch was great, but the timing wasn’t right?” “Well, anyone who wants to advocate for it simply tracks it independently, and then lobbies for it again six weeks later.”

That makes perfect sense. And that that has the feeling of something that just works on a well-functioning team. Like, when you say, “They simply track it independently.” That just works on a well-functioning team but would require processes and politics in low-trust teams. [crosstalk 00:40:04]

Ryan: I actually think it’s [crosstalk 00:40:04].

Brian: Or, rather that’s my assumption. [crosstalk 00:40:08] What are your thoughts on that?

Ryan: That’s an excellent question, and I actually think it’s the opposite, and let me say why. When you have a centralized backlog, okay, what happens is somebody who is in a position in the company to make bets– So, somebody who owns resources, right, looks at that backlog and they see a menu of possibilities. “Maybe we’ll do this, maybe we’ll do that. Maybe we’ll do the other thing.” Everybody else in the company, who is not in a betting position, looks at that backlog and sees failure because, to them, all of this stuff is supposed to happen.

Brian: And they haven’t done it yet.

[00:40:51]

Ryan: And it hasn’t gotten done. And we suck like, “How are we ever going to do all this stuff? And look at all of this stuff that we haven’t gotten done.” And, not only that, it creates a credibility drain and it creates bad politics because what happens is when people can’t agree about what to do, what do they say? “Put it on the backlog.” So, everybody learns that putting it on the backlog actually means we didn’t, we couldn’t agree, and it means it’ll probably never happen. But, at the same time, it’s on there so we sort of feel like we are supposed to do it. And everybody feels squeezed and uncomfortable and bad about looking at this thing.

So, actually, having a public, centralized backlog that everybody can see creates all of these bad feelings. Versus having a private list that a person who is in a position to, who is responsible to lobby for a project, or who is in a position to actually commit the resources; that’s just a useful asset to them, “Maybe I could do this. Maybe I could do that.” But when you have a private list, you don’t need to have these stupid grooming meetings, where everyone is wasting hours having a debate about how to prioritize stuff. It’s a completely different dynamic.

So, what we want is, if we have got two or three people, let’s say, in a very small company, who are responsible for figuring out what to do next, let’s say. Those people can have some sticky notes on their desk. They could have some stuff scribbled on their whiteboard in their office, they could have a notepad, they could have a little to-do list in their own to-do list app of their choosing. And they are just, they don’t have to have a grooming meeting. All they do is just scratch something down that they think comes back to the top of their mind like, “Oh, maybe that next,” right.

And then, if somebody does some shaping work, and pitches a project, and then brings it to the betting table, like you mentioned and, for some reason, it’s not the right time to do it. That person can keep that at the top of their list of like, “Okay, I am going to wait for the right moment, and then I am going to try again.” And then, when that happens, that work is being held on to, somehow, by the person who actually cares in a way that it doesn’t create any sort of a bad feeling among the rest of the company that, like, “Why haven’t we done this yet,” because they haven’t even heard about it yet, probably.

And then when the time is right, they bring that to the table instead of other things. So, it’s almost like an automatic, it’s like you get grooming for free by decentralizing it because everybody just brings their own top priority to the table. And then, when it comes to the table, it’s not something on a queue that you’re trying to read back what the description of it was. It’s something that’s in context, where there is a person there who is standing for the idea and who has been thinking about it to represent it. So, it’s a completely different dynamic.

And this is actually the dynamic where you can have more trust. Because if somebody says, “Hey, I think we should do X,” instead of saying, “Okay, put it on the backlog,” you say, “Well, let’s talk about that. I don’t really understand that.” Or, “Yeah, we have talked about that in the past, let’s see, maybe one day,” and you don’t write it down. And by not writing it down in a public place, you don’t make a false commitment to anybody.

It is more trustworthy, to not follow through on a suggestion that– You know what I mean? It’s more trustworthy if you’re not actually going to commit to do it, to just write it down on your personal notepad instead of putting it on the wall.

[00:44:41]

Brian: Yeah, that’s interesting. I want to, we only have a few minutes left so I want to ask a question. If you have any advice or tips for very small teams who are trying to implement “Shape Up” because they may be the ones who are doing, both, the shaping, and the betting, and the building. Because you have, okay, so these different six-week processes. How would myself and my co-founder, both, have a six-week process of shaping, getting the pitch ready, pitching it to ourselves, and then betting and building?

Ryan: So, that’s a great question because, like you said, in the beginning, everybody does everything. And it’s only when you reach a certain scale that you actually put a formal process into place. So, I would even say that even the six-week cycle might not be a good idea when you’re just three people starting off. I would say throw away everything that is a sort of strict process in the look and, instead, look at the facts of the universe. So, shaped work has a different outcome than unshaped work. Making deliberate bets on things gives you more strategic clarity than just kind of chasing after every request that comes up, right?

Brian: Yeah.

[00:46:06]

Ryan: Looking at what’s known and unknown will help you to make better sequencing decisions and manage risk better than looking at what’s complete and incomplete. So, these are just facts about how things are. If you internalize these facts, then, what you can do is you can say, “Well, before we bet on this work, how do we feel? Do we feel like we know what it is?” And you say, “Oh, no, we don’t really know. Well, let’s not go in blind and then have this thing and then not be clear what it is once we start, right. So, let’s shape this a little bit.” So, then, what you do is you just alternate, you take a little break from building something and you spend a little time shaping something, right. And then, when something is shaped and you say, “Okay, this is good enough to go.”

And it might be more appropriate for a tiny startup team of three people or something to work without cycles at all and just set arbitrary fixed time boxes. And say, “Our appetite for this thing is three weeks. And we shaped it to three weeks. And we are going to work on this thing for three weeks, and then we are going to go shape something else.”

[00:47:13]

Brian: Yeah. So, the small batches and the big batches you talk about in the book, two weeks and six weeks; small teams, don’t make that a dogma. The value of that is, those are numbers that help you set an appetite that you then agree to. A circuit breaker switches in to keep you from continue to, like, sunk cost fallacy and throwing bad money or bad time after bad. But the prescription of two weeks and six weeks as the cycles, you think, set that aside if you need to, if that’s what works for your team.

Ryan: Definitely. And I am so glad that you asked that because this– I am in the lucky position that when I get invited on to podcasts like this, I get these really great questions and then I get to discover things that are missing in the book. So, I am absolutely going to go back to the book and add something about how the different practices are scale-dependent but how the facts are not. You know?

Brian: Yeah, interesting.

[00:48:19]

Ryan: And if you are a team of three, then six weeks, two weeks isn’t necessarily true, but shaping versus unshaped will still give you a good or a bad outcome, regardless of how you schedule that in and how you distribute that responsibility among the team.

And we’re also seeing– I am seeing companies, actually, who are on the other end who are really, really, really big. Who have hundreds and hundreds of people on the development team in a bigger organization of thousands, and they are using “Shape Up”, and they have similar questions. I mean, different questions, but of the same type in the way that it’s saying, “Hey, I think that this all makes sense. But, at my scale, what about X, Y, Z?” And they are solving those things as well.

So, there is definitely something that I want to figure out how to articulate about when you’re– It’s actually not that complicated. It’s just a question of, it’s harder when you write a book because you make this big push and you get the thing out. And then you say, “Okay, well–” Fortunately, because it’s still on the web and it’s digital, I can say, “All right, I am going to open the hood again, and get in there, and make this improvement.” But I think it’d be worthwhile. I really appreciate the chance to sort of improvise and work out these answers by talking to people and then having these questions, and so on.

[00:49:36]

Brian: Well, thanks for coming on. My guest today has been Ryan Singer. You can follow him on Twitter, he is @RJS. You can read “Shape Up” at Basecamp.com/ShapeUp. And he blogs at FeltPresence.com. Ryan, thanks so much for coming on the show. It was great to talk to you.

Ryan: Sure thing. Maybe by the time your listeners read it, it’ll have a new section in it about what to do when you’re a team of three - let’s see.

Brian: Good to meet you.

Ryan: All right, take care.

[00:50:08]

Brian: Hey, y’all, I have got a little bit of unexpected bonus content here. As Ryan and I were hanging up and I was thanking him for the call, I mentioned that I had read this book with a friend of mine who runs an agency. And being a contractor myself, my friend and I, we each find ourselves in situations where we are helping our clients build something brand new, starting from nothing and going to something. And we were just kind of wondering how this process works for that sort of project. And I asked specifically, “It doesn’t seem like you could build Basecamp 3 with the “Shape Up” process described in the book.”

And so, Ryan just kind of began to answer that question, and I tapped record because he was mentioning, “Yeah, this process won’t work exactly as it’s described to build something brand new.” And so, you don’t miss much of what he was saying. At the beginning, where it’s about to pick up, is he is describing how it is just a little bit different as you get things started, so here is that answer.

[00:51:18]

Ryan: Instead of having shape, and then bet, and then build; you make a bet for a period of time, that we are just going to go explore trying to get a few main features somehow cobbled together. You don’t actually shape it, other than a really rough idea of what you want to do. And then the people, the person who you schedule into that time box is mixing, in a very blurry, messy way, shaping and building. They are going to shape what they’re going to do for three days, and then they’re going to try it. And it’s not going to work and they’re going to shape something else and they’re going to try it. So, it’s going to be shaping and building are going to be totally integrated inside of that exploratory time box.

And then, as they build, the main method is always saying like, “Done means deployed.” Get the whole thing, build it to the point that you can ship it, and all the way down top to bottom and then move on. And but if you’re in this R&D mode, you actually want to build everything halfway. You want to build it just enough that you can tell that it’s all going to hang together.

[00:52:23]

Brian: Like you want to build it to the top of the hill. [crosstalk 00:52:27] is that roughly right?

Ryan: You want to, exactly. You want to get more or less to the top of the hill on each main tentpole piece of the product. In order for the product to be what it is, it sort of has to do this, that, and this, right. And you want to sort of get to the point where you’re more or less over the hill on the data model for this and where that belongs in the interface. And how do you navigate to that? And then you reach a point where it’s all like sort of shoddy but you are like, “You know what? This holds together and I know what goes where.”

Then, now, you have a sort of like really rough map. And now you can make bets and shape things to give to other people. Because you can be like, “Look, this belongs over here. Go build this out.” You know?

[00:53:05]

Brian: Yeah, totally.

Ryan: So, that’s the shift. And I tried to describe that in that Appendix, more or less, what I just said. And so, if you’re trying to build like a Basecamp 3, then, what we did was we had, and we’re doing it right now with another new product. We have gone through this a few times. We have sort of the super-team of the most senior people. You have a designer in a programmer who are super-super-senior. And they are sort of skunkworks-style, doing this exploratory work where they are trying to figure out how the main parts hang together. Then, as soon as the architecture gets settled, then the ground is firm. And now, you can go to send other teams in by doing shape, bet, build.

[00:53:46]

Brian: So, the difference in giving them the whole IKEA box with no manual.

Ryan: Yes, exactly.

Brian: And, “Hey, there’s two boards and eight screws in there.”

Ryan: Exactly, yeah, totally.

Brian: That makes total sense [Ryan 00:53:56].

Ryan: And there is still a lot of unknown, but that unknown is more bounded. It’s not like everything is unknown. It’s like, “Well, we kind of know it belongs over here and it’s more or less using this approach.” You know what I mean?

Brian: Yes.

Ryan: “And we trust that if we give the team, if we task the team with solving this, they’ll come up with something that works, and we are not going to have to scrap it halfway through.”

[00:54:16]

[Music Plays]

[00:54:26]

Brian: Okey-dokey. Let’s do some closing thoughts, here. I thought it was most interesting just how Ryan continued to refer back to these basic facts of the universe or basic facts about work. That that sort of term that he kept referring back to, some of those being things, things begin as raw ideas. There are going to be some surprises along the way when you try to turn those raw ideas into a usable thing. You don’t want to over-spec it upfront, some boundaries are required. The process of going from raw idea to something worth betting on, that’s a skill, that’s work.

And striking that balance between free for all, no-process kids’ soccer and soul-crushing JIRA user stories is what they call shaping, like that process of finding the balance. I just thought, I just think it’s interesting the way he just continued to refer back to that.

And the idea to throw away things that are, throw everything that’s a strict process. That the– How did he put that? That the practices, themselves, are scale-dependent, like a six-week cycle, a two-week cooldown. Those specifics are scale-dependent but the basic facts about work are not scale-dependent- they are facts. So, I thought that was pretty fascinating.

I also like that, just the line constraints change the definition of value, of good and bad. That, it’s kind of referring to some jobs to be done language there, around a hot dog and a steak are both really good meals to have for dinner, depending upon what your constraints are. That’s just a great approach, I think, to keep in mind and with all of product design. And that philosophy is behind why they begin with an appetite and not with a design. And they do not allow the design to determine the time investment required. [It’s just 00:56:54] a fascinating thing.

Also, the notion of bets, making bets with a circuit breaker, that establishes a floor. If you are disciplined, then you cannot lose any more than you place in a single bet. That is so, it’s definitely easier said than done, but it just makes so much common sense. How many projects need to go over time and over budget before we adopt the idea of, “Hey, look, we are just no longer going to continue to fall victim to sunk costs, and one more week, we just need one more week”? If you can be disciplined about it, then, this idea of betting and under no circumstances do you go over the bet, it just makes complete sense.

And if you get to the end of the timeline and you haven’t shipped something and there is no way, well, then the circuit breaker trips, and you take the remaining work back to the betting table. And if it’s worth investing in, then it continues to move forward. No doubt, lots of nuances in there. But, as a general approach, as a general philosophy, it just absolutely makes sense.

In preparing for this interview, I was just kind of doing like a little bit scouring around Twitter and seeing what people were saying about “Shape Up” or commenting to Ryan. What were people taking issue with or having some questions, outside of just the mechanics of where do you fit in bugs, which they have added. That happens with the cooldown period.

Not, just that, but some other notions about who does the shaping? Who do the shapers answer to? What happens if consistently bets are being made and people’s preferences are being overlooked, etc., etc.? Just those kinds of things. Those were the bits that were behind a couple of my questions around like, “The process that you’re describing here, it feels like it works with a high-trust, high-talent team. And maybe it doesn’t work so well with others.” And that’s definitely the pattern that I continue to pick up on, the more I was digging around and finding what were the bad reviews.

Most of them have this like a scent of seeking too much certainty, too much process. And those things, in my opinion, are bad for morale. Or at least I should say, bad for morale among teams that value creativity over predictability. So, both of those are good things, creativity and predictability are both values. But placed, given an even-over statement, I would value creativity over predictability. Some people, some teams would value predictability even over creativity. And neither of those are bad or good. That’s just where do you value two very good things.

And so, I think something I have been wondering about, or saying as I have been talking to other folks about the book. Most people who read “Shape Up” and then think, “This would never work for us,” they are probably right. Because it requires a certain type of team, where leadership trusts design and development at a high level, and that trust is returned upward, similarly. Where things will fail, leadership will make decisions that other folks may disagree with. But if you trust that everybody is doing their best and assuming goodwill in every direction, this sort of thing will work. And it will probably be more fulfilling professionally than strict processes, tasks, checklists, and the paper shredder, [laughter] as this referred to in the book.

I think this question about are we shipping things that we bet on, being the primary question that you should be asking yourself along the way. Just, that made a ton of sense to me because when the answer is, like, “Are we shipping things that we bet on? No,” on a regular basis, at least. That is when you can start to dig into, “Well, okay, is that because we are not very good at shaping? We need to work on that process. Is it that we’re betting on the wrong things? Or are we shaping and betting things appropriately, but we have some issues in our build, in our design and development process that we need to refine?” That it feels like, to me, that that is a good qualitative measure, a good qualitative question that teams can be asking themselves.

And so, I think finally, the last thing I want to say or the last thought that I had, is just around the idea of backlogs because I just keep seeing this pop up all over the place. The idea of deleting your backlog, forget about it. Backlogs are bad. They are bad for morale. They make people feel terrible. And I guess my opinion here is “Yeah, if you and your team are in a position where you just want to highlight the backlog, and delete it, and move on - cool.”

If you’re in a leadership position and that is not something that your team can do, I think it’s at least worth saying out loud and agreeing as a group, the backlog is not a guilt log. This is our way of taking the pressure off of ourselves to store this stuff in our brain. We think that that’s equally bad. That’s tiring. And so, we don’t want anyone to be looking at the backlog, feeling bad about yourself because you haven’t gotten to all of this yet because we haven’t shipped it. That’s not what this is about. This is a place where we are cataloging ideas that we are receiving internally and externally because it’s hard to remember things. And so, we are just, this is just our way of getting it out. So, yeah, that’s my short rant on the deleting your backlog issue.

I would love to hear what you think about this interview. If you have any thoughts, you can find me on Twitter, I am @BRhea. That is B as in bulbous, R as in rhombus, H as in hexagon, E as in equilateral, and A as in angle. If you are a founder or executive at a startup and you need some help designing, developing, or even maybe shaping your product; you can feel free to reach out to me at Brian@BrianRhea.com, or hit me up on Twitter. I would love to chat and see if there’s a way that we can work together.

If you are listening to this podcast and it adds some value to your week. Please just scroll down on your little podcast app there and leave a five-star rating and review. It really helps people to find the show. And, as always, thank you so much for listening. And I’ll talk to you next week.