Transcript
Stefan Tilkov: Welcome, listeners, to a new episode of a CaSE Podcast, another conversation about software engineering. This is Stefan Tilkov, and my guest today is Ryan Singer. Hi, Ryan!
Ryan Singer: Hi there.
Stefan Tilkov: As usual, I would like you to start us off by introducing yourself.
Ryan Singer: Sure. I have been working at Basecamp for 16 years now. I started off doing UI design, basically web design, which I think meant something different that many years ago also... So I started off very much just thinking about what should be on the screen, and what are the flows going to be for a user to click through. Then when David created Rails as part of producing the first version of Basecamp, that was the first chance that I could really get closed into the programming side of things.
Ryan Singer: I had tried to learn programming many times when I was younger. I had always dabbled in it, but was never able to get very far, and then Rails made it much more accessible to me. So I went from there to combining a UI skillset with a programming skillset, and that naturally positioned me to start to play this kind of a bridge role between these two sides of the universe inside the company.
Ryan Singer: We released the first version of Basecamp in 2004, early 2004, and through the years our challenges grew. Our technical challenges grew, and then also taking on more people, and doing more with more people. I became interested in how to take a lot of the things that I was excited about that I was learning from the software community, about how to tame complexity, and how to separate concerns, and things like that, and how to apply that up at a higher level to how we do product development and how we think about bringing design and programming together at a higher level. That became my focus.
Ryan Singer: These days I'm doing mainly strategy, so I'm combining this background in knowing how to make things that work from a front-end and back-end perspective, with figuring out what's important, what matters to customers, what's competitively meaningful for us to do right now, and kind of figuring out where we stand and where we should go next.
Stefan Tilkov: Can you give those listeners who don't know the company and the product a very brief description of what Basecamp actually is?
Ryan Singer: Yes. Basecamp grew out of our own experience and the problems that we had early on, that we created Basecamp to solve - the same problems that many of our customers have today, our new customers who come to the product. Basically, if you're trying to do some kind of a project with a team, and especially if you are either remote or there's some sort of a time shift or distance between you, then what happens is you have a lot of emails, you have some chat over here, some Google Drive documents over there, some tasks in some other system, and all these things, this information is scattered in different systems, and then things easily get lost or slip through the cracks.
Ryan Singer: Basecamp takes everything that a project team needs to know to work together - all their discussions, all their notes, and all the tasks and milestones and deadlines and so on - and centralizes that in one place. It's very easy to use, so regardless of the role of the people who are involved, everyone can participate. It basically allows project teams to communicate and centralize everything, so nothing gets lost.
Stefan Tilkov: One of the things I've noticed over the years, and I'm pretty sure many people have noticed, is that you're very open about the things that you do at Basecamp, and you use every opportunity to share some of the things that you do internally... And that's actually the reason we're having this podcast right now, because one of the news things that you folks have shared is your internal development methodology, if that's what one could call it... It's called Shape Up. That's going to be the topic of this podcast. Before we dive into the details of that particular method, I'm very curious to find out what did you try before and what did you not like about it?
Ryan Singer: When we started, it was just three of us, and you know how it is when you are working on a really small team - you don't need that much formal structure. So much happens organically and just through understanding, and everybody knows everything, and there's a lot of overlap in your roles... So we didn't really need much structure in the beginning. However, we did have some very strong principles and some really tight constraints.
Ryan Singer: When we did the first version of Basecamp, David worked ten hours a week only, and he was the only programmer. So we had to be very judicious about what do we choose to do, what are we going to do next, how far do we go, is there a way to make this piece of the product work doing much, much less, so that we could keep moving? ...because we had so little of David's time. So from the beginning we had that in place.
Ryan Singer: I was exposed to the early Agile movement through David, and we were big fans. I think even the first book about Rails was called Agile Web Development With Rails, or something like that.
Stefan Tilkov: It was.
Ryan Singer: So the spirit of Agile was very much alive in what we were doing, and big fans of Kent Beck's work, and all of that stuff. At the same time, we never even went down the road of what's now become kind of off-the-shelf Agile; this sort of Scrum-type thing where you have two-week sprints, and some kind of a queue of work that you then groom into these sprints, and so on... We never even got into that, because we could see that two weeks was not enough time to get something meaningful done. And we've also always kind of been resistant to having some sort of a queue that we work off of. We'd much prefer to work based on what's in front of our noses, or the eureka from the shower yesterday, than a stale queue or some kind of a backlog. So there's always been some resistance to those things.
Ryan Singer: At the same time, we didn't know how to articulate what it was that we were doing. We were just trying to do what felt natural and what made sense to us, so we've experimented a lot over the years with "How do we take some of the key things that we figured out from our early principles and from early exposure to the--" I don't know what you call it; the original Agile, or something like that... For example, things like having a fixed time box and variable scope. You know, these very basic things.
Ryan Singer: We experimented with those in different ways, and as we met challenges of different sizes, then we had to grow our capability to meet those challenges. For example, we shipped the first version of Basecamp in 2004. By the time it was 2009, I think, we had already released a handful of different products. We had separate username and password databases and separate billing for each product, and we wanted to unify all of that. This was a big project we called 37 ID, and this really challenged us to start to step up how we manage our product development work.
Ryan Singer: When that moment came, we didn't actually reach for any existing methodology, we already started to experiment with our own ideas, and this was the first time where -- I had learned from the software side of things and from getting more deeply involved in the programming about things like factoring, and I wanted to try out this idea "What if we could do what we call "factoring" in the code at a higher level, to product?" So take whole pieces of functionality, both front-end and back-end, and decouple them from each other, isolate them from each other, and then figure out which ones to work on as vertical slices.
Ryan Singer: I think for people who have a deep background in Agile, this won't be a new idea, but we were pursuing that and trying it in different ways, without following any sort of script or any system that had been worked out from anyone else. We made plenty of mistakes along the way, but also it worked really well, actually, that project.
Ryan Singer: When it was time then to redesign Basecamp from scratch - we did that with Basecamp 2 in 2012 - we took a lot of those practices even further, and introduced a few new things that we were experimenting with. Then by the time that it was 2015, when we were redesigning and doing Basecamp 3, by then we had hired even more people and had met some different problems. This is where we were doing quite well with this thing, but there were still things that we hadn't articulated yet. So a lot of Shape Up comes from taking all these years of trial and error and finally putting language to them, so talking about things like "What does it mean to shape? What does it mean that we make a bet? How is it that we are more deliberate about making our commitments?", and especially dealing with the different types of unknowns and things that come up in the course of executing a project - you know, the language of uphill and downhill, and the hill chart, and so on.
Ryan Singer: All these different things were just an attempt to articulate what we had been doing intuitively, but then you reach a certain scale where you actually need to be able to say "This is how we do it" and have some language together for it. By doing that, we were able to talk with the people inside of Basecamp and the newer people we had hired about how we work, and it also opened up this opportunity to speak more broadly to the industry about these things. So this is sort of where the book came from now.
Stefan Tilkov: So you're offering the book for free... Is it open source, or free to read? I don't know whether there's a printed version...
Ryan Singer: It's not open source. We will be having probably a printed version and audio edition and so on, but this was really kind of a shipping strategy and a prototyping strategy. I've been making some pretty significant updates to the book; not in the main ideas, but in things that people are asking about that we didn't think to explain. So I've been making updates to the book, and the web is just a much more malleable medium than print. If you have to send a book out to print, then you have a really long night of thinking "Okay, did I fix every typo? Is it really ready or not?" Publishing it as a website just gave us that freedom of like "Okay, no big deal. If we miss something, we fix it tomorrow.
Ryan Singer: Now we're at a point where it's been received really well, and also there's been enough back and forth where I'm hearing the main questions that keep coming up again and again... So we're working on making some updates to it, and then we'll get to a point where we're ready for a print edition before long.
Stefan Tilkov: Okay. Let's dive right into it, and maybe we can start by you giving us the 60-second version of what Shape Up is about.
Ryan Singer: Shape Up is basically about the three phases of work that we have to go through. We are describing the actual process that we use to do product development, so there's some very specific techniques that we use. But at the same time, we're talking about all that in terms of what we see are the basic facts of the Universe. There are certain basic truths. For example, work doesn't come from nowhere. If you want to do a project, then someone has to define that project. And if you go through this process of what we call shaping the work, then you take a raw idea, a suggestion from a customer, or maybe the founder has a great idea all of a sudden, or something comes in from sales - whatever it is, there's all these raw inputs, and if we just sort of act on them and turn them into a project and say "Go build it", then we are giving the team a task that isn't well-defined enough, so we can't expect to have a good result.
Ryan Singer: On the other hand, if we -- and this is what's happening in a lot of Agile teams, by the way... Leadership isn't making decisions about really what to do and where they think the win is, and they're saying "Okay, let's go chew away at it, peck away at it two weeks at a time and hope that we figure it out." We want to be more deliberate about it than that. And then at the same time, if we go to the other extreme, which is the old waterfall extreme, then we're specifying too much upfront.
Ryan Singer: What we want to do is we have to define the work somehow, so the book is a lot of strategies for how to shape the work at the right level of abstraction, and with the right amount of latitude in it, so that there's certain -- we improve our odds and we improve our confidence for whether or not this piece of work can get done in the period of time that we allow, but at the same time we're also giving the teams more latitude, more autonomy, more room to self-manage within those constraints as they fill that in and figure out what the work actually is.
Ryan Singer: So first of all, we talk about shaping, and a big piece of shaping is the notion that we don't start with the design and then give it an estimate, and then slice it up and work at it, let's say, two weeks at a time. Instead, we actually start with what we call an appetite. So rather than saying "How long do we think this is gonna take?", we wanna say "How much time is this worth to us, strategically? How much time are we interested in spending on this particular thing?" And then, instead of having a design and then a number, we start with a number and then come up with a design. What's a design that's fitting to this appetite? There's some version of this idea that we could execute in that period of time. So that's the first third of the book, is shaping.
Ryan Singer: The second third is betting. This is where we take some shaped concept, and this is some kind of a potential project that we could do, that we've removed more risk from and we've done enough definition on that we know what we're betting on. We use the language of betting because we wanna talk about risk rather than talking about certainty. A lot of planning activities and scheduling activities that people perform are under the assumption that things are gonna go the way that you think... And they don't.
Stefan Tilkov: Surprise.
Ryan Singer: Anybody who has some background in Agile knows this as a principle... But how do we actually act on it in a better way? So one of the big things that we do is we cap our downside. We use the language of betting because a bet is where you put a certain amount of money on the table, and either you win or you lose, but you never lose more than the amount of money that you put down. And software development should be like this.
Ryan Singer: If we say that we think a certain project is worth spending six weeks on, then if we get to the end of that six weeks and the project doesn't succeed, we don't automatically reinvest, we don't give it more time. By default, we stop the project, we walk away from it and we do something else, because there was some kind of a problem in that work if it didn't finish, and we don't wanna just keep throwing bad money after good, or bad time after good. It's a crazy universe if the amount that you bet starts to multiply in front of your face; that's not something we wanna be doing.
Ryan Singer: Rather, we want to say "Wait a minute, something went wrong there. Let's do something else in the next six weeks that we understand, that we have more confidence in, that we feel good about betting on, and if we really feel like we need to go back and do that thing that didn't work out, let's do more shaping work to figure out how we can approach it differently, so that we can be confident that we'll succeed if we give it another swing."
Ryan Singer: This is really important. We call this principle the Circuit Breaker. It allows us to manage that risk, so that projects don't run away from us and start taking longer than they're actually worth in the first place.
Ryan Singer: And then the third part of the book is Building. There's two main things we're doing different there. The first is that we are not assigning tasks to teams, so we're not taking a project and putting it through the paper shredder and shredding it into separate tasks and then queuing those up in some kind of a plan for teams to take. So there's no stories, or cards, or anything like that. We're giving the whole project to the team, the whole shaped project. So there's boundaries for the team about basically what to do and what not to do, and the main outlines of the solution... But then the team has total latitude to actually discover and capture and track what the real tasks are.
Ryan Singer: We can talk about that more... There's a difference between the work that you imagine you have to do and then the work that you discover you actually have to do once you lift up the hood and get your hands dirty and start to get in there and find out what all the interdependencies really are, that you couldn't see in advance.
Ryan Singer: And then finally, rather than tracking what's complete and what's incomplete and managing time during the course of a six-week cycle, we are asking the teams to really think more about what's known and what's unknown, because this is where the real danger is.
Ryan Singer: If you have some work and you can very clearly see in the palm of your hand exactly what's left, then it's not so difficult to estimate, and maybe it takes a little longer than you think, but there's not a big mystery involved. However, if you get deep into a project and there's something that you actually don't know how to solve, or there's something that you think you know how to do, but you haven't actually gotten your hands dirty and started to look at what it's really going to take, or tried to spike it yet, those unknowns can turn out to be -- something you think is going to take a day can turn out to take a week, or something you were sure was gonna be possible can turn out to have no clear solution. There's a vast difference in these different risk profiles, of whether you know what to do or whether you haven't actually figured it out yet.
Ryan Singer: So that's how we do the tracking of the work, and we introduce a lot of tools and language for that, mainly the hill chart, and the difference between uphill and downhill work.
Ryan Singer: So those are really the three things - how do we define the work better, at the right level of abstraction, how do we give the work to teams by making bets that have very, very clear deadlines, with a circuit breaker, so that they don't run away from us and we don't spend more than our appetite. We work, rather than in short, two-week sprints, which is not enough time to actually get anything done, we work in longer cycles that are six weeks long, with a two-week cool-down in between. And then while the teams are building, they have full responsibility for discovering the actual tasks. They manage their own tasks, and they're mainly dealing with unknowns and knowns, rather than percent complete, or trying to track velocity, or something like that.
Stefan Tilkov: Okay. So I think I've understood the three phases of the whole thing. Can you map them onto the timeline for me? If it's six weeks and two weeks, does the shaping happen in parallel to other six-week things, or does it happen in the two-week pause between the two six-week slices?
Ryan Singer: The book is mainly written from the perspective of our current scale. Right now, Basecamp is around 50 people in the whole company, and the product team is around a dozen people. At our current size, you can specialize. You can have somebody who is dedicated to thinking about shaping all the time. And you can have separate people who are executing. That's a kind of luxury we have at our current scale.
Ryan Singer: So right now, I can be thinking about projects to shape, and I can be doing the shaping work just on an ongoing basis. Jason, the founder and CEO - he's kind of the last word on product at Basecamp; he does the same. So the two of us are mainly doing the shaping work, and from my point of view, we're inside of a six-week cycle right now. The end of that cycle is going to come, and then during the two weeks where we have this cool-down period between cycle, in the cool-down there's no scheduled work of any kind. So people are still productive, but they're not being told what to do. This allows people to do things like fix small bugs, make tweaks to the way that they coded things before, that they have a better idea about, investigate a new library, connect with people from another team... All these different things can happen in cool-down.
Ryan Singer: The main thing that happens in cool-down is we hold this so-called betting table, where we can decide what to do in the next six weeks. And I just need to bring some kind of a shaped idea - maybe one or two good shaped ideas to the table, so that we have something meaningful to do in the next six weeks. At our current size, we can do these as totally parallel tracks. So shaping can be completely parallel to building, and then in the cool-down we kind of have this betting table where we decide what to do, and that's how the work gets passed on, and that's how these streams cross.
Ryan Singer: Of course, when you're smaller, everybody just does everything. And even the six-week and the two-week structure doesn't really work well when you're really small, because you might have a founder who's -- like in Basecamp's case, Jason was a designer, David was a programmer, and I was there as a designer as well. And when you just have a few people trying to get started on something, you need to do a little bit of shaping so that you know what it is that you're actually going to do next, so that you know what you're taking on. But then you might say "We're gonna shape something for that takes us three weeks" and then build that out. And now the thing is built, and deployed to your staging server, and now you say "Okay, now we need to shape the next thing."
Ryan Singer: So then you're working more in a mode of alternation, and in a mode of wearing different hats, and just being conscious of what hat you're wearing, rather than having these different people for the different roles that are working in parallel.
Stefan Tilkov: Do you have more than one shaped up idea in the build step at any one time, or is it just one that you pass to the building stage?
Ryan Singer: At our current size, we have two (what we call) Core Product teams. These are teams of one designer and one or two programmers each. They're working on the main web product. And we wanna have work for those two teams every cycle. So right now we wanna have at least maybe three or four ideas that are shaped for a given cycle. We have this kind of internal language, we say "big batch versus small batch." A big batch is like one big thing, that's gonna take the whole six weeks.
Ryan Singer: We usually want to have at least one big batch project, because it's the feeling of making this big lump of progress on the product. There's this big thing that we're gonna do, and at the end of the cycle we're gonna ship it, and the whole product is gonna have this new feature or this new thing. So this big feeling of like "We made this big movement."
Ryan Singer: At the same time, there's very often a lot of smaller things that we wanna do as well, so small batches where we'll slot in kind of a handful of smaller projects. Maybe there's three or four things that we think the team could finish within the six weeks. And then we're not actually scheduling "By week two this will be done, and by week three that will be done." We're just sort of giving the team this small batch as a kind of bag of things to do.
Ryan Singer: Then it can be good to have more than one idea at the betting table, because it might be that something that I'm advocating for, maybe the other people at the table won't want to do, so I might want to have more than one idea to present. But the main thing is that we don't have a backlog of any kind. We don't have some sort of a long list of things that we've thought of in the past. Instead, anything at the table is being brought by a person, and being advocated for by a person because it's contextual and relevant and timely right now, and because somebody cares about it. So there's gonna be a few potential bets at the table.
Stefan Tilkov: Maybe we can go through the three phases individually, and start with the shaping thing first. What stage is an idea in if it enters the stage, and what does it look like when it gets out of that stage?
Ryan Singer: That's a good question. The input to shaping is a raw idea. I use in the book the example of building a calendar. In Basecamp 3 we didn't have a visual calendar of any kind. We had a kind of agenda view of events, which was just a list, and you couldn't see empty spaces at all. You just saw a list of upcoming events for the project. We had built calendars in the past for previous versions of Basecamp - they're very time-consuming and complicated to build, and we decided we could go without for Basecamp 3. Then customers were writing in the request, "Please, can I have a calendar? Please, can you make some sort of a month view in Basecamp 3?" So that's an example of an input to shaping.
Ryan Singer: Now, the problem is that if we just say "Okay, let's go do it", we don't know what that means... So we have to set some kind of boundaries on that. What is our appetite for that? How much time do we actually wanna spend on this? How much time do we think this is worth strategically? If we really believed that the future of Basecamp was with time management and calendaring, and scheduling the work to some degree, we could spend a year building a new version of Basecamp that's all about calendaring.
Ryan Singer: On the other hand -- actually, in this case we knew from past versions of Basecamp that only 10% of our customers used the pretty full-featured calendar that we had built in Basecamp 2... And that calendar took us six months to build. We knew that we just did not wanna spend that six months again. We were not up to that, and we weren't interested in that. But we did think "Well, if there was something we could do in a six-week project, then maybe that would be useful." So this is a case where we are setting our appetite and we're setting our constraints on whether or not we're gonna take some kind of an action on this idea.
Ryan Singer: Then the challenge becomes "Can we come up with some sort of a concept, some broad outlines of a design or a solution that fits within that six-week constraint?" And we didn't have any ideas for that, so we just didn't do anything about it. Eventually, we did some customer research and we talked to some customers, and we were able to determine what it was that they were actually asking about, and why they were asking for a calendar, and what circumstance they were in.
Ryan Singer: By unpacking the struggle they were in, we were able to get clearer design requirements to tell us - if we needed to build a tenth of a calendar, which tenth should we build? Should it be the high-fidelity interaction to drag an event or the borders of an event between hours within a day view, or dragging an event between cells on a month view? Or should it be a native calendar on the iPhone app? Or is it more about scheduling the overlap between people's availability to have a meeting, or something like that? There's so many different things we could do... We had to find the right tenth. And eventually we were able to do that.
Ryan Singer: Then what we created was -- the shaped version of this looked like a very, very rough hand-drawn sketch that showed how we could solve the problem that we had figured out, with a short presentation of the problem, a short presentation of our appetite... So "This is something we wanna do, but we only wanna do it if we can do it within six weeks. We've talked to customers; here's the understanding of the problem we came up with. Based on that understanding of the problem, here is why we think this is a viable solution, and here is a very rough (and this is important), a really rough sketch."
Ryan Singer: We have two sketching techniques I introduced in the book for shaping. One of them is called breadboarding, and the other is called fat marker sketch. Both of them are very low-fidelity, because what we don't wanna do is create some kind of a wireframe in advance, or some kind of a visual design that has a whole bunch of unnecessary detail, that wastes our time upfront, locks us into a specific approach that isn't necessary, and takes away latitude and freedom from the design team. We wanna give them as much latitude as possible.
Ryan Singer: We're trying to define the work at the right level of abstraction. If we define the work in words and we just say "Go build a calendar", that's too abstract. But if we define the work in high-fidelity mockups or wireframes, that's too concrete. So we're defining this correct level of abstraction to define the work. And then we're also eliminating different things that the team might put time into, that would take too long or lead down a rabbit hole. Things not to do, major holes in the concept, technical things that we've identified we should avoid, because they could just be turned into a big, nasty project - all those types of things we're also calling out.
Ryan Singer: The end result of this shaping work is if we get to a point where we solve all of these things, then we produce a document that's called a pitch. And the pitch is a potential bet. It presents some shaped work, and says "Here's what we're doing, here's what we're not doing, here's the sketch, here's the problem, here's the appetite, these are the rabbit holes that we're calling out...", and we see this as a kind of de-risked project, or a concept with as much risk removed from it as we can manage upfront... But it is upfront design. So we are, in a way, kind of swinging the pendulum back a little bit. With Agile, the pendulum swung totally away from upfront design, and we are bringing that back a little bit, but we are doing it at the right level of abstraction.
Ryan Singer: So what we're giving the team isn't a set of tasks, and we're not giving them a perfect bullet list of "It must do this, and do this, and do this, in this way and that way", we're giving them more like guard rails, or a kind of fence, or a certain boundary of what to do and what not to do, but within that there's a lot of freedom for them to work out what the actual design is, and to make all the hundreds and thousands of local decisions and judgments that are necessary to turn it into something real.
Stefan Tilkov: I'm sure at least some Agile practitioners will argue that they do the same thing with regards to defining just enough of what it is that's supposed to be built to enable people to make reasonable decisions... But I see that you're putting a different emphasis on the whole thing, and I think the betting thing you're really changing something in the dynamics of the whole thing... Because it's not somebody who has already determined that this is something that's got to be done; you've only made it something that could potentially be done. So I understand the difference, I think...
Ryan Singer: Yes, that is a difference. And at the same time, it's true -- I think a lot of the best teams are doing some of these things already... And what I'm trying to do in the book is give them language so that they can describe what they were doing more precisely, and then articulate what they did when it went well and what they did when it didn't go well, and then we can create contrast between teams that do this and don't. So by having the language of shaping, we can do that.
Stefan Tilkov: Two questions regarding shaping... One is what happens if something valuable that you do want to do simply doesn't fit into the six-week cycle?
Ryan Singer: The reason that we take six weeks as a constraint is because we don't believe that we can see further than that. For example, when we built Basecamp 3, we couldn't build Basecamp 3 in six weeks. We knew that it would take longer than six weeks to build the whole thing, of course. I think we had the idea of something like "Maybe by this date next year we'll be able to release it."
Ryan Singer: So we knew that it would take multiple commitments of some kind. However, we don't trust ourselves to say "12 weeks from now X will happen" or "18 weeks from now X will happen." We just can't see that far. There's just too many unknowns. So if we have something that we think is gonna be worth more than six weeks, still we have to set some kind of a target, we need to define an endpoint that we can actually see and understand and bet on. Otherwise we're just guessing, and we don't think that we can actually make a bet with good odds. So it's really a kind of time horizon...
Ryan Singer: For me, this goes back into the facts of the Universe category. Of course, if you're doing the exact same work that you've done in the past, you can maybe estimate longer. What we're talking about here - this goes without saying, probably - is novel things; the feature that you've never exactly built that way before. You've never built that exact feature before, which is where the uncertainty comes from. There is a horizon beyond which you can't really see, and what we want is to put ourselves, and we wanna put the team in a situation where they're feeling a healthy, productive back-pressure, where from the very first day the deadline is kind of pushing on them a little bit, so they're already making trade-offs and saying "Hm, I'd better start with this instead of that, because otherwise we might not finish on time." And of course, you have that if you work in a really tight timeframe. If you have a two-week period, then of course you feel that intensely from the very beginning, because the deadline is so close. But two weeks isn't long enough to actually finish something meaningful, so we've found that six weeks is more or less the right number. It's in that neighborhood of six weeks.
Ryan Singer: So what we'll do then is we'll carve off some kind of an endpoint of what we think we can reach that would be meaningful. So we say "At the end of the six weeks, if we execute this, then we'll be happy, and it will validate our belief in this bigger thing, and also it will allow us to make a firm bet." Another aspect of betting is that you hope to get a payoff, so you wanna have a capped downside, but you also wanna have some kind of a meaningful upside. So we wanna be able to say "Yeah, at the end of the six weeks, if it goes wrong, at most we will have lost six weeks. But if it goes well, we will have reached this defined end goal that we've shaped, and then we can celebrate together and say it worked and we got there."
Ryan Singer: Then what we will do is we'll shape the next thing to do subsequently. And we only bet one six-week period at a time. It might take more than one cycle to finish a given piece of work, but we don't believe that we can see exactly what that second cycle is going to be until we get the first one done. But we will shape that before we bet on it, so we're not going to just automatically throw another six weeks at something. We're going to stop and say "Okay, wait a minute, what does the next week look like in terms of the end of that six weeks? What is it that we think that we're aiming toward, and strategically, are we spending our time on the right thing?" And then we'll shape that and pursue that and then go on like that.
Stefan Tilkov: My second question - and hopefully the last question regarding shaping - is do you actually gather user feedback on the idea? Does that help in the next phase?
Ryan Singer: The way that we think about this - we are just very skeptical about any type of feedback on something that isn't released. It's so difficult to artificially reproduce the real-world context that creates -- how do I say this...? Context is what creates value; you can't value something unless you're actually in the context. So we could, theoretically, show some feature in progress to customers and say "Do you think this would help you?", but we just don't believe in that. We believe in releasing something, and then allowing customers to actually encounter it in their real life, in their real context, and then, if it works for them, we'll really know. And if it doesn't work, we'll really know.
Ryan Singer: So there's things that we can do to interact with customers to improve our understanding, but what I wanna do is I want to deepen my understanding of the problem they're in, and I wanna deepen my understanding of how they're struggling with whatever is presently available to them, without the new thing that I'm building. And then we call that the baseline.
Ryan Singer: So if I can really understand what they're doing today without the new thing, how it's going wrong for them, what progress looks like for them, then I see it as our task to do the design work and the solution work to fill in that negative space that we've defined by better understanding the demand side. So we use the language of demand vs. supply side.
Stefan Tilkov: Okay.
Ryan Singer: I don't think there's a way around taking that risk of not really knowing what the solution is and not really knowing if it's going to work, so we'll talk to customers to better frame our understanding... But still, the only way to really learn is to release something.
Stefan Tilkov: I have a follow-up question. Do you actually take things away again, from the product? Because you're taking a risk; you're just taking the risk that you're right, you're sort of betting that you have a good understanding of the market and the product, and you're building something that's meaningful and valuable... But of course, that risk would still be there if you showed them an early sketch, I’m aware of that. But still, I'm just wondering, do you actually retire features if you notice that not enough people use them, or how does that work in the product?
Ryan Singer: That's such a great question. When you have a brand new product and you have a small customer base, you can get away with taking things away. As soon as you reach a certain size, the absolute numbers are so big -- at our current size, the absolute numbers are so big that if 5% of customers use something, it's still a lot of people. So from where we are now, shipping -- I think once you get out of the very early phase of trying to figure out what the product should be, and reaching product-market fit and so on, shipping really is a one-way street. And it's part of the risk that you take, of betting on something... That "You know what - we're gonna have to probably live with this thing for the rest of this version of the product" or "We're gonna lose this free space in the interface forever if we put this thing here." So I think that's actually a part of the risk, and a part of the risk to really take seriously.
Ryan Singer: Of course, we can iterate on something. If we release something and we find out that very few people use it, then -- there was still something that motivated us to do that project that we were trying to solve, that we understood as being some kind of a problem or some kind of a struggle. So we could in the future shape a new project that ends up changing that part of the app because we've improved our understanding of what the problem really was, or how to go about solving it... In which case we might be able to take that thing that didn't work and turn it into something that works better. But it's true, outright removing something is very rarely possible. I think it's better to actually just think of it as a one-way street and take it as part of the risk of making the bet.
Stefan Tilkov: Understood. Would maybe putting out experimental features solve part of that problem, or is that a stupid idea?
Ryan Singer: I think you have to make the commitment... Because if you put out the experimental feature - what is that really saying to customers?
Stefan Tilkov: I get the point, yes.
Ryan Singer: So we don't wanna be in that position, we'd rather just take on the risk.
Stefan Tilkov: We're now at risk, so I think it's the stage where we're entering the betting phase/process. So how does that work?
Ryan Singer: It's quite simple in practice. It's mostly just changing the perspective. The big shift here is we want more trade-offs to be made higher in the company. Very often what happens is the people who are at the leadership level of the company are basically saying yes to everything... Like, "Yes, that's a good idea. Put it on the backlog. Yeah, that's another one. Let's do that, too. Oh, let's get to that as soon as we can." And what happens is you're saying yes to everything, and then pushing that down to the teams, and then the teams are under a constant pressure to somehow fit everything together and get it all done as fast as possible. And of course, this leads to all kinds of problems. It leads to bad morale, it leads to technical debt, it leads to all kinds of problems.
Ryan Singer: One of the biggest problems that you get out of that is a lack of strategic clarity. I'm actually starting to come to the belief that a lot of people who have the title "Product manager" today are actually project managers... Because they're being tasked with more work than there is time, and it's their job to juggle time and resources, to just try and somehow get it all done, even though it's not really possible. So you need to hire somebody then to play this game of Tetris, to try and squeeze everything together into a small box.
Ryan Singer: So what we're trying to do with betting is we're trying to make the trade-off higher in the organization. We want the people who really control the resources to say "What is important right now, and what is not important? What risks do we wanna take, and where do we wanna put our time?" This notion of being really deliberate about what is meaningful right now, and then scheduling a team to do that, and only that.
Ryan Singer: Maybe I'll try and put these points together that we've already touched on a little bit... So what makes a bet - the first thing is when you're making a bet, you have a capped downside, as we talked about. The second thing is you're making a bet because you hope for some kind of a pay-off. So we've shaped the work, and we have a clear end in sight, and we think that at the end of this amount of time that we're betting - let's say the six weeks - that something good is gonna come out of it that we can actually see in advance.
Ryan Singer: Then there's the third point, which is that if you make a bet, you honor it. You'll get into trouble with people if you make a bet and then you walk away and you don't pay. So what does it mean to honor the bet? In software, it means "Leave the team alone." Give them the work, set the clear expectations through the boundaries defined in the shaping of what it is and what it's not, and what the end is like, and then leave them alone. Don't go to them and tug at their shirt and say "Oh, but I just need you to do this one thing", or "It'll be really quick. Just do this one thing."
Ryan Singer: Every time that you interrupt the team, you of course lose the time for the interruption, but you also lose the momentum that they had built up, and then you lose the time that it takes to spin up again, and you lose the interaction between other people if they had all been available at the same time to help each other. So there's massive costs from interruption.
Ryan Singer: Betting is really about taking the resources that we have, the people who are available, and lining them up and then saying "They're only gonna do this one thing for the next six weeks, so what would be the most valuable thing?" And the way this actually happens is, in practice, through some fairly short conversations.
Ryan Singer: Too often I hear horror stories from teams where they have to have these -- especially if they're using sprints, then every two weeks they have some kind of a meeting where they all have to decide what to do next. Sometimes they call it a grooming session, or whatever... And these meetings can be four or five-hour meetings, with too many people involved, and a lot of unclear discussion, and they're just painful.
Ryan Singer: If you have shaped work that you're bringing to the table, meaning someone has actually thought a lot about this work, and you have a very small number of people who are actually in the position to make the decision because of where they sit in the organization, then what you can have is a quite short, maybe hour-long discussion, that is very dense and very meaningful, where all the questions that are raised have good answers.
Ryan Singer: The work of defining the work is work. So often, unless you're creating a wireframe or implementing the view, making commits to the pull request, people think that you're not doing real work. But figuring out what to do is work, and it takes time. And very often what happens is when we get into these meetings to decide what to do, nobody was allowed to sort of go deep and actually figure out what is the right work... And that's what we've done in the shaping process.
Ryan Singer: By having that as an asset - that's an input to the betting table. And then by having a small group, who are the right people, we can have a very potent, intense conversation. Also, the higher people are in the organization, the less of their time is available anyway, so you sort of have to be productive in less time. That's more or less what the betting table looks like. For us it's four people - it's Jason, the CEO, David, the CTO, myself, and then Jeff, a very senior programmer is very often there. That way we represent both the customer-facing side, the technical side, and the strategic side. All these things are brought together.
Stefan Tilkov: The assumption then is that the people who are involved in that betting table process - or do you just call it the betting table?
Ryan Singer: Yeah, just the betting table.
Stefan Tilkov: The people who are at the betting table - they need to be able to understand the consequences of what they're deciding there. They need to be technical enough to understand or be able to judge whether that stuff will actually fit into a six-week cycle, right?
Ryan Singer: Yes. They need to be able to judge that. That needed to happen in the shaping process as well, so that's something I didn't mention earlier - there is a step in the shaping work where if the person who did the shaping was deeply technical, then this is already there in the work that's coming to the betting table. If it was more of a designer person who was leading the shaping work, they do need to pull a technical person in at some point during the shaping to say "Hey, tell me where I'm wrong" or "Is this as feasible as I think it is?" or "Are my assumptions correct about the interdependencies here?" and so on. But that's absolutely true - there is a judgment call there saying "Is this thing something we want to do? Is it strategically the right thing to spend the right time on? Is this the right time?"
Ryan Singer: Sometimes something can be the right thing, but it's not the right time, based on maybe you did the exact same type of work in the last project, and it's gonna be a dip in morale for people if they're doing a repetitive kind of work. Or maybe it's a really good idea, but something else came up, in some other corner that hasn't gotten attention in a long time, or whatever. So it might not be the right time. And then the feasibility is of course a key thing.
Stefan Tilkov: My initial reaction would have been "Well, that's not a good idea, because you're not involving the people who are actually doing the work", but you mentioned before that you're not determining the exact thing to be done, you're just shaping something that's then to be filled in by the actual team doing the work, right?
Ryan Singer: Yes.
Stefan Tilkov: It's rough enough so that you don't feel bad about passing that to a team that then has to deliver it, because they haven't committed that they're actually able to deliver this in some particular form; they're just expected to--
Ryan Singer: Yes.
Stefan Tilkov: Okay, understood. Are they allowed to say "Yeah, that was nice thinking, but it's not gonna happen"? Can they reject something and say "Yeah, not doable"?
Ryan Singer: I don't think so.
Stefan Tilkov: Or has that simply not happened before?
Ryan Singer: I don't think so. That's never happened at the macro-scale of "This is what we wanna do. This is the project. Team, please go do it." At the micro-scale, that happens very regularly though. So there might be some aspect of the shaped project, and then once the team starts to actually work on it, they have better information than anybody else had... Because the amount of information you have upfront is, of course, very limited. So it can happen quite often that the team gets involved and they say "You know what - this aspect of it is not working the way that we thought it would" or "It's not feasible the way that we imagined. We have this other idea; let's take this other approach instead." But this is very rarely happening in one of the (let's say) pillars of the idea. It's quite unusual for that to be something foundational to the concept.
Stefan Tilkov: Maybe to conclude the shaping phase discussion, one term you've mentioned a number of times is the appetite. Can you elaborate a bit on that?
Ryan Singer: The appetite is just referring to what maybe many listeners have heard before in the notion of "fixed time, variable scope." So it's just a question of "What is the fixed time for that variable scope?" It's a strategic question. If we start with an estimate, then we are committing ourselves to whatever our initial assumptions were about what the solution should be. We come up with some sort of a design, then we put a number on it, we say "This is how long it will take", and then we can immediately -- too often we immediately go into trying to do time management in order to figure out how to get that thing done. And what we wanna do is we wanna stay away from time management as much as possible, and instead do scope management.
Ryan Singer: Scope management is design. We wanna say "If this thing, because of our strategic understanding of it, is only worth this period of time, then we want to create a situation where everyone is making trade-offs in their design decisions, so that we can come up with some kind of a scope that fits within that time box." So it's really about creating the forcing function. The appetite is a forcing function on the design process, so that we make trade-offs in the design, to arrive at something that can be done within that period of time.
Ryan Singer: And sometimes it's not possible. There are intrinsic sizes to certain things. If you have to do XYZ in order for the functionality to perform, it may be that it's not possible to do it in less than a certain period of time. But if your appetite doesn't meet that minimum amount of work to do the thing, then you don't do it, because you say "Well, that's what it takes, but strategically we're not interested in doing it."
Ryan Singer: In most cases, there is so many different ways to attack a problem, and there are so many levels of detail you can go into, and things that you can improve and things that you cannot improve, and there are many trade-offs to make about how far to go, in which aspect of the concept. So this scoping thing - there's a lot of latitude there, and it's very important. This is our biggest secret weapon throughout the entire history of Basecamp - our ability to do this; to make deep cuts and trade-offs in what's actually important about the design and then just build the things that are important.
Stefan Tilkov: So I just assume that - well, you've actually mentioned that before - you'll have a number of ideas in shaped up form, or shaped form, and you only have a limited budget in terms of time and effort and person hours that can be spent on the whole thing, so you pick the best ones, the ones that have the most support... Do you actually attach a budget to each individual idea, or are they all passed to the teams as a whole? So is there a way if one thing takes a little less than the estimated amount - can that be invested in the other? Or is everything limited to exactly what you were willing to invest for it? Phrased differently, is the investment that you sign off - is that a person day amount, or is it just "This is gonna be the next cycle"?
Ryan Singer: We keep this very simple. Either the team has been given a project for the entire six weeks, and then that's all they have to think about - build this thing within that period, and it should be done at the end, and that's it - or we'll do a handful of smaller projects. If we do the handful of smaller projects - we call it the small batch - occasionally we might specify "This thing is worth three weeks and that thing is only worth one week." In practice very often we'll just give the 3-4 projects - whatever they are, these small things - to the team and say "Look, we believe these things can all be done within six weeks. You can tell what that means – figure it out"
Stefan Tilkov: Okay.
Ryan Singer: Time management is very costly... So the more that we can avoid time management by just using big time boxes, and then relying on the teams to self-manage their decisions for how to get it done, the better off we all are.
Stefan Tilkov: Good. So on to the final phase then, or the last phase of the three, which is the build phase. What's special about that?
Ryan Singer: The first thing with the build phase is, as we've mentioned before, that the teams are figuring out what the work is within the boundary of what was shaped. So they're not working off of a queue, they're not in this sort of code monkey/grunt work role of just pulling tickets and then completing the tickets. Everybody knows why those things are bad; it's not fun to just work off one ticket after the other. This is not good for morale. It's also not good for the outcome of the actual functionality and way that the work integrates.
Ryan Singer: This goes back to the analogy of the paper shredder - you shred the project into tasks and you kind of hope that they all glue together in the end back into what you thought, but usually that's not the case... Because if the definition of success is checking off a task, that's a very different definition than saying "The definition of success is the project as shaped works in a meaningful way." So what we want is for the teams to discover their own tasks and capture their own tasks and manage their own tasks, but we also want them to take responsibility for thinking about how all the work integrates together into a working whole. So they're really thinking about the whole and not just executing parts and saying that how it all weaves together is somebody else's problem. That's a huge aspect of it.
Ryan Singer: So when the team starts to build, we set an expectation that something should be live and clickable. Something should do something on a staging server, very early. Let's say by the end of the first week, or at the very latest at the beginning of the second week. And in order to do that, the designer is going to produce some design that isn't final. The level of fidelity that the designer delivers, so to say, to programmers or commits to the code is much lower. We don't need to have the final colors and the final layout and everything in order for a programmer to implement something. All the programmer really needs are the affordances, the endpoints; they need to know "Is all of this happening in one form, or is this happening across multiple steps?" And whatever form it's happening in, what are the components and how are those components wired together? That gives the programmer all the constraints they need to figure out how to wire the controller, and what the model needs to be behind that, and connect those things.
Ryan Singer: We're encouraging the team to make it work before they make it beautiful. So there's gonna be a little bit of design, a little bit of programming, and then those things are gonna be integrated together, and it's all gonna happen around some specific, small core piece of functionality that's interesting to see first. Of course, it's not interesting to see username/authentication first, because this is a problem that's been solved a million times; it's not telling you anything about the domain, you're not touching any of the things that are interdependent in the problem, that are gonna help you to feel confident that the feature is coming together.
Ryan Singer: So they're picking off something that is small, something that is central to the problem, but also something that is not so deeply entangled with other things that they can actually click on it and get it to do something quickly; something that's isolated enough that they can make progress on it. So that's how they get started. And as they work, this -- we've been talking about filling in this space within the boundary of the shaped work, and we can think of this like a wilderness or like a territory that hasn't been explored before. So as the team actually starts to look at the existing code, and spike out approaches to some of the things that were shaped, and put a little bit of design together, they start to learn how the existing system works, how the solution is going to come together, what's going to work and what's not, and they figure out what the actual work is in the implementation side.
Ryan Singer: This process, as they walk the territory, they can start to create a kind of map, of "There's this concern over there..." Just like when you're doing coding - when you first start to code something, you don't see how to factor it into separate -- whether it's classes, or methods, or if you're working functionally, how do you pull this apart and untangle it into different responsibilities. You can't see that immediately. But after you have started to pull on the thing from different directions, you can feel "When I pull on this piece, that other piece comes along, versus when I pull on this piece, it just comes away by itself."
Ryan Singer: As you learn where the interdependencies are in the work, you can start to map out the boundaries between things and you can sort of decouple and isolate things from each other. And what the team is doing is they're identifying slices of the project that they can complete front-end and back-end together... So where can they integrate front-end and back-end, and then have a whole sort of area of the map that they have identified, that they can then say "This is solved, this is integrated. You can click on it and it does something, and the universe of problems that we need to solve has shrunk."
Ryan Singer: That's the kind of activity they're doing, and we call those separate pieces of work where front-end and back-end can be integrated and that piece can be completed sort of orthogonal to the rest of the project, we call those scopes. And we call this activity mapping out the scopes. So they're doing that.
Ryan Singer: The last piece of building is how do they actually show progress and figure out where they stand with regard to these scopes, and here is where we use the metaphor of the hill. Every piece of work that you take on, even if it's something that you are quite sure that there's some solution to it, you don't actually know what the final form of the solution looks like until you start to get involved and start to work on it.
Ryan Singer: This beginning to connect it, this "Is the API where I think it is? Does it connect with the library the way that I expect? Is the existing code where I think it is? Oh no, there's also this other module over here that has a dependence with that. Aha, okay." All these things - this is compared to walking uphill. As you're going up a hill, you can't quite see where the top is, if it's a steep hill. But then eventually you reach a point where you're standing at the top of the hill and you're like "Okay, I've got this piece working, that piece working, I've seen all the existing code...", and now you can see down the other side. You say "I know the approach, I've seen everything, I've touched the real code", and now it's more like "I have to tighten a screw here, and I have to tighten this, and I have to wire that together", but there's no unknowns anymore. It's all certainties.
Stefan Tilkov: Everything's downhill from here.
Ryan Singer: Exactly, everything's downhill from here. So there's a major qualitative difference between these two phases, and every scope has this. So what we want the teams to be able to do is report on where they are in terms of uphill and downhill on each scope that they're working on... And this tells us something very important about the risks. If we get to the end of the six-week project, and let's say we're in week five, and there's a bunch of work that still isn't finished - let's say a little bit too much work is still unfinished - but all of that work is plotted on the downside of the hill somewhere, either immediately at the very top of the hill, or maybe down toward the bottom of the hill, where there's just a little bit left to do before it's fully executed... If that's where the work is, we're not gonna feel bad about throwing another week or another two weeks at the project. By default, we don't do this, as I mentioned before, with the betting and the circuit breaker... But when we consider whether to do it or not, we would lean towards saying yes if all the work is downhill.
Ryan Singer: On the other hand, if some important piece of the project isn't done, and it's not only not done, but it's uphill, that means that there might not even be a solution for that. So this is a totally different category of risk.
Ryan Singer: So the team now has a way to communicate where the work stands in terms of known and unknown, but then they can use this as a feedback mechanism for themselves to make sequencing decisions. So the team, because they're self-managing and they have this big period of time of the six weeks to fill in the shaped work, they need to make good decisions about which problems to solve in which order. And what the team is going to do is they're going to prioritize getting anything that's important to this project over the hill earlier.
Ryan Singer: For example, there might be a few very important key pieces of functionality to a project, and rather than getting the first scope over the hill, and then after it gets over the hill completely finishing it to final execution, they'll often actually let some work stand at the top of the hill and say "Okay, you know what - that's good enough. It's not done yet, but we've isolated it, we've mapped it out as a separate scope, it's over the top of the hill... We'll come back and finish the execution later. Let's go turn to this other problem that's completely at the bottom, that hasn't climbed the hill at all, and gain more certainty in that."
Ryan Singer: So then they reach a point where maybe by the second or third week of the project the most important things are all over the hill, and then they'll switch modes and say "Okay, let's just execute, execute, execute, and get all the downhill work done." This allows them to reserve capacity for the unknown.
Ryan Singer: So first there's a question of identifying known versus unknown, and the second question is we have to reserve capacity for the things we don't understand, because they could very well take multiples of how long we think they're going to take. And then the team does that by sequencing.
Stefan Tilkov: Okay. The easy the case would be they finish some form, some possibly slightly differently-scoped form of the original shaped project they were supposed to do, everybody's happy, everything's fine, they do some little finishing work in the two weeks after that... That's sort of the easy path. What happens if things go wrong? If at the end of the six weeks they haven't delivered it? Do you table it, reschedule it later? What do you do with that? ...because they've done a lot of work, and there's a lot of effort invested. I know about the sunk cost fallacy, but still I'm wondering - do you simply throw everything away, or what do you do if you don't win your bet?
Ryan Singer: Right. What we now have is a pretty rich toolset for a debrief... Because now, if the project goes poorly, if something goes wrong and it's not finished at the end of the time that we bet on, now we can have a conversation where we can say "First of all, was the problem in what we shaped, or was the problem in the performance of the team that was filling in the shaped work?" Those are very different things.
Ryan Singer: You might look back at that work and say "Look, this was very clearly-shaped, and we set clear boundaries on it, but maybe this programmer who was working on it completely went on a yak shave and -- they had clear boundaries, but they didn't respect those boundaries, or they didn't make good judgment calls about how to fill it in." And then you have maybe a performance question... Or who knows, maybe there's something personal going on with that person and it was just a very short-term performance problem. That could happen.
Ryan Singer: It could also happen that you say "You know what - the team made very good decisions, but the way that we shaped the work... Nobody could have anticipated this thing that we left out of the shaping." Or it could be "You know what - we actually shaped that work in a rush. We didn't think about it very much, very deeply. We were busy with some other things, and then at the last moment, before the betting table, we kind of quickly whipped this idea together and we hoped that it would be fine."
Ryan Singer: So already then we have very different next steps. If the work was shaped really well and it was a performance issue, then you have some sort of a follow-up to address the performance issue. If the work was not properly shaped and you have feedback to the shaper - that's where the learning process happens.
Ryan Singer: If the work didn't get finished, but all of the work that did get finished was done well, and everything that was finished to what was shaped happened as expected, so the performance was good, the shaping was good, but somehow it still didn't get done, then we have the language of uphill and downhill to talk about our risks. This downhill work is a little bit like you're at the end of assembling the IKEA furniture, and there's four screws in your hand and you look down and you see four holes in the chair, and you say "Okay, no problem." If it feels like that, then you can throw an extra couple weeks at the project and everyone can feel very confident that it's gonna go well.
Ryan Singer: On the other hand, if you're at the end of assembling the IKEA furniture and there's some piece of wood that -- the cabinet's finished but there's a piece of wood lying there and you don't know where it belongs, then you say "Okay, we have a deeper problem here."
Stefan Tilkov: I hide it and don't tell anyone.
Ryan Singer: Yes, exactly. Or there's a piece of functionality that's missing and no one actually can see exactly how to go about putting it into place - then you have an uphill piece of work that's left over... And if that's the case, it would be very risky to reinvest. So then what we can do is we can either say to ourselves "Well, we could hold a very emergency shaping session in the cool-down, to see if we can figure out this problem", and if we can shape a solution to it, then we could feel comfortable betting again a certain number of weeks on finishing the work.
Ryan Singer: Or we could say "This problem is too scary" or "This unknown is too fundamental." We had a case like this once where there was a piece of the design that we just assumed this designer would solve, and we didn't shape it, and when it came time for the designer to solve it, it was like "You know what - I don't think there's any good answer to this. I can't come up with anything that seems to work well." And then we all looked at it and we said "You know what - this is a hole in the project that is sinking the project. It can't survive this hole." If that's the case, then we're gonna have to really deeply come up with a different approach.
Ryan Singer: This goes back -- there's no conveyor belt or cue that now this shaping has to think about this but rather it goes back into the field of shaping, where if someone who's responsible for shaping feels that they're still interested in it and they're optimistic about finding some solution, then they might pursue it... Or if everyone feels totally stumped and there's just no path in sight, then you just set it aside and you do something that is better-shaped, that's totally unrelated in the next cycle, and you wait for a eureka in the bathtub one day, or for some new information to come across to you that changes things, or whatever.
Stefan Tilkov: Good, I think we got through the three phases. We're well above our time budget, which is perfectly fine, but I think we need to wrap up. Obviously, we're gonna link to the book itself, which has tons more information than we could cover in this amount of time, which is great. Is there anything, are there any final words of advice that you want to leave our listeners with?
Ryan Singer: I think the most important thing is to think more deeply about the work. What we want to do is get out of this situation where we're under constant time pressure and trying to rush to finish a task, and instead reverse it and create a situation where we can think more deeply about "Is this the right work? Do I know what I need to do or do I not know what I need to do, and how important is it, and how strategically meaningful is it?" All of these techniques are about reframing that, and being able to see, as I've mentioned before, that figuring out what the work is is work.
Ryan Singer: If we can change that shift in our mindset, especially at a leadership level, we can carve out more time for people to think, and by giving them more time, they can produce much better results. And on the second order, it means less tech debt, less things that don't make sense when we go back into the code, and a firmer, more solid foundation that we're building upon all the time. This is a really good place to be in, and I think this should be our goal.
Stefan Tilkov: Perfect last words. Thank you so much, Ryan, for the time, thanks to our listeners for listening. Thanks!
Ryan Singer: I really enjoyed it, thanks a lot.