Shape UP Ryan Singer

Alright, I think we're live. So welcome folks, welcome everybody to this 9th episode of the webinar of the Agile Spain webinar series. The idea of this webinar is to try to share some kind of content knowledge that Ryan has based on his experience at Basecamp. So Ryan, feel free to introduce yourself to the audience. Hey everybody, I'm Ryan. I'm talking to you from Santa Fe, New Mexico in the US right now. It's 1130 in the morning over here and I got an email from from Fed here, the organizer, and happy to talk about Shape Up. I'm not quite sure how much everyone has had a chance to look at the book or if they're being introduced to the ideas for the first time so we can sort of follow where the questions go. I'm also happy to give some background on myself and where the book comes from. Briefly about myself, I've been at Basecamp for 16 years now and I started in 2003 as a web designer. We were a web design firm and I was just doing mainly user interface design, not so much graphic design but more like functional things, interaction design. And I was doing sort of hands-on HTML and CSS as one did at that time. And it was shortly after I joined that I was working at the time with Jason Fried, the founder of Basecamp, then called 37signals. And we had another guy, Matt Linderman, working with us doing web design projects. And then Jason had this idea for this app to sort of centralize the way that we communicate about all of our projects with our clients. And this became Basecamp. David Heinemar Hansen came on board as the as the programmer and he's now CTO and Because he built Ruby on rails the web the the Ruby web framework that we that we used to develop it Actually rails made it really easy for me to make this jump over from just doing design to also doing programming because in a rails app the views are very, very close to just plain HTML and CSS. And so I got to learn a lot about the programming world. And one thing that I learned was that programmers, especially this sort of community that David was coming out of, you know, there was people like Kent Beck and Martin Fowler and Eric Evans and a lot of those folks, they had some really clear, structured thinking. about how to deal with the complexity of making software. I think I saw the name of your group that you have a lot of agile people or people interested in agile. I'm referring back to the early wave of agile, especially things like Kent Beck's Extreme Program Book. There was a lot of work around how do you separate concerns inside of the code. How do you factor it into parts that you can think about independently? But what was happening was that knowledge was limited to just the programming world and Once I got exposed to that since I had experience with both UI and programming and I was sort of driving from the UI side I had the idea well, maybe we could actually perform factoring and and separation of concerns up a level You know at the at the product level and this would help us to to manage the complexity of the overall development better. And I had a chance to first test that actually in 2009. We did a really big challenging technical project. Before that, we had always been very, very constrained in how we worked because we had, David was only building, he was only working 10 hours a week. So the whole first version of Basecamp was built with 10 hours a week of one programmer. And that forced us to always think in terms of not so much estimates, but more appetites. You know, how much time are we willing to spend on something? How much complexity are we willing to take on rather than just sort of doing whatever we think we have to do for it to be good. And however long it takes is however long it takes, right? Because we would never have shipped if we had that attitude. So we already had quite a lot of discipline in terms of making a lot of progress with a short amount of work. But then in 2009, we had, at that point, we had four products. We had, they all had separate username password databases, you know, and we wanted to unify them into one single sign-on and unified billing and everything. And it was this huge, anybody who's done that knows how difficult it is, right? You have totally separate apps and now you have to unite them all together. And this was the first time that we used some of the methods that later became the methods in this book, actually, because we had so much complexity in front of us that we had to solve that. So the methods like mapping things out into scopes, and breadboarding, a lot of those tools came out of that work. And then we later used the same tools when we rebuilt Basecamp from scratch for Basecamp 2 in 2012. And that was a really big success for us and went very, very smoothly. And a lot of these techniques were happening in a way that we didn't really have clear language for them. It was just something that we were a very, very small team still. We had grown a little bit by that time, but we were still very, very small. By the time we were working on Basecamp 3 in 2015 into 2016, we had more than quadrupled the size of our development teams. So we were from four people to, you know, from three people to like 12 people. And the product doing design and programming and the overall company had grown from four to over 50. And at that scale, you know, it's a little bit of a different world than it was before. And we needed to be able to really explain how we were doing things instead of just like watch and learn. You know what I mean? Like we needed words for things and language for things. And so we went through a process of learning how to describe what it is that we had found out over all these years. And at the same time, I started my role was sort of adjusting. So I went from design to a little bit of design plus programming, which allowed me to get up into sort of a Product management is a very confusing role because very few people know what it means. It usually means project management. In the beginning, it was a little bit more like project management, honestly, in the sense of how do we choose which part of programming, which part of design fit together and then finish that and then do something else. But then after we got quite comfortable with that, then I moved up into strategy, which is, I think, a natural move. questioning not only how to ship things regularly and how to have a healthy production process, but actually what is important to build, right? And how do we make decisions about that? And so all these practices sort of got embodied into the three phases of the book. We have the shaping, which is shaping is the terminology we arrived at to describe the fact that we don't just give teams tasks. which are too specific, right? And we also, they're too small and we don't give them projects that aren't clearly defined, right? And so this shaping process is how do we define the work so that we have clear boundaries and we remove a lot of risk and we know what we're asking for and it also fits within our appetite, right? The amount of time we want to spend on something, the amount of time we think it's worth strategically. And then the result of this shaping process is we have a potential project and it doesn't go into a backlog. It doesn't go automatically into some queue. Rather, it's something that is shaped enough that now we could bring it to the betting table and we could decide to bet resources on it. And when it comes to betting, we're not working in sprints and we are not working in open-ended projects. We have a kind of middle ground where we work in six weeks at a time. And this is how we manage our capacity. And the six weeks is not incremental the way that a sprint is. Actually, at the end, we shape the work to the six-week boundary. So very often when we talk about estimation, the whole notion with estimation is you start with work, you start with a design, and then you have a number, right? So if we want to build this, how long will it take? And what we do with an appetite and with shaping is the opposite. We start with a number. And then we come up with a design, right? Which is very different. It is. And let me tell you something. I was trying the other day to, you know, with one of my clients to try to, you know, ask them to do that exactly what you're saying. You know, don't think on how this thing is going to cost me. Just try to think the other way around. How much do you want to spend or how much are you willing to spend in that initiative, in that bet, right? Exactly. Yeah. But it's very difficult to try to make the switch. It's very difficult. Yeah, it is a different mind state and it requires actually that you do, you have to become more creative because you have to consider different possibilities for how it could be. It could be, because for anything that you want to do, there's a version that you could spend 10 years making it, six months making it or six weeks making it or two days, you know, and you have to figure out what trade-offs you want to make. And all of this is about making trade-offs, you know, and making the right trade-offs strategically to, to how valuable the work is. And so we've got the shaping part, the betting part, and the final part is the building part, which is when we make a bet, we don't give a team tasks. We give them the entire shaped project, which is like a boundary within which there's open space for them to work out the details. And then they use the different practices like scoping and factoring into scopes and getting one piece working. with a little bit of UI and a little bit of programming very, very early on a staging server, for example, these different things. So all those practices come into play. And actually the book came about because Jason, you know, Basecamp's founder pulled me in to a room last year and he said, I think it's time for you to write a book about this. And I said, you know, he was, he's my boss. So I said, I walked away from the room thinking, this is impossible. I don't know how to do this. I've never written a book before. So actually, in order to learn what to do, I just treated it like a product development problem. If the book is a product and I don't know how to develop it, what would I do? So I found a prototyping strategy. I decided to offer a full-day workshop in Chicago for a very small number of people. And I screened the people very carefully so that they would be the right people to help me learn. and delivered a day of content based on what I knew about how we do things. And actually from that I was able to do a sort of jobs to be done study by interviewing everyone who paid for the workshop and figure out what they were struggling with. And this taught me a lot about what's going on in a lot of teams out there and what they're struggling with. And there were really like kind of four main types of progress that people seem to be trying to make where they were trying to learn a better way for the way that they do product development. And the first one was somebody is responsible for product in a team, either a technical leader or a product management type person or a senior designer. And they're so busy with the day-to-day managing the team that they never have time to think about the future. You know, so it's like if they want to think about the vision of where to take the product next or what would be meaningful to do They have to do it on the weekend or at night because during the day they're just answering people's questions Right, so so give me time to think Give the team more responsibility and make them more autonomous so that they can just work without me and I can go think about what's important to do next right and the second one was teams who were founded who they were, this was mainly the founder or someone more senior in the team and they remember what it was like in the beginning when they could just do things very quickly, right? Then they hired some people and they've gotten a little bit larger and now the development is inconsistent, things take too long, it's not clear why things don't ship, right? And the thing is like help us feel fast again, you know, help us move quickly and be sure that something is going to ship. so that everyone can feel that feeling again of what it's like to just continually make progress. And then the third and fourth, the third one was somebody who's already been exposed to Basecamp's way of working and they're trying to convince their team, but they don't really know how to answer all of the questions that come up. So they're confident that this works, but they need to help their team feel more confident that it's possible to work differently. So help me bring my team along. And then the fourth and final one was, people who are struggling to get their idea to go from an idea to a reality. So this is an early stage founder or someone who's trying to develop a new product and they keep trying to tell the programmers what to do and the work that comes back is wrong and or it's not what they wanted and they're spending lots of hours and the work just keeps coming back and it's not the right thing and it's like help me figure out what I'm missing. What am I doing wrong here? You know, that's kind of a thing. Awesome. So you have basically applied the same thing that you are doing at your job with this kind of, you know, with the approach when you had to write, you know, the book. Yes. Yes. So those were the sort of the big things that I tried to address with the book and then unpacked everything that we do into some sort of a structure that spells it out. And that was my best effort. here we are today that's that's sort of the backstory that's that's great so let me let me try to tell if if some of the people on the on the chat has any questions just please put it on the chat i will be asking you know ryan some questions based on the on the ones that we have received but if you have any question right now that pops up into your mind just put it up there and we will be we'll be tackling that question um i have a i have a tons of questions uh ryan but i just want to mention one that you're saying that I love, you were talking about fencing the word because that will give you the boundaries of the people know where they can move, you know, the decisions that they can do within those boundaries. So some of the things or the concept that you have in the book are scope hammering, circuit breaker, you know, you mark the task with must be done or nice to have. You're talking about the appetite. You also mentioned, for example, when you have a project that they're like a three layer cake or questioning or icebreak, ice, you know, icebergs, starters. Yeah. A lot of these kind of things. How helpful is this when, for example, when you have to give the people something to do and they are not being caught up in this kind of useless soil when they have to approach that specific, for example, bed or project? How helpful is it? Yeah. Well, it's... It's helpful in a lot of ways. The first thing is if we didn't do that, then we could do what a lot of teams do is they take the project that they want to happen and they come up with this is what we think we want, right? And then they put it through, I call it the paper shredder, right? They split it out into many, many small tasks, and then they assign these as like tickets or issues and something like JIRA, you know? And then what happens is the person who is creating those tasks has the least information about the real work. Because there's a talk in the book about the difference between imagined and discovered tasks. So in the beginning of a project, all we know is what we think we have to do. room to to we so to say it more precisely we have to reserve capacity for the unknowns right now and so if we if we're only assigning tasks then there's no we'll fill all the time with the tasks that we think we have to do then when all these extra tasks come in and there's more work than it fits into the sprint you know now everything is delayed and now that we didn't finish everything we thought we had to do and now we have to do something else right So instead what we want is we don't assign tasks at all and we just give the overall, this is what we're trying to do. And we accept the fact that we don't actually know what the small tasks should be in the beginning. And this way the team can actually make judgments about which things to spend time on and which things to not spend time on. And we give them enough time, you know, six weeks instead of two weeks so that they actually have, they can actually succeed and they can finish that thing, you know. So this is very, very helpful. And the most important thing, if you change to this way of working, where you give them the whole project instead of tasks, is if you don't also give some guidance about how to spend that time inside of the six weeks, the teams will naturally do what they always learned, which was they'll just make up their own tasks and then they'll repeat the same problem, but for themselves, right? So this is why... we have this practice called get one piece done in the beginning of part three, which is the designer delivers instead of a pixel perfect high fidelity mockup, the designer delivers something very, very rough, very, very raw. And actually I'll show you, I'll just share my screen for a moment and I can show you what that looks like. Actually, it says that I can't it says the host disabled attendee screen sharing is it possible that That you can turn that on for me if not if not I can just talk it through Here we go. It's working now Okay, so can you see my presentation here good? Okay, so I'll just skip forward to this. So this is an application that we were working on to to record data from customer interviews using the jobs to be done method. And this is an early prototype of this app. And what you see here is that this was actually the design. This is where I stopped on the design and handed it over to programming. And you can see that the font isn't correct. It's using the default blue and purple browser colors. There's no buttons even. It's just text links for the different actions. And that's because The most important question in the beginning was how do I add it? See each of these bullet points actually needs a separate record in the database because these are all going to get clustered through some algorithm later. If I could have designed some interface here to add them right inside of this box and edit them and delete them and manipulate them all inside of this interface. But it seemed like much too difficult to provide all of those controls in a small space and over and over again for every one of these boxes. So the idea was that actually you could navigate to a different screen and then have this very simple interface where you just add them one by one and you can edit them and delete them here and you can click to go back. And at this point, actually every story was hard coded. So they all had the same name. They were all Tom. There was no way to log in. There was just this HTTP auth that we threw on it. Very, very cheap. The whole point was to prototype this one interaction of adding these pull data points. This was enough design to give to a programmer. You can see this is like one day of work. This is not some fancy high-fidelity thing. This is the first input and so in when the the the beginning of the of the six weeks You know if you have a lot of tasks to do and you give the team tasks you expect the work to look like a square wave Like they go from doing nothing and now they're working and then they finish the tasks and now they're doing nothing again, right? But real work on a project is more like a like a like a sine wave You have like this period in the beginning of the six weeks where you don't know how the existing code works, you have to familiarize yourself with everything. So there's this slow period in the beginning where nothing's happening, right? Then you start to get some design going and you start to wire it to a controller action and some modeling and now something is working and then you reach a point where everything is going and going and going. And then at the end of the six weeks, you don't just cut and stop, you know, but you actually allow some time to clean up. bit and look back and refactor and so on. This is the level of fidelity that the team delivers on, let's say, the day four of six weeks. Maybe at the end of the first week or the very beginning of the second week, the programmers are already implementing this with a simple model. This isn't throwaway code. This is the this is the foundation of building everything. Yeah, this is the thing that you are iterating over the different ways to try to, you know, make more, more stylish or wherever adding, for example, some particular, some particular style or interaction. Right. Yeah. So you can see how the design and the development are coming together on one small piece of the project first. Yeah. Right. And then after this, thing about adding the polls is settled then they can duplicate this over to the other sections like pushes and habits and then they can move on to other problems like creating stories or setting up projects or or the out the clustering algorithm that happens later or whatever it is yeah one of the things that i really like what you said is like at the beginning of this curve you know you you are we will be discovering things you know there will be a lot of uncertainty And the thing is that it's not as smooth. I mean, you don't go to the top one strike way. I mean, you are going up, you can go back a little bit because you discover something new. And that is the piece of the work where you're starting to discover anything that you haven't planned before. But since it's a little bit fencing, maybe the risk is, I would say, kind of controlled. At least you can mitigate it, right? Exactly. That's the purpose of the shaping work that came before. is to put that fence around. So if there are specific things about the project that are very, very technically challenging, or they involve connecting systems that we don't know anything about, we'll actually look into that during the shaping phase instead of just giving it over to the team and assuming that they'll be able to figure it out. We need to control our risk in that way. Got it. Could you talk a little bit more about, because you mentioned before, you mentioned about the scopes. Could you mention specifically in your term, what is your idea about the scope? Because for me, it's more like, I don't want to say it's like a bag, but it's something that contains some specific thing that are related. But I don't know if you created that specific word that you are using that word, that meaning. Yes. How do I say this? We can take a look at a project. Let's take a look at another example here. So the notion with scopes is we want to get to a place where if we just keep adding tasks and adding tasks, then we'll have a lot of things we have to do, but we'll never reach a point where we can sort of stop and finish and one whole piece of the project is over with. And so what we want is, this is the sort of mental picture that I have, is that unscoped work looks like this. It's just a whole bunch of things that have to happen and they're all mixed together. And this metaphor here, this is like the fence we talked about. This is the boundary of the overall project, but inside we have no idea. And now this is difficult because you might finish a lot of tasks, but if a manager says, so how's the project going? You say, well, you have to explain many small things to them, right? I finished this and this and this and this and this, but it didn't add up to anything big, you know? And at the same time, it's difficult to see which problems, which bigger problems in the project are finished and which ones are still open problems or unsolved problems. So we need some kind of a higher view. to work with, to deal with this complexity. And it's the same thing as if you were programming, you wouldn't put every single function in the same file, or you wouldn't put everything in one class, right? You would factor it out into different parts that have a single responsibility. So we're doing the same principle in terms of what is the work to be done, including UI and programming together, and factoring that out. So we can take all of this unscoped work, And then we can pull out, in this case, this was a project to do, it's kind of an email type application where you are sending messages to people and you need to be able to draft them and then get back to your drafted messages before you send them. So here what we do, we isolated a few tasks that were just related to the process of starting a new draft. And now if we finish these tasks that are a mixture of design and programming tasks, and we finish these, then we come to a point where, The universe of problems has shrunk. Yeah, right and something this one part is actually sure we know it will ship Right and so the scopes are the way that we find the scopes is actually by Looking at the real work, so it's not something that we do from our heads. It's more like you It's like it's it's like an animal that has anatomy You know you have to find where the joints are and how the muscle and the bone connects, right? As we go, then we learn how to group these tasks together into different areas of the project that we can think about separately and we can solve separately. This allows us to be more strategic. Now we can say, what's most important? Should I figure out how to save and edit a draft or should I figure out how to deal with deleting or navigating to an old draft? Then we get into save edit in this case and we notice that it's still actually quite a few things. We can factor out sending the draft email, right? Because delivery might have some whole other performance questions or plug into some other system. We can factor out storing versus some special case for replying. And then we can start to finish these things one by one. And then so there's kind of a dual purpose here. On the one hand, this is allowing us to become more strategic in what are we working on today and how will it finish and when will we be done. And at the same time, when I was talking before about the imagined versus the discovered tasks, since all the time new work is appearing, every time you go in and you do something, you realize, oh, I can't, I should not forget. Over in this model, this is also a thing that touches this other thing. You know what I mean? Yeah. So whenever that happens, you need a place to put that new work that you found. Exactly. So the scopes are also working as a basket. to put in this work that you discover, right? That you can say, oh, this work has to do with that over there and this work has to do with that over there. And that way you always know kind of where you stand in terms of what's done and what's not done at a high level. And you're not stuck in the small, small details and getting lost like that. Yeah, because when I was reading the book and I was looking at this technique where you're basically listing, you know, a lot of tasks that you have to do on that work, but you don't have yet specifically identified the different scopes. Yes. That it's impossible to know everything on that list, right? So what you're basically doing is to try to say, all right, I know that these two or three items are related. So that could be, for example, something that we can start to work on and finish. And there is something more that I need to add. to some specific thing and it's related to any of those scope, I can add it. And I imagine that when something comes up, you can say, is this something that we must do or this is nice to have? So you are able, as you say, you are able to prioritize and say, you know what, this is good enough for now, so this is something that we consider adding value. And we don't need, for example, to add this one that just came up, right? Yep, yep. I have a picture of that. So our naive idea our natural way that we think that tasks happen is that you begin with a list of tasks and then you complete them over time and then eventually they're all finished right? But when we really do projects it looks like this We complete some tasks, but then because we completed them we found new ones and we find more and more and more and actually Very often if we have more tasks to do We are closer to the end You know, in the beginning you think I have to implement the geocoder. Yeah, one task. Looks easy. Then you actually start to do the work and then you discover implement the geocoder means I have to change, I have to add a field over here. I have to change this. Now I have to change this other part of the model and I have to make a migration over here and I need test fixture data for this and the interface for that doesn't quite work. And now you have all these small tasks, right? And it looks like you have more work than you had in the beginning, but actually you have more certainty because now you actually know what you have to do. So very often when you have more work to do, but it's more specific, actually you are closer to the finish than when you have less work. And this is very counterintuitive because usually people say, well, how many tasks do you have left to see how much work there is? And it's the opposite. Have you ever had for example any experience with the I imagine for example that there are people they are already working with this kind of idea So they have this like a mental model when they have to you know create a scopes You know they have to get one piece done But what happened for example where you have new people working in these in these you know new fashion way Because for me it would be easier as soon as I start you know, I keep adding tasks because you know, it's whatever emerges, I would put it there. How do you help those people in order to avoid this kind of behavior? You know, keep adding tasks rather than, you know, putting and saying, you know what, this is the scopes, this is the thing, we got it, we're adding value because this is our baseline and so we're adding value. How do you help these people to onboard this process? Yeah, I think two things really help there. The first thing is the circuit breaker we talk about. There's an understanding that we set for the team that you have the six weeks to do the work, and it's a reasonable amount of work for the six weeks. We don't know the details, but we know that it's possible, right? And now we say, if you don't finish it at the end of the six weeks, then the project is a failed project. And we're not going to give it more time. Now remember, if you do that, you have to also give them lots of time. So you can't have meetings with them every day. You have to leave them alone. But if you give them this clear deadline, and there's actually consequences, and you also give them time to manage together. and to do their work without interruption, then this is the first thing. This gives them an incentive that they have to make trade-offs. They have to make decisions to separate the must-haves from the nice-to-haves. Otherwise, they will never finish, you know, and they know that, right? So this is very, very helpful to have this pressure coming at the end of the six weeks. And then at the same time, we also give them another pressure from the beginning, which is saying, The only thing that we really believe in as that shows progress is running code That I can click on that does something So deploy something to the staging server that does something and it can be rough Like we saw like that interface was very very rough, but it worked right? So we want to see something that works very very early and then we have this deadline right and so they keep Focus making decisions on what can we do next that will actually deliver something that that we can try and click on to show that we're getting closer got it and don't do things create a good incentive structure Yeah, don't show don't show me only pages that they're basically running on mock-up data Just don't you know, show me something that you have completely done integration between because the you all right, yeah, exactly exactly So we do vertical slices small vertical slices of front-end and back-end together right one after the other like that Yeah, it seems like when I was, you know, you use a lot of metaphors on the book, I was thinking that you are basically putting some kind of, you have the territory and there you are creating the map with the scope to try to see, for example, where, because I normally use, for example, use the story mapping, which is, you know, it's basically the other way around because you're starting at the very high level and then you're starting to map, you know. You need to go from the bottom up, not the top down. Because the idea is that the territory is a wild place that you never visited before, and you just got off your boat, and now you go explore the jungle. And then as you go, you will learn, this is where the river is, this is where the mountain is, and so on. But you have to actually, this is analogous to opening the code and actually trying to start to implement some things. And this is where you really learn all the details. Got it. You also mentioned about, for example, strategy. Let's suppose that, for example, I work at Basecamp and I want to present, for example, some particular, you know, some particular bet that I want to, I think that it's important and that bet goes to the betting table, right? So do you have any kind of North Star or something to try to, you know, tell people? or let the people know, for example, where the company is going so we can create beds that make sense with the strategy. Because I haven't seen that on the book, but maybe it's written somewhere. No, so that's not really explained in the book very well. Here's the thing. If we are giving projects to teams and we are giving them more power than before, right? Because we're not just giving them tasks, right? It actually means that during the six weeks, the teams are very, they're challenged and they're busy and they're doing difficult work that requires them to apply their expertise and their creativity and they have to solve problems and they have to make decisions, right? So what this means is that actually if we give more, we empower the team more, It's not very reasonable to expect them to have time for strategy. Right. That is that is outside the fence. Right. Right. Because there's so much work inside the fence that we're giving them to solve. Right. And so I think that it's very, very natural that you then you find that there's actually a boundary where inside the fence you have the people who are solving the unknowns inside of that. And then outside, you need to have the room to think about new things and to talk to customers and to talk to the people in the business, maybe your bosses or the people above you who are making decisions. So for me, it takes a lot of time and effort to try and do customer research and to... explore design ideas for the new feature that I think we might want to do to do the shaping work for that. But at the same time, I also am having interactions very often with Jason, the founder, because he's the one, him and David are the ones who are really making the decisions at the betting table. So I think the most honest way, and now I understand that this is This depends very much on the size of the company, how to answer this specifically, right? But at the size of our company, I think it's very important to be honest about how decisions get made. Decisions don't get made because you create a document that defines a North Star, even though that would be nice, you know? In reality, you have some people who are in control, and they do what they think is best based on how they feel that day. And that's how it is at the top of any, anybody who has the power to make decisions at the end of the day has to just make decisions somehow. And there's no algorithm because if there was a formula, then every company would copy it and we would all make good decisions. You know what I mean? So there is something, there is a place where it bottoms out and you can't keep using frameworks anymore. Absolutely. No, absolutely. So the notion is that I'm trying to have a good understanding of what is my opinion about good strategy. And this is according to, I create my own framework and my own model. And this is my idea of what's important. Jason has his own ideas and David has his own ideas. And then I'm also, because I work for Jason and David, I'm trying to understand what is important to them because there might be something that's a good idea for the product. But if it's not what, what, where the type of company or the type of product they want to create, it doesn't work. Right. So I'm also trying to really, um, listen to them and talk to them to understand what they value. Right. And then we work together like this. So this is, this is the closest I can give to an answer. I think it's a very informal, it's like the weather, you know, you try to feel the weather. And then you make decisions cycle after cycle based on your feeling and understanding of how the management is thinking. So what you have basically done is to try to optimize the time where you guys spend on the betting table. So everything that you need to make a decision is in every single pitch that is on the betting table. So you go there. I don't know how much time you spend choosing what are the best that you're going to... they're going to implement in the next six weeks. It's quite short. It's quite short. Yeah. And you know, that's how it is also whenever you have people, the person who's at the betting table is someone who controls resources, which means they're high up in the company and people who are higher in the company have less time. Yeah. So, so we can't, we don't have room for these out multiple hour meetings of grooming sessions and all this stuff. Nobody has time for that, you know? So what we want is to have some, a very small number, three to four, maybe, very well thought out ideas. Yeah. And then we, and then, and we bring them to the table and we look at them together and say, what's reasonable to do next. Right. Yeah. Got it. Got it. Um, you also have, I was, I was thinking when I was reading the Google so that you have this kind of period that you call cool down. Cool down. Yeah. Yeah. Have you, uh, because I, you know, I don't mean that to make any resemblance to SAFE, right? You know, in the SAFE you have this kind of last two weeks where you're having, you know, innovation and whatever you want to call it. But have you ever experienced with any other, you know, putting that time in, you know, place it that time into different, you know, different after, for example, an iteration of two weeks, then you have a cool down or you, for example, found that after six weeks was the best time to have these two weeks of, you know, fixing bugs doing some kind of adult work or whatever Yeah, so well first of all the six weeks is fixed for us Because if we if we do less than six weeks, we can't get anything meaningful finished, you know, you cannot Start everything and stop everything and then decide what to do again and start and stop. It's it's very inefficient It's very very inefficient and very expensive. It's too much overhead to work Two weeks at a time so so we so we have the six weeks then and i've seen some teams try you know five weeks whatever it's it's not a holy number but you know the idea is it's long enough to actually finish something and we don't have to keep having a meeting about what to do next right but now if we finish the six weeks and we learn this through our own experience our own mistakes if we finish the six weeks and we immediately begin another six weeks The whole time inside of the six weeks we're always trying to build something new right and finish it and that means that we'll never have time to fix bugs we'll never have time to to deal with like some kind of a Architecture problem with like you know some yeah some job is in the queue and it should be parallel instead of instead of cereal or something like that or you know these things that come up that you have to fix or something from support and something is a little bit broken and there's just no time to fix it so the two weeks creates a free space for all of these small problems that start to grow into a big pile. Yeah. Yeah. Yeah. And we even forgot that. So we solved this problem and we had the two week cool down. And then, you know, we got busy and then we thought, okay, we'll just shorten the cool down to one week, you know. And then everybody started to say, hey, I can't fix anything anymore. No, exactly. So it's very, it's important to have that time actually. Yeah, yeah, yeah, yeah, I got it. I was thinking because you know sometimes at this point I was saying all right in those six weeks What you have the people who are you know doing the building you are also shaping the next things that you're going to present in the next Yes, you know bedding table and I was I thought that those two weeks where the the period where you basically you know All right, you have been building you need to fix some stuff you need to do some kind of you know Architecture tweaking or I don't want to I don't want to say technical debt, but this kind of stuff that you, you know, you need to clean sometimes, uh, you know, your own room and then, and then start, start again after those two weeks. Yeah. One thing I would point out is that, um, we expect the technical debt to be clean at the end of the six weeks. All right. So we, we reserve capacity for that because, um, we cannot ship, we can't ship code and merge code into master that has all kinds of, mess in it that's not okay and so this is actually part of using time well inside of the six weeks or whatever this is I mentioned you know there's the beginning where you don't know what to do and then you gather steam but then at the end you have to slow down and cool and clean up after yourself before the end of the cycle is over actually right and that way this this two-week period the cool down is completely for other things you know other bugs random problems, things that nobody has a plan for. It's not, I mean, and you could use it for technical debt in the sense that as a programmer, every programmer will tell you they have a list of things, at least in their mind, that they wish that they could go back and change. Yeah. Right. But there's a difference between, the quality is okay, but you have a better idea and you wish it was different versus really like technical debt where something is, isn't right or it's badly made yeah you know so if they if they just wish to improve something even more you know to make it even better then they could use that time because they're free to use the time the way that they like or they could use it to fix some other bugs somewhere else all right so they are free for example to fix whatever they consider this necessary to fix right yes and it's important that this this cool down time is not scheduled in any way it's totally free Otherwise, you would have the problem of now you have to create a plan. Yeah, exactly. And then you don't get any, you never get to breathe, right? No, no, exactly. And the thing is that we get so much value out of the six-week cycle. We're really making a big, powerful push. And then everyone needs to be able to go, ah. Okay, and then just fix some small things here and there and then come back and make another big push again, you know. Yeah, now we know what you call it, cold cool down, right? Yeah, exactly, exactly. Awesome. So, you know, in the last episode, Ryan, we have Sandy, Sandy Mamoli, who she wrote a book about how self-selection leads people to, you know, to excel. How a team can, for example, select the work that they can do and also, for example, select the people that they want to work with. I read in the book and just you know correct me if I'm wrong but you are basically saying that one specific project you have you select for example one or two programmers and then one or two for example designers. Have you ever tried for example this experience where you know you give the people the bits that you are going to plan to do in the next six weeks and let the people decide which work they want to take on? So we have not had First of all, I haven't ever felt that we have a struggle or a problem with just assigning the work. The thing is that actually allowing teams to choose their own work is costly. It has a cost. It requires extra time and you have to facilitate that process. If some teams think that that is valuable, then I think that's totally up to them. In our case, we would not have the patience for that extra process because it's much faster and simpler to have the betting table and to have an overview of who's available and where people have the best skills. Because also, the ones at the betting table are more senior and they can make judgments about, probably this one would be better fitted for this person and so on. And then just make the announcement and say, here's the work, now go start. This is a one day one day of kickoff and get going versus if everyone had to sort of review the projects and then somehow speak together and also we're remote so I think it could be challenging remotely to facilitate that process of who wants to work with who on which project and how do you deal with a disagreement and so on so I'm not saying that it's a it's a bad idea but in our case we we would not want to make the trade-off to have that extra time and process we'd rather just go straight into the work Yeah, because I was thinking, for example, I don't know how many people are you right now at Basecamp, but I was imagining this, for example, like when you're like huge and then if you have to sign the work, that could be also challenging. And I assume that, for example, for the amount of people that you are right now, you can do that and it's better than having the people, you know, doing set selection. Yes. So when we have a betting table, we are only dealing with two teams. Two small teams and each team is one designer and one or two programmers and that's and that's and that's it and then we have two other teams That are doing product an iOS team and an Android team But they do their own shaping and they make their own decisions about what to do So so this isn't centralized to that point So if you only have two teams that you have to generate work for then it's it's it's much more efficient I think to centralize it Maybe it's different if you have if you have many more teams that are all running in parallel. I'm not sure. Yeah, I got it. I think there's a lot of room to experiment with. Yeah, if you're at different scales. Yeah, absolutely. Absolutely. That's because I want to I want to know if you have ever tried that. But I, you know, I thought that, you know, the amount of people that you are right now, that's not, you know, it's not worth it. Yeah, I am curious to hear we have a few I have some friends at different companies now who are applying these methods and some of them are quite large some of them have hundreds and hundreds of developers and They're in a totally different environment in terms of scale So I'm very curious to see kind of what they learn as they as they experiment and then how they adapt the method I was I was thinking the other day Ryan because you know I'm trying to start you know helping these kind of people with this kind of this is basically a bank, but they also have their own ideation process and then you have to handle that into developers, whatever, right? Now it's very, I would say it's like a phase with very identified, you can identify the silos across the process. And I was thinking, I don't know if you have ever tried, for example, do you think that the building part could work specifically when you're talking about the mapping the scopes and listing all the tasks, grouping the tasks in different categories or scopes or whatever. Do you think that that part could work if you are not, for example, doing all the shaping and the previous work? Just to try to see, for example, the people who identified the big picture and... Yes, that's actually how it is. For us right now at Basecamp, in most cases, Jason or I will do the shaping and then we'll hand off the work to a team and then the team does all the scoping and making the trade-offs about how to implement that. And if they feel that, there will be times where they want some kind of an input from the person who did the shaping. But it's not a... So, they might ask for review at some point, right? Or they might just even informally ask some questions. Hey, what about this versus that? How's this looking? And then Jason will give input or I might give input. But it's not a formal structure and it's not a, we are not really part of the team. And the team is ultimately deciding what to do. Right, so you're basically giving the team all what the team needs. to do that project. And if there is any question, of course, they can ask you, right? Exactly. So we can provide support if it's needed, but we're not part of the team. And then we're free to do other things. And then they have a lot of decision-making power. Got it. Got it. So, all right. I think we're approaching the hour, Ryan. We don't want to hold you up any longer than that. Before we close, could you give people, I will be sharing the links and the PDF to the book, to the Shape-Up, all the links, your tweet and how the people can reach out to you. Could you give us some kind of podcast information, books, people to follow regarding this product and strategy that you are basically following? The thing that I've been following the most myself has been Bob Mesta's work on jobs to be done. Yeah. And so a lot of the book, his work is everything that happens kind of before you start the project. Yeah. And it's kind of the strategic part of shaping. So how do we actually figure out what the important requirements are, what's important to customers? And how do we make the trade-offs in the design, in the shaping part? All that strategic work, the jobs-to-be-done stuff that he does, I think, is the best resource for how to learn to think more strategically about all of that and how to think about design really from the struggle of what customers are trying to do instead of kind of what's a cool idea that we can build, how to really make this shift. And there's a book that introduces this way of thinking called Competing Against Luck by Clayton Christensen. And Bob and Clay work very closely together. And so that's a good starting point there. And as far as other recommendations go, I learned by studying a lot of many, many things. But the problem is that they don't... I ended up writing something like shape up because I needed to synthesize all of it into one package because it was so much, you know, so I'm I took a lot of inspiration from Christopher Alexander's work. Mm-hmm the a lot of the the roughness of the work the way that that we don't do a pixel perfect mock and then build it but that we we work with very very rough work first this this is very much inspired by Christopher Alexander's books and then Eric Evans' domain-driven design and all that stuff was a huge influence from the technical side. All of these things are deep subjects in their own. I tried to do the synthesis work as much as I could in V1 of this here. It's the best I can put out there at the moment. Got it. Also, for example, your talk of Minded Product could be also useful where you're explaining, for example, the scopes. I think that where you introduced the concept there. Yeah, that was kind of an early prototype of trying to teach some of these things. Got it. And I am linking to some of the new, I've been doing quite a few podcasts lately, and I'm linking to them at the top of the ShapeUp website. So Basecamp.com slash ShapeUp. there's a few podcasts there right now and as new ones come that touch on something different or go into some interesting depth, then I'll also be adding those there. Awesome. Great. Yeah, I'll be sharing all of them. So, Ryan, thank you so much for your time. It's been a pleasure. I mean, a very, very kind conversation. I don't know if you want to say something, say bye to the guys, but again, thank you so much. hopefully we will follow you and if you want to come to Spain everyone I would give one of your workshops will be more than welcome to host you speaking is nice nice very nice yeah so I will see if we can find a reason to do that that would be nice awesome you know but thank you very much for inviting me and thanks everyone for listening it's been really nice to be here all right vice thank you so much guys all right appreciate it bye

In this webinar we have discussed how Basecamp is organizing its work using the Shape Up approach with Ryan Singer - Head of Strategy and Product at Basecamp.
Some of the resources and assets mentioned:
Shape Up (Book and Podcasts): https://basecamp.com/shapeup
Competing Against Luck: https://www.amazon.es/gp/product/0062435612/ref=ox_sc_saved_title_8?smid=A3LMYXXY2MF09I&psc=1
Bob Moesta's Twitter: https://twitter.com/bmoesta
Ryan's Twitter:  https://twitter.com/rjs