Shaping The Work

Ryan Singer at UXDX Europe. Video: https://www.youtube.com/watch?v=-7cLLpV06x0

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why we wrote Shape Up

[00:00:00] Ryan: Thanks for having me here. I'm happy to talk about shaping and Shape Up. Shape Up is the book that I put out last year that describes the way that we at Basecamp go from a raw idea of something that we think we want to do to a shipped project. I want to talk a little bit about why we wrote the book and what it's for, because in the short time that we have, it makes more sense for me to try to give you some motivation and connect the dots about why this might be useful to you. And then of course you can read the whole book for free at basecamp.com/shapeup.

[00:00:45] Jason, the Basecamp founder, invited me into a room for my semi-annual review a couple of years ago and said, "I think you should write a book next." I had never written a book before, and I thought that this was a terrifying idea, but of course I said, "Ah, good idea. I'll go do that." I had no idea how to do it. But he could tell that we had so many peers in the industry who were telling us about a lot of difficulties they were having. And we were reflecting on some of the difficulties that we went through in our earlier growing pains as an organization. And we had gotten to a point where we had systematized the way that we work enough that it was a good time to try to share it.

[00:01:32] The struggles that we're seeing with other companies, and also with ourselves when we look back at our earlier growing pains: one big struggle is a lot of teams say, "Why are projects dragging on so long? Why is it that we can't ship the way that we used to?" In the early days, when a startup is only three or four people, things just happen organically and they happen quickly. And then as the company starts to grow, things start taking longer and longer. What is going on there, and how do we get out of it?

[00:02:09] The other big problem that I'm hearing, especially when it comes to folks in the UX world and folks who consider themselves to be leaders of the product: there are people who feel that they're supposed to be thinking about what's important to do next. They're supposed to be creating a vision of what we should do next strategically with the product, what's important. But they just don't have any time to think about that. They're so busy in the small details of the work that's going on week by week by week. They're in so many long, probably unnecessary meetings that they're busy all day with all these micro details of the work in process, and there's no time to really think in a strategic way about what's important to do next. Very often we'll even hear about folks saying that they end up spending their time on a Saturday or a Sunday trying to think about what's important to design and tackle next, to move the product forward.

[00:03:07] These are big challenges, and we've managed to overcome them really well. And this is what Shape Up is about. It's about how we create a rhythm within our product organization where we are regularly choosing something we want to do, deciding how much time we think it's worth, and then actually shipping that thing, or some version of that thing that we feel good about, and doing that again and again and again. The way that we really do this... I'm going to introduce a handful of concepts to you that are the main ideas, and then you can go to the book for the details.

Shaping at the right level of abstraction

[00:03:52] The first thing is we talk about shaping the work. When we talk about shaping the work, this is about defining the work at the right level of abstraction. What I mean by that is there's a level of abstraction that is too concrete. This is what happens when, for example, we'll often see teams where the designers create wireframes or pixel-perfect mock-ups, and then these go downstream to get implemented. If the work is defined at such a fine level of detail up front, there's no latitude for creativity, first of all, right? Because you can't draw a wireframe and then say, "Well, make it look like this, but not exactly like this." You're going to get locked in to all of these very early visual decisions that weren't necessarily the right decisions.

[00:04:44] The other thing that happens is when the work is defined too concretely up front, it always blows up in your face later, because the things that work on paper, the things that we think are going to work in very specific visual concepts, very rarely translate directly. Once they actually go into code and into something interactive, and we start clicking on it, we realize, "Oh, that's not really what we wanted." We don't want to be too concrete.

[00:05:06] At the same time, there are a lot of pitfalls if we're too abstract. Too abstract is where, instead of delivering specific wireframes and pixel-perfect mock-ups for a feature idea, we say, "Let's go build a calendar," and we just use the word calendar. Everybody nods their head because they think they know what calendar means, but this is the illusion of agreement. It sounds like something we all know the meaning of, but when it comes to the details, there's a massive amount of latitude in the definition of what a calendar is. For example, does a calendar mean that we're going to allow you to drag events between cells on a month grid? Does calendar mean dragging the duration of a meeting in 15-minute increments? Does calendar mean that we're going to be facilitating the RSVP process, or figuring out how to send invitations, or figuring out overlaps in people's schedules? There's a massive amount of latitude there, and this drastically changes the scope, the expectations, the amount of time, all of that.

[00:06:18] There's a middle zone in between, where we define the work at the right level of abstraction. I'm just going to give you a couple of little examples of that, so you can see. I'm going to share my screen here. What we're looking at actually came from the book. This is what we call a fat marker sketch. We used to do this on paper with Sharpie markers. The idea was that we would use such a blunt instrument that it would make it impossible for us to specify fine details, but at the same time [?]. This is a calendar concept that we built for Basecamp. And this concept was something that we wanted to build in only six weeks. We knew from experience that building a full-featured calendar was easily a six-month project, because of all of those complexities that I mentioned earlier. But we knew for strategic reasons that this was only worth six weeks: the demands from our customers that really mattered strategically were very few and quite simple.

[00:07:37] We came up with this concept, which is like when you book a flight and you see two months side by side. We only rendered events as dots inside of the cells. There was no dragging between cells. There was no spanning of events across cells. There was no high-fidelity interaction here. You can move back and forth in this two-up month view, and then we would display an agenda view underneath, like Apple's phone app, where you could see what that dot was, and it would give you some detail for that. This is an example of specifying the concept at a level that constrains what the team does but still leaves them a ton of latitude for the actual implementation.

Breadboarding

[00:08:21] There's another technique that we use called breadboarding, and this is even one layer more abstract. It's a technique where we just use words and connections to specify the affordances and what appears on a screen. Here's the basic idea. If we're going to talk about an invoice screen, we write "invoice" and then draw a bar underneath. Then we can say that on the invoice screen there's going to be an affordance to turn on the autopay option. The autopay option is going to take you to a screen called Set Up Autopay, and here we're going to have the credit card fields and a logo for the financial institution.

[00:09:16] What we've done here is we've described what needs to happen functionally, what needs to be there in order to perform the functionality. But look at all of the design latitude that we're leaving for the team. We're not even saying this is on the left or the right or above or below. There are no two-dimensional relationships here at all. Purely topological relationships of what connects to what, while still being very specific.

[00:09:47] For example, here we can say, "Well, should we introduce an option to pay the balance now?" This is a recurring option for paying an invoice. And we can say, "Well, no, this is the wrong place to do that." We can totally revise the concept and say, "We're going to have a pay screen, and from the pay screen we'll have an option to autopay in the future," and so on. You get the idea of how we can very quickly adjust the concept. We're allowing for a lot of variability in the scope, because we're not defining it down to the small detail, but at the same time we're bounding scope, because we're defining the important things that are in and that are out. This level of shaping is where we do project definition at the right level.

Appetite instead of estimates

[00:10:26] Now, a couple of other major concepts that I want to share with you in the short time we have here, regarding time estimation and scheduling. Very often when teams are designing work, they design a concept and then the question becomes, "Well, how long is it going to take to do that?" And then we have what's called an estimate. The estimate is where you start with a design and you put a number on it. We work the opposite way. Instead of setting an estimate on some work, we define our appetite. The appetite is how much time we actually want to spend on this thing. That's a very different question. We reverse the process: instead of starting with the design and then giving it a number, we start with a number and then come up with a design that can fit inside of that time box.

[00:11:31] With the example of the calendar, if you just said, "Well, what is a good calendar?" then of course it would include all of these high-fidelity interactions for dragging events and dragging the edges of events to change the duration, all kinds of things like that. But when we say, "Well, we only have an appetite for spending six weeks on this calendar," that changes everything, because now we've introduced time as a design constraint. The time isn't how long it's going to take. The time is going to constrain what we are going to build. And out of this we came up with what we called the Dot Grid Calendar, which was a very, very limited calendar. But because of our understanding of the demand and the circumstances that our customers were in, we understood that we could scratch the itch that we wanted to scratch within the amount of time investment that we wanted to make.

[00:12:25] When we combine these two together, when we set an appetite instead of an estimate, and we define the work at the right level of abstraction, so that it's very clear what is in and what is out, but there's a lot of latitude for how exactly it gets executed, then we can use fixed time, variable scope. We very often talk about building some version of a concept. We don't need to build the version that was specified down to the pixel, and we don't need to have a contract where every single bullet point will be there. We understand the spirit of the idea. We've shaped an idea that we think is viable within that appetite. And now the question is how we make that time commitment and give it to a team and get somewhere with it.

Betting instead of planning, in six-week cycles

[00:13:13] Here's where we talk about planning instead of betting, or actually betting instead of planning, sorry. Very often teams will choose something to do and then they'll make a plan: this is what we're going to do. We use the language of betting because it communicates the risk that's involved. Different concepts that we choose to schedule are going to have different odds, according to how well we've understood the interdependencies of the work, how well we've shaped it, how well we've scoped it. The work that we do in the shaping affects the likelihood that we are going to be able to ship it in the amount of time that we think we're going to spend on it.

[00:14:00] At Basecamp, a typical team is one designer and two programmers working together. The way that we schedule projects is we have what we call the betting table. Shaped work is a potential bet, something that we could do. It's a good option. Then at the betting table we make a decision about what we are going to do in the next six weeks. We work in six-week cycles.

[00:14:25] The exact number six is not so important, but the basic size is. A lot of teams are working two weeks at a time. Two weeks is not long enough to really finish anything meaningful, if you're trying to reach a meaningful goal where you're actually shipping the work. You can't run when you're looking down at your feet, and working two weeks at a time is a little bit like looking down at your shoes. On the other hand, if we make the time horizon too far and say, "Okay, let's plan six months for a project," nobody can feel the pressure of that six-month deadline coming until you get to around six weeks away. There's a natural horizon where you can feel the deadline pushing back on you. What we've found is that around six weeks is the right period of time: long enough to accomplish something, but short enough that the teams can feel that back pressure from the beginning. And this back pressure motivates them to make trade-offs.

What makes a bet a bet

[00:15:33] The way that we make this back pressure effective is by having a tough policy around what betting means. When we talk about making a bet, it means that we're going to take this shaped concept and give it to a team, and they're going to build it for the next six weeks, and at the end of the six weeks this is going to ship. Now, there are three things that make a bet a bet.

[00:15:57] The first is that we don't make a bet unless we expect some payoff. We're not just building incrementally two weeks at a time with no end in sight. When we make the bet that we're going to spend six weeks on something, we know what done means from the beginning, because of the shaped concept, because we've done the shaping. We have a definition of done: some version of this is going to be completed within the latitude of the variable scope at the end of the six weeks. We have a clear payout of what we hope to get from the bet.

[00:16:30] The second thing is that when you make a bet, you're making a commitment. It's something that you honor. You don't make a bet and then say, "Oh, just kidding, I'm going to take my money off the table again." No, it's a commitment. What that means in the context of software development is that when we say this designer and these programmers are going to get the six weeks, we are not going to interrupt them with other things. Support isn't going to come and say, "Can you fix this bug?" Sales isn't going to come and say (we don't have sales, but if we did), "Hey, I need you to stop what you're doing and build this feature so we can close a deal." Six weeks for this team is a commitment that we're making. It's the bet. It's the money we're putting on the table, saying we are willing to risk this to get this outcome.

[00:17:22] The third thing that makes a bet a bet is that there's a cap on the downside. If we say that we're going to bet six weeks, and then the project starts to take 10 weeks, 12 weeks, 18 weeks, there was no meaning in placing the bet, right? We should have a sense that the maximum we will lose, if the uncertainty blows up in our faces and we don't get what we hoped to get out of this, is the amount that we bet. That's a capped downside.

The circuit breaker

[00:17:56] In order to implement this, we have a policy that we call the circuit breaker. The circuit breaker means that if the project doesn't finish in six weeks, in the appetite that we've set for it, by default it's canceled. We don't automatically extend the work, ever. We never just say, "Okay, we started it, we have to finish it, so let's give it more time." If we shaped the work and had done the work to say we believe this is a good bet for six weeks, that there's some version that can ship at the end of the six weeks, and then it doesn't happen, there was something wrong in our model. There was something wrong in our understanding, or in our design concept, or in the performance of the team. Whatever that thing is that was wrong, we need to look at it again and decide: do we want to reinvest in this faulty thing?

[00:18:50] The other thing is that something much more important might have come up in that six-week time. It could be that the thing that we thought was the best idea we had six weeks ago is now less important than a new opportunity that we discovered, or a crisis that has appeared, or who knows what could happen. We also want to always give ourselves the optionality to abandon something that didn't work and to do something more important, rather than continually reinvesting in it. This circuit breaker is very powerful.

Giving teams the whole work

[00:19:25] There's a third and final aspect that I'll mention in this brief overview, which is that we do not assign any tasks to teams. Nobody creates tasks for teams. What we do is we give them the whole work. We give them the shaped concept. We give them the time box of the six weeks. And then we say: inside the boundaries of this concept and the boundaries of this time box, come up with the best thing you can come up with. And then the teams themselves, by getting involved in the work, by trying to integrate and produce it together, capture the tasks that they discover.

[00:20:07] There's a huge difference between the tasks we imagine we have to do, the imagined tasks, and the tasks that we discover we have to do by getting our hands dirty in the work. Those are the discovered tasks. What the team is doing is creating their own tasks. They're capturing the discovered tasks that appear as they get involved in the work. And they are self-managing and making the trade-offs about what work to sequence in what order, what problem is important to solve first, which pieces of design and back end to integrate early, in order to successfully complete the project in the six weeks in a way that's satisfactory.

[00:20:43] In the book, in part three, we have a lot of detail about the methods the team uses to do this sequencing, how they bundle different aspects of the work into different scopes, how they manage unknowns and knowns with the hill chart. There's quite a lot there. But the key point is that they have the shaped work and the latitude to adjust the scope, and they have a hard boundary with a real ending because of the circuit breaker. This circuit breaker creates back pressure. This back pressure motivates the designers and the programmers to collaborate more, to decide what to tackle in what order, at what level of fidelity. And because they have this productive pressure, but they also have enough time and the right amount of direction in the shaped concepts, this massively energizes the team.

[00:21:51] This is one of the main things that I love hearing about teams who adopt Shape Up: they say that they've never seen so much collaboration and so much excitement out of the collaborators, because they have more to contribute. They have more creative latitude than before, and they have more responsibility than before to make trade-offs about what is important, when to keep polishing one screen, and when to say, "That screen is good enough. Let's move on to this other thing where there's more risk."

[00:22:24] That's a high-level summary of the things I wanted to talk to you about. Appetites versus estimates. Working with the right time horizon: six weeks to get something meaningful finished and shipped, rather than two weeks on a treadmill, or six months where nobody sees the end and nobody's reacting and making trade-offs. The notion of fixed time and variable scope. Using work that's shaped at the right level of abstraction to give creative latitude. Making bets instead of planning. Capping the downside of our bets. And giving teams the whole work, giving them responsibility for the whole and the integration of all the parts, instead of tasking them with tickets for the individual components of the work. With that, I'd like to see if you have any questions for the time that's left.

Q&A

[00:23:26] Rory: I'll jump in there. Thanks very much, Ryan. That was really good. I really liked that talk. I'll jump in with the first question. I love that calendar concept. It was a great concept because it's complex enough. With the calendar, when you're shaping, is there a risk that you're taking away some of the context from the builders? When you're shaping, you're saying, "We're just going to go with the dots," and that's for a reason, and you've chosen a particular reason. But is that rationale being handed over to the team as well, so that when they inevitably have to make more decisions, they're going to be able to understand why it's been shaped the way it has?

[00:24:11] Ryan: Oh, that's excellent. I'm really glad that you asked that, because I left out a detail, which is the way that we present the shaped work to the team. We write what's called a pitch, which first presents the shaped work to the betting table, to choose whether or not to bet on it, and then if it gets bet on, we pass it further on to the team. The pitch is not only describing the solution, the shaped work. It's also describing the problem and the motivation. And this is where the appetite is also very important, because if we say, "Look, we're only doing dots on the calendar," someone could say, "Well, come on, that's clearly a worse calendar. We should be doing all these other things." And you say, "Well, given the appetite, and given the context, and given these things that we've understood by talking to customers, this is why this is the right solution." What we're doing, by shaping the work, is giving the teams the context that they need to make the trade-offs.

[00:25:07] Another thing I think is very important to mention here is that I think product teams have become way too democratic, and they should become more authoritarian. Programmers and designers: programming is very, very hard and requires deep expertise and tons of time, all day dealing with small, difficult, hard puzzle problems. Design is the same. Design is really hard, and it takes all day to solve hard design problems and figure out how to implement them correctly. Designers and programmers have deep, amazing expertise. They don't have the time or skill or the resources to go talk to customers, to model strategy, to understand why we're building what we're building. They need to know the context around what's been given to them, but they need leadership. Somebody needs to spend the time to talk to customers and to do the higher-level design work.

[00:26:09] Because this isn't a power question. It's not a governance question. It's a time and work question. Talking to customers and coming up with concepts that meet their needs requires hours and hours and hours of time that people who are dedicated programmers or designers don't have. I think this is really important to look at as a way that each of us adds a different type of value and complements each other. I look at our team members: they can do a level of design that I could never implement, and they're going to come up with solutions at a fine-grained level that I could never come up with, that are 10 times, a hundred times better than what I could do. But I have a specialty, in my shaping role, of trying to understand what's going on strategically with what customers are trying to do. I want to be able to package that understanding in a way that gives them boundaries and then enables them to do the things that they're really good at, and then we're very complementary to each other.

[00:27:12] Rory: Great. I'm just going to paraphrase. There are a lot of questions coming in at the moment, but there's a theme coming through here, I guess, that slightly contradicts that viewpoint versus... We had Marty Cagan on yesterday, and he went very much the democratic route. But can you give people a bit of an understanding of what your team looks like? Because I'm seeing a lot of people asking what your makeup is. And a second point to that: as the shaper, how involved are you in the delivery?

[00:27:42] Ryan: My goal as a shaper is to have the least involvement possible, and to be available in a support role if questions come up or things need to get workshopped. We don't have any regular meetings at all. During the six weeks, there are no regularly scheduled meetings of any kind. The only meetings that we have, both within the team and outside the team, with the person who shaped it or someone senior or whatever, are ad hoc workshop sessions with two or three people, where a very specific question has come up and they have decided ad hoc to talk with each other.

[00:28:20] The actual build teams, that's the important thing. I've seen Shape Up implemented, of course, in our own case at Basecamp, where our designers are both doing the visual design and doing the front-end build-out, and then our programmers are mainly doing the back-end aspect. That's the way we were built and integrated at Basecamp. I've also seen this work in other companies where you have a few more hops in the chain, where you have a front-end engineer who's not conceiving the interaction, they're more implementing the view, and then you have a stylist who's doing more of the graphic design of how the interface should look, but they're not implementing it in code. And you have a back end. You can have more layers. The point is that all the layers that you need to build something are integrated on the team, and the team is as small as possible. We should have something like two to four people on the build team, with all the skills that are necessary to build, and there's no management necessary, because the team is self-managing. That's all we need.

[00:29:34] Rory: Yeah. I'm trying to keep track of all the comments coming in as well. That is a lot smaller than, I guess, traditional teams would be in a lot of organizations, even with the two-pizza team. And a lot of companies struggle with that, trying to keep it small.

[00:29:48] Ryan: You can't really build anything targeted as soon as you have a giant team, because then you're spending all of your time coordinating with each other and you're not actually in the work. When we have a very small team and we scope the work for what this combination of people can do in six weeks, then we're designing the work. Usually teams take the work for granted. They don't really design the work. They just say, "This is what we have to do," and then they keep throwing more people and more time at the work. What we're doing is designing the work so that it suits the people, so that it's something that we can execute.

[00:30:28] Rory: Great. And just on that, keeping it constrained ties in with a few of the questions. What about bigger initiatives, something that's going to take more than one team, with coordination across teams?

[00:30:38] Ryan: Yep. Here's the thing. If you want to do something big and you just define a giant thing that's going to take six months or a year, nobody's going to be clear on what they're doing until they start to feel the deadline. You're going to get six weeks away, more or less, from the six-month deadline, and all of a sudden everybody's going to start going into hyperdrive, staying up late and working late, and it's going to be chaos, because nobody had a clear pressure of what done looked like at the right scale.

[00:31:11] The thing is, you can't just go build something giant. You need to decompose, and this is what design is all about. You have to decompose the problem into orthogonal parts. Where these parts are interdependent and those parts are interdependent, let's separate them into separate definitions of done. What we have to do is take this giant hairball of work and follow the interdependencies. Find what we can, sorry, orthogonalize, or factor, or decompose. Find the word that works for you. But it's an analytical process of looking at the dependencies in the work to be done and defining an entire thing: if we finish this, this is a piece we can understand. It's a piece we can shape. And having understood it and shaped it and defined it and given it six weeks, we are very confident that at the end of six weeks that thing will be done.

[00:32:18] What we want to do is do that over and over again. We might have to have a larger macro appetite, in the sense that we might have to dedicate, let's say, four or five cycles to this big effort. But the thing is, already in the first six weeks we're probably going to discover that things didn't work out the way we thought. And what we want to be able to do then is, on a rolling six-week basis, adjust our planning of what the next thing is we're going to build, or how we're going to redefine the problem. We have the sense that we're going to be working on this big thing, but we're always taking spoonfuls that fit into our mouths. We're taking problems we can understand, that are tractable, and we're setting boundaries that we can make trade-offs with, so that we succeed as we move along.

[00:33:09] Rory: And I guess you've touched on it there. How often are you wrong in your bets? Wrong is probably not the right word, but you said it's going to take six weeks, and it takes four, or it takes eight. I know, as you were saying, you don't automatically renew, but how often are you not correct? It could be short or it could be long.

[00:33:30] Ryan: Yeah. First of all, Parkinson's law, which you've all probably heard about: work is never short. And it doesn't matter if it's short, because remember, this was an appetite, not an estimate. The appetite was the question of, strategically, is this worth the resources? If this was worth six weeks to the business and it only costs four weeks, it's still worth six weeks to the business. That's not a problem. This is about business value, when we talk about appetite.

[00:34:01] When it comes to things going over, we've had cases where we thought it was going to be six weeks, we get to the end of the six weeks, and it's not done. For us this is quite rare. I can think of maybe three cases in the last three years where it was really, really not done at the end, because we have quite a bit of experience with this shaping, which allows us to hit the target pretty well. But it definitely happens from time to time. The main difference, if we're at the end of the time and the work is not done (this is actually where the hill chart came from, so you can look in the book to see what the hill chart is), the question is: are there things that are not finished that we don't understand, or are there things that are not finished that we completely understand, and we just have to tighten screws?

[00:34:57] It's like if you're building an IKEA piece of furniture. It's the difference between when you have all the pieces on the floor and you're holding your head and you're like, "How in the world is this going to come together?" versus when you have three holes left and you're holding three screws in your hand and you're like, "Okay, I'm not worried about this at all." If we get into a situation where we see the three holes and we're holding the three screws, then we're very likely to reinvest. At the next betting table we'll say, "Okay, we're going to give two weeks of the next cycle to finishing that work, because we understand it."

[00:35:30] If the table is standing but there's a piece of wood lying on the floor because there's something we don't understand, then we would rather deal with that on the shaping track, outside of the building cycles. We're going to troubleshoot it, if it's worth it, and figure out what it is that we're not understanding, so that when we do invest more time it's going to be meaningful. But I can tell you for sure, we had two or three projects that we just completely abandoned because they didn't happen in the amount of time. And I have never regretted that. Every time we've pulled the circuit breaker, it has always felt like a relief, because we freed ourselves of something stupid that we were doing, something that we didn't understand, that was too tangled up, or didn't have a well-thought-out concept.

[00:36:20] Rory: That's a great example. I've been in that experience before, of cutting something, cutting your losses. I found it's painful at the time, because you've invested so much, but it is the right decision.

[00:36:30] Ryan: Yeah. And when it's seen in the context that, look, this was a bet from the beginning, there was always risk in it, then it's not necessarily the team's failure. And we can also do a debrief to say: was this a shaping issue? Was this a performance issue? Was there some random, very unexpected thing that got in the way? We can have very productive conversations that help us learn when this happens.

[00:36:53] Rory: Great. Well, I'd like to thank you for joining us today. I always like hearing different opinions. When everything is all just a bit too same, it can get a bit worrying. I really enjoyed hearing a bit of a different opinion on how teams should be working, shaping and collaborating. Thanks very much for joining us today, Ryan.

[00:37:14] Ryan: Yeah, happy to do it. For those who still have questions, please check out the book. I think you'll find a lot of answers there. And you can also find me on Twitter, @rjs, and you can DM me there, whatever. I can answer some things.