Shaping, betting, and building (Interview)

Bandwidth for changelog is provided by Fastly. Learn more at fastly.com. We move fast and fix things here at changelog because of Rollbar. Check them out at rollbar.com. And we're hosted on Linode cloud servers. Head to linode.com slash changelog. This episode is brought to you by Linode, our cloud server of choice. It is so easy to get started with Linode. Servers start at just $5 a month. We host Changelog on Linode cloud servers and we love it. We get great 24-7 support, Zeus-like powers with native SSDs, a super fast 40 gigabit per second network, and incredibly fast CPUs for processing. And we trust Linode because they keep it fast, they keep it simple. Check them out at linode.com. From Changelog Media, you're listening to The Changelog, a podcast featuring the hackers, the leaders, and the innovators of software development. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. On today's show, we're talking with Ryan Singer, Head of Product Strategy at Basecamp. We're talking about their newest book, Shape Up, Stop Running in Circles, and Ship Work That Matters. It's written by Ryan himself, and you can read it right now online for free at basecamp.com slash shapeup. We cover the backstory of this book, how the methodology for ShapeUp developed from within at Basecamp, the principles and methodologies of ShapeUp, how teams of varying sizes can implement ShapeUp, and Ryan even shared a special invitation to our listeners at the end of the show to his live, in-person ShapeUp workshop on August 28th in Detroit, Michigan. Details are in the show notes. Ryan, we're here to talk about your book. I guess more of a topical thing than just simply just your book. You always seem to have big ideas, let's just say, right? Because you're... You're a big idea guy. You've been with Basecamp, I guess, 37cino slash Basecamp. I guess we just moved to say Basecamp, right? Because you were at Basecamp, maybe. For many years now. Yeah, 16 years now. That's a long time. And I've always looked up to you and the work you do personally and then corporately at Basecamp. And you've always been leaders in new methodologies, leadership abilities, the way to build businesses. And here we have a book from you called Shape Up. What's the story? You know, we thought... I thought that we had already kind of written something about how we work. It was our first book called Getting Real. And I've been hearing from other teams just how much they struggle with never-ending projects and getting stuff out the door and feeling like they're actually shipping stuff that matters, that means something, instead of constantly chipping away at something with no end in sight. And I kind of tried reaching for Getting Real. and looked at it and said, you know, I thought we talked about this. And it turned out that we actually needed a lot of years to really articulate what we really meant in those early days, I think. You know, because getting real is quite general. You know, it's saying very, very basic things. It's more about principles. It's not very tactical. So part of it was kind of looking back and saying, Can we actually articulate better kind of what we've been trying to say all along about how we work? And then the other piece of it is that as a company, we've changed quite a bit. Our values have stayed the same, but our scale has changed. Our headcount has changed. The types of problems that we have to solve has changed. And a lot of these things about how to work and how to get projects done and how to run a team and how to ship. Those things are very scale dependent. You know, the way that you do that with two friends when you're kind of noodling around with a side project is totally different than when it catches on and it turns into a thing and then you hire people and you know what I mean? You hire more people. And when we did V1 of Basecamp, the company was four people and it was three of us who built V1, Jason, David, and myself. Now we've got, you know, I think the product team, the core product team is around a dozen. and the whole company is about 50. So the dynamics have changed a lot. So kind of felt like there's an opportunity here. You know, we actually had to learn through that growing process how to formalize what we do, because otherwise we you can't just have a bunch of opinions and principles at that size. You have to actually have some some sort of a sense of like, first we do this and then we do that and then it's ready and then we continue, you know. So I feel like kind of all the factors came together. But the big thing was, man, just talking to other people in the industry and hearing still, you know, even though Scrum and Agile was supposed to solve everything, people are struggling even more than they were before, I think, with how to get stuff out the door. Agile in particular seems academic in some ways, the way it prescribes how to do things. And some people loosely follow and some people strictly follow Agile. And there's... I'm not sure if there's really a right way or a wrong way to do Agile because some people can pull things away. And it seems slightly modular, but not quite. And also the information on Agile seems to be very spread out. It's not all in one place where, in this case, a book can sort of summarize a methodology and then also have the background of you and Basecamp and others to support. you know what you're saying here because I mean if you were untrusted hey this would just be a book it wouldn't be yeah you know something for everybody to like oh wow this is Ryan writing this and have the 16 years as you said experience behind you base camp and success I think we've seen a big pendulum swing you know agile started off those of us who were there when agile was new you know we're very invigorated by this huge swing of the pendulum away from upfront design and sort of master planning everything and then sending it down the pipe for production toward, hey, let's actually learn as we go. Let's adapt as we go. I think that spirit is still alive and still a good thing. But the thing was that the pendulum swung so far to the point where there's no planning and there's no clear direction. And now it's like, you know, if you're just working two weeks at a time, you don't know where you're going, that's actually wandering. That's not pursuing a goal. And you do actually need to have a sense of direction. I think this is becoming more prominent in people's minds as you hear more about the quote-unquote product role, you know? And there's a lot of confusion about that because... most people who are product managers are actually project managers because they're getting somebody else higher above them telling them what needs to get done and they're just trying to play calendar tetris and task tetris and just squeeze everything in so it all happens you know you're speaking my language here PTSD come on right but there is this thing where we need to sort of have a strategic high altitude perspective where we're looking a little bit further out in time and we're looking over a broader surface area in space and we're saying like, what do we want to accomplish? Where do we want to go? What matters right now? And this conversation about what matters doesn't fit into a two week cycle, you know? So how do we, how do we kind of have that conversation? How do we lead with more design? without swinging the pendulum all the way back to waterfall. So I think a lot of what we're talking about in shape up is, is, is something that kind of breaks that duality between either you're doing waterfall or you're, you're kind of wandering around making little incremental nibbles and not knowing where you're going. So the book is called shape up is the methodology. Do you guys also call that shape up? Like we like, that's what we do is we do shape up. Are you trying to like create that moniker or is that just a byproduct of the book name? it's funny like you have to call it something right you know for us it's just how we work and right we started to to give names to the different practices and uh i was actually trying to figure out what to call the book you know and in the end and uh i was talking with my friend chris speck who who helped quite a bit he and bob mesta helped a lot with sort of um helping to pull out what we were doing and reflect it back to me so we could figure out how to systematize it and um He said, well, you know, what do you guys say to each other when you recognize that you need to improve or that you're off track internally? And I mentioned to him, you know, we still say to each other sometimes, hey, we got to get real with this, you know? And then I realized, you know what? When it comes to actually... turning some kind of a raw idea or an impulse into something that's actionable that's going to ship and confidently ship we actually say like you know we have to shape that up because shaping is this is a function where you turn something that's unformed into something that has enough form and enough clear boundaries on it that you can see the edges of it and you can sort of contain the risk of it more and you can confidently delegate it and give it to a team and trust that they'll be able to work out what it what it ultimately is. So that was the thing where once we realized like, yeah, we got to shape that up like, ah, that's actually a thing you can do. That's a verb. Boom. You know, we'll call it that. And whether whether it catches on as a method name or whatever, I mean, you got to call it something, you know, the important thing is I want to I really want to give people language to articulate. what they're doing that's working, what they're doing that's not working, and the fact that work has different phases. Work isn't born as tasks and finished as tasks, you know? There's all of these intermediate stages from maybe we need to redo this part of the UI, or maybe we have to rebuild this part of the back end, to this is actually a project, to... this project entails actual work, but we don't know what the work is, right? You got to get under the hood before you even actually know what the work is that you have to do. And you get down there and you get your hands dirty and there's all kinds of stuff you had no idea about that you have to deal with, right? You know, so there's all these different stages of what I have to do unfolding and then figuring out how to tackle it and then completing it. We need language for all those things, you know? So that's a big thing that I'm trying to contribute here. especially if you have a product manager trying to drive a direction and as you said they often uh fall into the product manager like this is what we got to do here's stories let's do estimation let's you know all the necessary agile scrum methodology uh you know practices to do the cadence into the rhythm and be connected and yeah you'd have developers go away trying to fulfill their estimation fulfill their tasks they pick up and lo and behold they find tech debt or stuff that they that we didn't weren't aware of and now our two-week sprint isn't really a sprint on that it's like well we have the back battle to deal with things we weren't aware of totally in the book we call it imagined versus discovered tasks so there's the tasks that you imagine that you just by thinking in your head, well, we're going to have to connect to that API and we're going to have to refactor this a little bit first and then we're going to design some UI over there and it's all going to work, right? And then you open the hood and then there's all the stuff that you didn't imagine that you discover you have to do. And that is the real work. Most of the work is actually in that category. Maybe backpedal a little bit and describe what it is to be a successful team. You know, I'm kind of pulling from the forward from Jason saying the way a team works has enormous influence on what it can do, processes methods and practices i'm curious what you think what are some things successful teams do to be successful yeah that's a really great question this is a little nerdy but the way that i think about both base camp the product and base camp the company is that what it does well is it it catalyzes self-organization so you've got a whole bunch of people who kind of want to make progress together and want to work together and make something great and that can happen as a base camp customer where you're in some other domain you know you're working at a at a creative firm or you're working at a non-profit or a law office or whatever there's some kind of sense of we want to work together to get somewhere right um and then the same thing with our teams internally we've got programmers and designers who are extremely skilled and are really, really good at making decisions and making choices and figuring out what they have to do and then getting somewhere. How do we enable those people to work together and make decisions amongst each other, you know, and discover what they have to do and capture what they have to do and then manage that rather than this kind of there's going to be some genius somewhere who architects everything and then delegates down a million tasks and that's how the project gets done, you know. So I think I think a really successful team has a sort of guardrails in the sense of they know what to do and what not to do in terms of what's valuable to pursue and what doesn't matter. And they also have guardrails in terms of how much time do we want to spend on this and what's this worth? You know, we talk about the appetite instead of the estimate in the book. But then they have the freedom and the autonomy and very importantly, uninterrupted time, uninterrupted from the outside of the team boundary, you know, to coordinate together ad hoc, to learn together and to decide together how they should actually fulfill this project. Of course, if you're making the exact same widget that you made 100 times before, you're just doing it for a different client, there's no learning involved, there's no novelty involved, there's no discovery, right? But most of the interesting projects that we like to do as software developers, there's always something new there. There's something we haven't done before, you know, and that's where all the interesting work is and where all the challenges are. So a good team is working together based on, and I like to think of it that work has a natural anatomy. And it's sort of a, you know, it's not a vegetarian-friendly analogy, but the, you know, the... The process of cutting apart the work is like butchering an animal. You don't pick arbitrary points to make the cuts, right? The location of the joints and bones and muscle is already in there to guide you where to make your cuts. This is how we think about factoring as software developers, right? And the thing is that every project kind of has a natural anatomy in it. that you have to find by feeling around and getting in there and getting your hands dirty, but you don't know that upfront because that anatomy is made out of interdependencies, you know, that often you can't see. Interdependencies that play out in the current system, you know, in one snapshot in time, but also interdependencies that play out over snapshots of time through time, right? Like first, if we do that, that's going to enable us to do that next versus the other way around, you know? So, If we try to put everything into a plan upfront, like these are the tasks and now go do it. Or if we try to sort of segment everyone's time, like you will meet once a day and then you will meet again once a week. We're trying to make something that has a very organic, natural, weird internal structure that we're trying to determine. We're trying to turn that into some kind of a periodic crystal. The structure of the project is not made in day-sized bites and week-sized bites. It's like you're going to have your head down for three days and then all of a sudden you're going to be like, oh, I'm ready for the next thing. Or you're going to have your head down for 30 minutes and you're going to be like, I can't even move forward. We got to talk. You know what I mean? And you can't predict that when you're doing novel work. So I think that's where we try to set up the guardrails. by shaping the work so the team can be successful and setting the right boundaries on it. But then at the same time, the team is really successful and they have a lot of autonomy to apply their expertise and make their own decisions as they feel their way through the project. So we should probably talk about the methodology and what the major tenants. the cycles, the way it actually works, the shaping, the bedding, the building before we do that, because I think that will set the groundwork for the rest of the conversation once we all understand what it is that you've been writing about. But I'm just curious before we get into that, how long y'all have been doing this particular cadence, the six weeks, two weeks? How much has this... coagulated as a concept or is it still a moving target inside of Basecamp in terms of the way you all do your work? Do you expect it to change dramatically for ShapeUp 2 or do you feel like it's been pretty solid for a while now? That's interesting. So different parts of the method trace back to different points in our history. The basic notion of we're going to set a fixed time box and we're going to design to the time box. as opposed to we're going to estimate the work and then slice it into time units. That's very, very different. There's a huge difference between taking a six, let's say you take a 10-week project. Let's say you estimate something as 10 weeks, and then you slice it into two-week slices. Now you're doing a 10-week thing, but you're just incrementally attacking it tactically two weeks at a time. It's a huge difference between saying, we're interested in spending six weeks on this thing. So rather than estimating some solution, as 10 weeks, it's more like how do we design something into the bounds and the constraints of six weeks? How do we make different choices? That aspect of working with an appetite instead of an estimate and working with a fixed time box, whatever the size of that box is, started in 2003 when we did V1 at Basecamp because David was working 10 hours a week. We built V1 with one programmer working 10 hours a week. And so we were constantly asking ourselves, if we if we asked ourselves how long does it take to build base camp it we would have never gotten done but if we said to ourselves man like if we've only got 10 hours of david this week what's a version of message categories that we're going to get done at the end of the week you know what i mean that's a totally different thing so that that traces all the way back to the beginning and then the the the technique of scoping which is Instead of just splitting work out into tasks, we have this intermediate unit, which is kind of like, it sort of corresponds to the anatomy of the animal, like the big joints and muscle groups and stuff, you know? How do we factor the project down into the main orthogonal parts? That scoping practice started in 2009 because we had to build out, we had four products at the time, Basecamp, Backpack, Highrise, and Campfire. And we wanted to tie together the, like tie them all together into a single sign-on. and have like seamless you know movement when you're authenticated from one into the others and that was just a gnarly thing to transition all those pre-existing user bases into a single sign-on thing so that was such a huge technical thing that we we actually had to figure out how to break down the work into the right size units that integrate front-end and back-end that we could finish and then kind of shrink the universe of what's left, you know, and then move on feeling better. So that goes back to 2009. And some of the interface techniques like breadboarding goes back to 2009 as well. And then it was in 2012, when we totally redesigned Basecamp from scratch and did Basecamp 2, that we kind of first, we had more people on the team. And we kind of had this notion of When are we done experimenting? You know, there's this phase where you've got like three people who are experimenting with where to take the new project to sort of the skunk works thing, you know, and then and then eventually you have to flip a switch and you have to say, you know what, like we know what this new thing is. We can see the outlines of the architecture. If we're trying to imagine how we would build the next feature, we can sort of see the through lines on it. You know, it's not like this big research project anymore. And then you make this flip into production mode. And now you want to give teams the responsibility to build out the features, right? So that's kind of where the informal aspects of shaping and bedding kind of came together there. But we didn't have a strict process around it yet. And then it was in 2015 with BC3 when we were trying to, we were past the point of experimentation and we felt like, We want this thing to be done by the end of the year. That's actually when we formally adopted six-week cycles because we were really kind of feeling the pain that our cadence wasn't fast enough and there was just too much to take on. So we've got to figure out a way to kind of repeatedly make progress. But how do we make a bite into this where the bite is big enough that we're getting nourished from it? And it's not just incremental. So if we were doing two weeks, we wouldn't have felt like we were getting anywhere. But with six weeks, it's the right time horizon. You know, you can see the end from the beginning. The end is far enough away that you can get something meaningful done, but it's close enough that it's also kind of looming the whole time, you know, reminding you to make trade-offs. That six-week thing goes back to 2015. And we do have a little bit of a twist on it. You know, like in the summers, we do four-day work weeks. So we actually are doing eight-week cycles in the summers. just to compensate for the fact that we lose that fifth day every week. So there's little there's little twists here and there. But for us, you know, for us on the tech stack we're using and the way that we're structured, six weeks feels like the natural number right now. This episode is brought to you by Keen. Keen makes customer facing metrics simple. It's a platform that gives you powerful in product analytics fast with minimal development time. For example, a DIY solution to build out customer-facing metrics in your product could take six months or more, and with Keen, you could be up and running at the same day. The Keen platform lets you stream events to easily collect and enrich your data, compute with embeddable answers, insights, and metrics, access controls so you can design role-based access to your data, And of course, a visualization layer to create stunning charts. And we got a special offer just for our listeners. Go to keen.io slash changelog. Get your first 30 days of Keen for free. And as a bonus, just for checking out a 15 minute demo of Keen's customer facing metrics, they'll send you a free t-shirt. Go to keen.io slash changelog. Again, keen.io slash changelog. I think naming, we probably can all agree that naming matters a lot. Yeah, for sure. And I think calling it cycles versus calling it sprints removes some inherent anxiety, natural anxiety even. Like if you're in a sprint, you feel like you've got to put it all out there in those two weeks. It's not so much that you wouldn't in the six weeks, but calling it a cycle kind of removes that stigma of like, we have got to go fast, fast, fast as possible. Absolutely. I can't sprint for six weeks, you know? No. You totally can't sprint for six weeks. Just don't ask me to sprint for six weeks. And if you did, you wouldn't like the result because… Yeah, burn out real fast. And this is a huge problem is that if you're working two weeks at a time and your idea is push, push, push for the whole two weeks, not all work. You know, work is kind of like a wave. There's a point where the work is gathering and then it reaches a high point and then it pushes and crashes and then it recedes again. And inside the six weeks, there's an early phase where nobody's like pushing, everybody's getting oriented. They're trying to figure out like, what is the existing system? What APIs do I need to connect with? Like, where are the boundary lines between different parts that are dependent or interdependent and stuff like that? And, and then, and then there's a point where they start to figure out what the work is and then they kind of gather steam and then, and it's kind of like, go, go, go for a nice, maybe four week chunk in the middle, you know, but you can't just ship, you can't just race and then ship. Cause you also have to sort of take a moment and get some feedback on your pull request. And you, you already have a better idea for how you could factor something that you did in the first week. You know what I mean? Like, you're like, oh, that shouldn't be here. That should be there. And I want to separate that concern here and there. So. This is sort of like the wave kind of starting to recede. It's not over, but you need that time. That's a huge part of why people have so much technical debt. It's because they don't have that time built in to the cycle to think about quality or to make those cleanups or to make those adjustments to how things are factored and represented in the code so that it's better for your future self and for future others. How you describe that kind of remind me of, this is a nostalgia too, by the way, I'm sure. You'll both nod your head when I say it, but it reminded me of HashRocket's 321 thing they launched way back, and it turned a lot of heads, and people were like, how in the world can they build, this team build, or these teams build a full-on application, VIP application, in three days? The premise was essentially, hey, hire us. We'll build your first prototype in three days, and then you can know where you're trying to go from there. And what you didn't realize was that before the 3-2-1, the three days, so to speak, you actually had several weeks of, you know, very intentional meeting, planning, discovery, et cetera, that was kind of prefaced to this and was sort of necessary to build, right? You got that sort of gap that you have to build in there, but it was sort of hidden in the – What's the two and the one? Like two weeks and one? I could I swear it was called 321 I could be wrong somebody I remember the name I just don't remember the two of them I don't know honestly it kind of reminds me of the more advanced hackathons now where there's lots to win and you can't bring any code beforehand so you have to show up for these 48 hours and then the teams that are actually serious about winning they put like weeks of preparation into what they're going to build right they just haven't written any lines of code yet and then it was time to kick it into high gear talk about a sprint right we're far enough in though we need to we need to hear the sum of this methodology. Take us through a cycle. Take us through like a- We're teasing it too much. At a high level. Okay. Don't go into the details of like how you shape, you know, but tell us about the shaping and the bedding, the multiple cycles. Go ahead and lay it out at a high level for us. Sure, okay. So I think based on what we set up so far, we could start sort of from the inside out, start in the middle with the six-week cycle. So we're working in a six-week cycle, which gives us enough time to actually finish something. and ship it. So the general idea is that at the end of the six-week cycle, the thing is we fully intend and plan to deploy it. And not only that, if it doesn't deploy at the end of the six weeks, like something bad happened. So that's really the attitude. Something bad happens to the employees? What do you mean? Well, you know, we don't have any roasting pits, you know. Oh, you said something bad happened. Like, okay, I thought you said something bad happens. I'm like, whoa. There's a sense of, you know, if it didn't ship at the end of six weeks, something went wrong. That's not normal. That's not business as usual, you know. And then we've got two weeks of cool down at the end of every six weeks. And that originally started because we recognized that We needed some time to just look at bugs because there's a certain amount of bugs. Most bugs don't matter and bugs aren't special as David likes to say. They're just other work that you could maybe do or not do. They're also in a way just the edges of what works. If the core of what works is valuable, then the bugs are just kind of there sometimes. It depends on how competent the execution of the core flows is, right? We assume always because we have competent people who have enough time to think. that the core things are properly done. But nonetheless, having that two weeks of cool down between cycles gives programmers uninterrupted, like totally un, how do you say it? They're not guided with what to do at all. They're totally free to just pick off that thing that they wish they had done differently, that bug that was brought to their attention that they would like to solve, the new library that they might want to use, but they haven't had a chance to tinker with it yet, you know, whatever, right? So, and then also those two weeks of cool down give us an opportunity to kind of put heads together and meet about what to do next. They give people sort of a chance inter-departmentally, which is a goofy thing because we're a fairly small company, but, you know, still like, when does the programmer get to talk to the data person if their head's down for the six weeks trying to build something, right? So that's cool down. And during the six weeks, A huge part of the notion of that cycle is that it's uninterrupted time. So the team is given a project and they are totally left alone to do it however they see fit and to organize themselves how they see fit. So that's the basic structure of the cycle. And then if you have that in place, then questions arise. How do we put work into a cycle so that we can actually... have confidence that it's going to ship. So this puts us into a risk mindset. If I give a team work that is totally underspecified, like go build a calendar. I mean, a calendar could do 100 things. Which 10th of a calendar should they build first? They could build the best ever RSVP and invitation and schedule alignment system, kind of go down like a doodle direction and make that the best ever thing. They could make the best ever high fidelity native interaction for drag and dropping events on a monthly grid of cells. Where do they go? So if you underspecify the problem, your risk is huge because you're giving way too much open space to the team. On the other hand, if you over specify the problem and you say you will do this task on Monday and this task on Wednesday, then it's all going to blow up in your face because you don't actually have the information to make that judgment up front, like we talked about with the imagined versus discovered work. So the challenge then is, is how do we kind of shape the work in such a way that everyone can see what the rough, basic... solution is, you know, without totally being specified. And how can we kind of address what might be the major rabbit holes in that work before we commit to it and give it off to a team? So you don't want to give a team a ticking time bomb or a hole they're going to fall into. So there's a certain amount of high level design that we do and a certain amount of sort of technical stress testing. you know architecturally does this make sense do the apis that we expect to to use actually exist there uh this kind of a thing performance wise if the designer has an idea that this project is going to work like this but then somebody who understands you know how all the jobs are going to have to get queued could say um you know we might need to that might be an issue whatever right um so there is this pre-work and the pre-work that happens before work goes into a cycle before work is kind of qualified to go into a cycle is this shaping work And this shaping work isn't done by everybody. It requires kind of a cross-discipline melding of what is strategically valuable, how do we figure out the main affordances and moving parts and flows from a customer-facing standpoint? And then working backward, can we actually envision the technical solution enough that it doesn't feel like we're throwing a big mystery over the wall? to a team and expecting them to solve it, right? So that's the shaping. And then the work that we do in the shaping phase, it doesn't automatically directly go onto some kind of a conveyor belt or a queue. There's no backlog. So just because you shaped something doesn't mean that now it's going to go to a team. Rather, it means that you've done some value-add work on a raw idea. on an unshaped idea so that it's now a better potential bet. So you've improved your odds on the success of shipping this thing. But there's still a separate question, which is, is that thing strategically valuable for us to spend time on right now? Or is the amount of time that you shaped it for? So let's say I've got some idea for some group notification thing in Basecamp. I could shape up a six-week version of that. And then put it together into a pitch and be like, here, here's something I think we should do. I don't think there's any rabbit holes in it. I think it's clear kind of how the team could solve it. Let's do it. And then we could have some push and pull. And somebody else might say, you know, Jason or David might say, eh, if we could do that in a week, I would gladly ship it. But I don't want to give up all these other things that we'd rather be doing for the next six weeks to get that, right? So you have this question of kind of what's, what actually matters so that's where we get into betting betting is very different than planning planning has the has a general connotation of certainty and betting has a general connotation of risk so with betting we want to have the notion of you know uh i know how much i'm betting and i have a i should have a capped downside and and and maybe an open-ended upside so you know what i mean at the most i'm gonna bet six weeks on this thing and see what comes out of it. But I don't want to bet six weeks on it. And then all of a sudden, it turns out that I bet 2x, 3x, 4x that much time on it. That's not a bet. You know what I mean? That's like just getting screwed, you know? So with betting, you put a certain number of chips on the table, and that caps your downside, right? So that's the first thing. That's totally different from let's take two weeks whack at this and see where it goes, right? And then the next thing is that betting is supposed to have a payoff. So there's no guarantee that you're going to get the payoff, but you're only making the bet because you see a payoff ahead, right? So we want to have that conversation. At the end of the six weeks, how are we going to feel about this? Are we going to be like high-fiving each other? Like, awesome, the product just got better because we did this thing and this was a good use of our time right now. There's the payoff, you know? And then we also have this thing, you know, that we call the circuit breaker, which is by default, a bet that we make, if we say we're going to do this project and we're going to give it to a team and they're going to work on it for six weeks, if they don't finish that project at the end of the six weeks, by default, it's dead. It doesn't ship. It doesn't get reinvestment. It doesn't get picked up again. That's a circuit breaker. And a circuit breaker is a risk management technique. You know what I mean? As soon as something gets above a certain level, pop. Like, we're not going to allow more than that, you know? And basically, the idea there is that something went wrong and we don't know what and rather than immediately injecting more cash or time or people or whatever into this thing that didn't work let's table it and then let's put the onus on whoever thinks it's important to bring it back to the betting table and if they're going to bring it back to the betting table for consideration for more resources then it probably needs some new shaping work, right? Because whatever it is that we thought was going to work out when we shaped it didn't work out the way that we thought. What if it's super close? Yeah. Now, that doesn't mean that we never extend projects. It just means that that's the default, right? Gotcha. And so that kind of takes us- You ever think, oh, we need one more week. We just need one more week. So the we just need one more week thing kind of takes us further into part three of the book. This takes us into the uphill and downhill work. Work has these two phases. We say, you know, we have these hill charts in Basecamp because work is like a hill. The uphill phase, it's not the effort of pushing. The uphill phase is the phase of the work where you don't actually know how to do it. You know that you've got to geocode this data, but you've never worked with the geocoder API thing, library before, whatever. And you have assumptions about how it's going to work, but you haven't actually tried to piece it together. And so there's unknowns there. So there's an uphill phase where we kind of know what we want, but we don't actually, we can't see, I will do this and then that and then this, and then it will, and I'm 100% confident because it's right in the palm of my hand. These are the screws that I have to screw in, you know? But then as you sort of look into it, spike something out, stub something, spelunk a little bit into the existing frameworks and stuff or libraries, you get to a point where you're like, okay. I tried wiring a little bit together. I've stubbed it a little bit. I can see this. I can see down the other side. Now I know what I have to do. That's like what it's like to stand at the top of the hill. And then the downhill is where it's like, look, I've got, I know exactly what I have to do. It's just a question of time. So I use a kind of everyday example of planning. You're going to have a dinner party. If you don't know what you're going to cook at the dinner party, then you don't know what you're going to go. where you're going to go grocery shop and what you're going to buy, right? And how many days beforehand you need to plan it. So there's a certain kind of phase of, am I going to grill out or I'm going to cook Indian or am I going to do Italian? And then once you realize like, oh, okay, it's going to be pasta and it's going to be vegetarian, it's going to be this and that. Then you say, okay, now I've got my grocery list. I've got my recipe. And all that stuff is like known, known, known, known. You know what I mean? You can schedule it all out and you can just bang it out and be done. So when we're at the end of a project and we got that like, oh, we just need one more week or we just need two more weeks, the character of that work. Whether it's uphill work that has uncertainties in it or it's downhill work where we can see it all in the palm of our hand, it makes a huge difference to how we want to think about reinvesting. So, yeah, I mean, if you're at week five and you're like, we still don't really know what we're doing here. It's like, okay, we're not going to extend this for a couple of weeks. We're going to cut it off. Exactly. And we've seen both of those cases. That's actually kind of where Hill Charts were born. We had a project. That was at week six. The cycle was over. And by the way, we don't even make this call until the cycle's over because we just leave the teams alone to solve it. But then the cycle's over and there's this UI problem. And it's like, man, we could go a year and never solve that. Or we could have a Eureka in the shower tomorrow. But that's not how we make bets. We want to put that off onto the shaping track where we're going to feel more confident that we have a design solution to that before we actually give it to a team and say, This is something we actually expect is going to ship. So that kind of takes us through. There's raw ideas, customer requests, stuff that the CEO dreamed up yesterday. All that stuff needs to get shaped before it's a good potential bet. Because if it's not shaped, it's too risky. Then if it's shaped, it's defined at the right level of abstraction, where it's not so vague that teams don't know what to do. And it's not so specific that teams are going to get boxed in with incorrect assumptions on the first week. right and and we we get into tools and techniques for how we kind of hit that right level of abstraction in the in the book that the output of that shaping process is a potential bet and since we don't have any backlogs somebody needs to bring a potential bet to the betting table the betting table happens in the cool down between cycles and the potential bet takes the form we call it a pitch so the pitch is like here's the problem or the opportunity Here's the rough outlines of the solution. Here's the rabbit holes that we covered or identified. Here's the things we're not going to do that makes it reasonable. And this is the appetite. Like this is going to be a two-week thing that we're going to do as a small batch, as a set of smaller projects, or this is going to be a full six-week project, whatever. Those things are addressed in the pitch. And then at the betting table, a handful of senior folks or executives are going to look at that and say, not only what's valuable, not only what seems to be shaped up enough, but kind of what is timely, you know? We don't want to do the exact same type of project five times in a row. Or maybe the set of people who are available based on vacations is different. The skill set available is different. So that's going to kind of influence what we bet on. And rather than like grooming some giant backlog of stuff that we're never ever going to do, people are bringing... a pitch to the table so you have to personally bring it you know what i mean so you're only going to have three or four right you're going to have a few things deeply considered with lots of context that are timely um that have been uh risk reduced as much as you can manage of course you you can never take all the unknowns out but we've done our best and that's that's what happens at the betting table so then once we if we choose to make a bet on a project that means okay we're going to give this to a team Our teams are generally one designer and two programmers or sometimes one designer and one programmer. We're going to give this to the team and we're going to leave them alone for the six weeks and they're going to figure it out and they're going to ship it at the end. And that is where we kind of get into part three of the book, which is about handing off. So part one is shaping, part two is betting, and part three is building. And building starts with assigning people projects, not assigning them tasks. So we talk about the paper shredder. You know, if you try and split up a project into a bunch of tasks and that's what you give the team, it's like putting your project through a paper shredder. They all just get a whole bunch of individual strands of work and then it's like, good luck, hopefully it all pieces back together again into what we wanted at the beginning, you know? And on top of the fact that that was just imagined tasks, not even the real work that came up through the course of figuring out what you actually have to do, right? So instead of assigning tasks, we're just assigning the whole project. And then we're giving the team the autonomy to do that inside. It's also the opposite of empowerment for your developers. It's like demeaning. It implies a certain level of code monkey or grunt work. Like, here's your task. Go do the coding thing. That's exactly the terminology that you hear. Code monkey, grunt work, ticket taker. You know, it's just tickets on a queue that never ends. Nobody wants to be that. No, no. And it's a, you know, programmers have expertise. They're not, there's a lot of judgment calls that need to be made in the course of building something. And you want to sort of promote that fact that there's going to be judgment calls. There's going to be trade-offs to be made and put them in a position where they're making those judgments instead of just executing stuff that somebody else kind of planned out for them. you know yeah yeah and then we get into uh sort of what are the techniques that that the teams use to enable them to be successful then how do you go from this kind of shaped overall concept to running code you know and this is kind of where we get into some of the getting real principles kind of better articulated so the first thing is that the teams actually aim to get some they aim to get one piece done very very early And I think for people who really get what Agile is really about, we'll feel that this section is familiar to them. So instead of doing a lot of horizontal platform work where we're going to build out every piece of code we're ever going to need, and then we're going to layer out the features later, it's kind of like the people who, I'm going to invent the new database before I write my app. You know what I mean? I think that happens. That happens in a kind of small way on ordinary projects all the time. Like, first I'm going to get all this code back end working, and then we'll do stuff later. Instead, what we want to do is we want to have a single vertical slice of a little bit of front end with no unnecessary visual styling. It's more about the affordances and the components. There's going to be a button here. It's going to show you this, and then it's going to take you over here, and then you're going to fill in this field. And then it's going to do this calculation. It's going to spit out this other thing on the last screen. So the affordances and interactions, the designer is going to lead with a little bit of that, put that into place, and the programmer is going to wire that up. And then that one little piece that you could carve out that has both front-end and back-end is going to be done. And you're going to have a separate branch running. You're going to have a beta server running that shows this one little part is working. You know and you're gonna be able to show the outside world like we finished something That is totally core to kind of how our teams work and this is what we used to call getting real We still call it that internally sometimes It's the notion of like don't build a bunch of stuff that's supposed to magically come together in the 11th hour Don't design an IKEA set, you know and then and then trust that your instruction manual and your design is gonna like it's all gonna come together, you know instead like actually put integrate integrate front-end and back-end together and deliver something that works that's some kind of orthogonal slice. We call that a scope. And in the beginning, you can't see what the scopes actually are because you have to walk the territory before you can map it. So there's this notion that the work we have to do has these boundaries on it from the shaping, but it's also kind of like a wild jungle. And we have to sort of get in there to figure out what the major landmarks are and where the ravines are and where the river runs and stuff like that, you know, to figure out those, of course, correspond to where the interdependencies and the independencies exist in the work. So in the beginning, the team is just going to pick off one thing that they can say, you know, this is the place to start. And in the first maybe week, they're going to have something running, front end and back end working together. And then because they kind of dove in there and they started to get, involved in the system and get their hands dirty, they're going to start to see, okay, so we're also going to need this and that, and then we can work on that other part over here. They're going to start to see the lay of the land, and that's where they start to kind of define the work into scopes. Scopes are a unit of work that's lower than a project and higher than a task. So it's an orthogonal chunk of the work that we can integrate independently and that we can finish. It needs to be small enough that... that we can see the end of it in maybe, I don't know, three, four days of work together, you know? Because if it's bigger than that, it starts to feel like a project. Yeah. You know, and if it's smaller than that, it's a task. And then what happens is the team starts to get this kind of big map and they actually develop language. You know, when you're working on a, when you're working on modeling a new feature, you've got to figure out like what, what you're going to name the columns, what you're going to name the major methods, like. That naming is so huge because that gives you the leverage for everything else that you do later. So actually naming the scopes turns out to be this really juicy activity for the team. So we're building client side 2.0 and client side 2.0 has a visibility toggle. It has bucket access. It has like, you know, it has these things that have names. And basically what we've done with the notion of scopes is we've taken the principle of separation of concerns and the principle of factoring, and we've lifted them up from software development to product development. So it's like, what are the things that need front end and back end together? And then how do we put front end and back end together, but cut it apart from everything else and just get that one part working? That's what a scope is. And so once they've mapped those, then actually they create to-do lists. I haven't found a tool. This isn't just promotion. I actually tried to find a tool other than Basecamp that enabled this way of working. So there's an opportunity if somebody wants to try, and there's also opportunities for us to keep going down this road. But Basecamp has this hierarchy. You're in the project, and then the project has to-do lists, and the to-do lists have items. it sounds stupid it sounds very simple but like try it in jira you know what i mean what what happens is you can create a to-do list where the name of the list corresponds to the name of the scope now as you as you glance up and down this set of lists inside of the project you're looking at a very high level architecture that's kind of dynamically produced based on walking the territory of where the moving parts are of what you're going to work on and what you can finish independently and then as you discover work which is a huge part of development, right? Oh, I got to do this. Oh, don't forget about that. Oh, this doesn't wire into that. I'm going to have to research that, right? Those tasks now have buckets that they live in. If you're working on, we're redesigning the client interaction, we have a scope called bucket access that has to do with the way that we allow people to access a project and know who can see what project. If an issue comes up with that, I know that I can create a task and capture it inside of the bucket access list. So this facilitates this capturing of work. But capturing it so it doesn't just become a giant pile, but it actually goes into the different scopes. And then the fact that the work is separated into scopes enables you to sequence the work. So now you can say, well, what scope do we want to finish first, second, third? What do we want to hold off on? There's another piece to this, which is we have a little technique. that I mentioned in the book, we distinguish between the team is always having to fight scope because scope creep isn't like a bad client. It's not bad shaping. It's not just taking on too much. A lot of scope creep is just the fact that you thought you'd be able to build what you described. But then once you discovered all the actual work you had to do, you didn't know you had to do, it's way more work than what you characterized up front. So it's a natural function of opening the hood that the scope grows. So what we need is some kind of a machete in our hand so that we are constantly cutting away at that and making judgment calls. And the machete that we use is this little key on the keyboard. It's on the upper left, depending if you're on a sun layout or a modern layout. It's the tilde. And so we put a tilde in front of a task if it doesn't absolutely have to happen for this thing to ship. Like if I had to ship tomorrow and I didn't do this thing, would I still ship tomorrow? You know what I mean? Like what could I ship? It's a nice to have. It's a nice to have, exactly. And so what you'll see is that these scope to-do lists will have a name corresponding to some scope, items underneath. a mixture of design and programming tasks because they're integrated. And then you'll often see like two or three little tilde tasks hanging off the bottom of the list. And those are the things that the team declared as soon as they encountered them. Not a must have, let's see if we have time at the end. And that's a discipline kind of coming back to the question earlier about what do successful teams do? Successful teams engage with the scope. They battle with the scope. We call it scope hammering. Because it takes so much force and effort. And it's not just like trimming off things that are easy to cut. It's really being like, man, do we really need that? What happens if we don't do that? It forces conversation too, right? I mean, if you have a team who's trying to do work and is not collaborating, they're sort of isolated. They all assume, hey, we got to do these things. We got this work. There's no collaboration. It's a feedback loop that's necessary. to have a healthy team to say okay ryan agrees and i agree that this thing is a till day or it's it's a nice to have not a need to have and we're all on the same page now we can actually focus our effort versus be kind of feel almost guilty that you're not finishing the things absolutely yep this episode is brought to you by team city team city is a self-hosted continuous integration and delivery server developed by debt brains Millions of developers every day are already using JetBrains IDEs, and now there's a powerful CI CD solution from the same company. TeamCity lets your team deliver quality software faster. It is super smart at running incremental builds, reusing artifacts, and building only what needs to be built, which can save over 30% of the daily build time. For example, JetBrains uses TeamCity internally, and its optimizations save them over six months of compute time each and every day. The professional version of TeamCity lets you run up to three builds in parallel, and it's free to use even for commercial use. For large organizations, JetBrains offers TeamCity Enterprise, and our listeners get it for 50% off for a limited time. Head to teamcity.com slash changelog, and all you got to do is use the code changelog50 at the JetBrains store. Again, that's teamcity.com slash changelog. So that almost brings us to the end of the book. The teams are walking the territory and mapping out the scopes. They're capturing the discovered work that comes up into scopes. They're building the scopes out and finishing them one by one. So they're kind of like checking off whole territories on a map. Like, nope, don't need to think about that anymore. Don't need to think about that anymore. The whole universe of stuff that they have to worry about is shrinking over time. And they've got actions, tasks marked with the tilde as a nice to have. So they're constantly sort of managing the scope as they go. And then the last piece is the way we've built it in Basecamp. is that Scope's to-do lists in Basecamp, they map to dots on a hill chart. So the uphill, the hill chart, if you just sort of look at it, it kind of looks like a, what do you call it? Like a normal distribution, a bell curve. But that's not what it is. It's just the same shape. And the left side is showing if we're on the far left, bottom left of the hill, it means I might have ideas about how I'm going to do this, but I haven't actually cracked it open at all. Right. If you're a quarter of the way up the hill, it's like I've identified some of the moving parts. You know, I've stubbed something. I think I have an idea about the approach. And then maybe nearly all the way up the hill is like I've stubbed it. I've kind of validated that the things wire together. I thought that they would. And I'm not seeing anything left that isn't clicking together. So now you're on the top of the hill. And then, you know, maybe a little bit over the top of the hill is like. I have a lot of tasks left toward the bottom of the hill. I don't have that much left. And then all the way on the other end of the hill, it's totally done, right? So we allow the teams to actually just drag a dot to indicate what's known and what's unknown on a per scope basis. If you tried to drag a dot for the whole project, you couldn't do that because every piece of the project has different probability and different level of uncertainty to it. You know what I mean? There's this one piece of, like, I know how to build login. but I don't know how to build this new algorithm that we're going to do for this analytics thing that we're trying to do, right? So I can't say that the project is equally certain and equally uncertain, but if I break it into scopes, now I can say this scope is totally solved, but not done. This scope is not solved at all. And then this gives us kind of a really instant single picture of the risk profile of the whole project, you know? And it's not just the snapshot, but it's also the second order. So I can look at snapshots of hill charts, like one next to the other, and they're dated. So I can see if that dot for bucket access has been sitting in the same spot on the left side of the hill, meaning there's still unknowns in it, or if it's moving, you know? And this is not algorithmic. It's not automatic. It's not some, you check off some tasks and then it automatically moves. It's the opposite. The number of tasks often increases when we have more certainty about what to do. You know, the more you know what you have to do, the more you know what you have to do. So all of a sudden you had four tasks before and now you're like, ah, okay. You really get in there and now you got 20 tasks. But they're all very, very doable tasks and you're not worried about it at all. Right. So if you were trying to look at the quantity of tasks to judge progress, you'd have a complete backwards picture. So that's why the position on the hill is manually dragged by the developer or the designer, whoever's doing this piece of work. And it's totally decoupled from the number of tasks. Right. It's a totally separate question. Yeah, just completely orthogonal. So if they don't manually drag it, you have to walk around and say, hey, go update that hill chart. You forgot to drag it. So what we found is that actually the teams really enjoy sort of there's a weird sense of triumph of like, ah, got that over the hill. So once they understand it, they tend to adopt it actually very eagerly because it's a chance for them to sort of celebrate a moment of success or celebrate progress. You just can't see the progress if if the thing they're building isn't wired together enough to click through, you can't see the progress if the tasks that they need to do don't even exist yet or the tasks don't really represent what's in their head. But if they can drag a dot uphill and be like, hey, I took this from totally unknown to mostly solved, everybody's going to be like, sweet, this is coming along. Yeah, that's a very, I think that's an insightful conclusion. Like, hey, the best thing we can actually do is just indicate manually where we are because we can't, accurately derive based on any particular data that we have in our system where we are on this particular scope. It's epistemologically honest. It's just reality. Like, look, nobody actually knows, but they can tell you about a single piece that they're working on if they've gotten it straightened out or not. That's a real honest thing that they can report. So we're trying to map what we're reporting and what we're calling progress to what people actually know. You said before that you kind of leave teams alone. when they're in a cycle, right? Yeah. Does that mean there's no collaboration or does it, how does the, you know, sort of the design and the two developers, for example, doing the work kind of in this discovery mode, how are they doing the work and then kind of feeling good that they're making the right choices? Is there any sort of like check-ins along the way? Is there like this constant collaboration? How do you leave them alone but stay in touch? That's a great question. So the way that we do it is it's not very formal and I think that's a feature, not a bug. there's sort of two aspects to it. One aspect is the team can get into a situation where they don't feel like they're making progress. And the problem is that very often teams actually don't, it's just human nature. It's hard to wait to raise a flag and say, I'm stuck. You know what I mean? Like, especially if you're a developer and you're supposed to like, kind of, you know what I mean? Like have the whole logic of everything in your head all the time. And then you're like, I don't know what to do. It's like, Who wants to say that, you know? So actually the hill charts are sort of a proxy for that. If something isn't climbing over the chart, it's a signal to the outside that something's wrong internally, that something isn't clear or somebody's stuck somewhere. The other proxy that is something on beta that I can click through that wasn't there five days ago, you know? I mean, the real truth is always the code, right? Is the shipped code that actually does stuff. So if... If a team is working on something and someone who's responsible for sort of, we don't actually have exactly people who are managing the whole team, but we have people who are more senior who those people report to. If somebody's kind of wondering, I wonder how that project's going. And they go and they look at the beta and they can see that new stuff is deployed. And it's like, oh, they're building stuff, must be fine. Or if they look at, nothing's deployed on the, but they look at the hill chart and they can see that something, meaningful got solved recently, you know, which probably means that a push to beta is coming soon. Then they say, okay, I see progress. But if they don't see progress, then they might tap a shoulder and be like, hey, what's going on, right? And then there might be an ad hoc meeting. There might be a little troubleshooting session to untangle something, you know, it can happen like that. But it's totally, it's totally ad hoc. And it's totally from the point of view of providing support. Like the team shouldn't need anything. And their performance proves that. Our teams are amazing and they don't need help very often. Sometimes it's in the nature of the work. Sometimes it's just a super gnarly thing that we're trying to do. Or maybe we left something out in the shaping that we didn't consider or couldn't have foreseen. So things come up. But it kind of goes back to work doesn't come segmented on a grid. It's a weird animal and you have to figure out what kind of animal it is. And so I think it's really important that the team is uninterrupted by default. But then, of course, you can ad hoc intervene if you don't see any signs of progress or sometimes a designer will raise a finger and be like, look, I just want your input on this. There's totally room for that. I'm curious the type of team this is for because you have methodologies. We talked about Agile earlier on about where it applies. You've got some, you know, you even have this idea of, geez, I can't remember what it's called, but it's, you know, the VIP methodology basically, you know, is it fit for a brand new startup trying to discover their product? Or is this more for mature teams or more mature teams? Like, is this a one size fits all for anybody building any software product hands down? Or is it more like pick and choose? There's actually two books in this book. There's a book of principles and there's a book of specific tactics. And if you take a little time with it, I think you can tease them apart. If you're a team of three people, you know, a founder, let's say like a tech, like a founder, who's also a designer and, and, and, and two programmers and you're working together, you know, you, you, it's not going to make sense for you to hold a betting table and, and plan six weeks ahead and then like delegate work to yourself. Like you, you, you don't need to write a pitch necessarily because who are you writing it for? Like you're all just. you're all just like together at lunch every day you know what i mean like right it's a whole different world in kind pitches so to speak like it doesn't have to be a formal written it doesn't have to be formal so so um what but the thing is that what we look at as we look at this that this transition in scale from you know three people to a dozen people to 30 and on you have a transition from hats to to people all the same things need to happen If you don't shape the work and you just take on something that you don't know what you're going after, you're going to get lost and wander around. So we've been shaping work since the beginning in the sense of like being very deliberate and clear and not just jumping into something that has a bunch of unknowns in it, you know. But in the beginning, that shaping is going to be a hat that you put on where you're like, OK, I'm not coding right now. I'm thinking about the next thing and I need to eliminate any rabbit holes before we really commit ourselves to that this is the next thing we're going to build. Versus when you reach a certain scale, it's not practical and it's not effective for everybody to be thinking about what to build next. You're going to introduce a more varied and specialized skill set as well. So for example, we have designers here who are going to out, all of our designers are going to out design me. more than 10x when it comes to implementing and making all the choices and trade-offs in like what is the actual design supposed to be. But I think everyone would agree that like I can bring something to the table that's unique in terms of sort of integrating the strategy and the technical side and defining something at a higher level of abstraction that's doable, that has business value. This shaping thing is actually a different skill set. than the standard design skill set. So we start to develop this relationship as we hire more people where we really look to each other with respect and you're like, wow, you could do that way better than I can and I could do this better than you can. So I'm going to figure out where I sit in the organization so that I'm adding value to this sort of, you know, there's this sort of supply chain I've been describing of work from a raw idea to an actionable idea to an idea that's actually scheduled. you know, to something that is getting built out and mapped and scoped to something that ships. So these are different skills. So the six week thing, the formal betting table, two tracks where we've got shaping happening in parallel to building and we're dropping in shaped work, you know, for the next cycle. That's all designed around our current size, which is like two core development teams that are running in parallel, plus senior people who are able to think about what to do and don't also have to build it themselves all the time yeah you know when i described it to jared when we're talking about uh the details of this was like is it like a recipe right am i making a dish for six people four people or two people because the same ingredients go in the same you know product for lack of terms comes out yeah the process is all the same except like you know maybe there's two you know instead of four or whatever it might be you know right you just simply shrink down your recipe so instead of six weeks and two weeks you know does some other time factor make sense in yes different size teams i think it probably does to be honest because when you're really small and your product doesn't do anything um there's this the difference between nothing and something can be really really big with with a little bit of development work i mean i do a lot of side projects so you know we all know how this is like you've got those four hours on a Saturday and you went from like nothing to the feature basically sort of works if you just go down the golden path. That's huge if you're in the early phase of a product. So I wouldn't devalue the idea that a small team who's just starting out sets a goal for two weeks and pursues it and then moves on and then picks off the next thing to do. I don't think there's anything wrong with that. But it's important to create the contrast that we're not sprinting, we don't have a backlog. We're not doing grooming and we're not just incrementally biting away at something that's bigger. There's a huge difference between as a tiny team defining for yourself a two-week appetite and saying we're going to come up with a solution that's a two-week size solution. And then using your ingenuity. Time is of the essence at that stage too. Working product, feedback loop, et cetera. And the methodology I was thinking actually that. drop my mind and i have no idea why is the lean startup methodology that that was sort of this description of how you could begin a company how you should develop a product and in many ways it was agile-ish or very agile like it had a cycle it had a feedback loop it had a you know a deliver you know a gather information and sort of like rehash how it could change for the future and this iteration cycle but it's it wasn't exactly agile it wasn't exactly just its own thing and this doesn't seem like it's against that but not not much like it There's some similarities, but not exactly. The big trouble that people get into, as far as I can see from afar, because I haven't, I've never adopted a whole hog myself. So this is just for me of looking from the outside in and other teams. There seems to be a lot of struggle with MVP, where people define the minimum valuable product as something that kind of works and sort of validates the concept, but isn't actually a quality thing that you would want to live with in your code forever. And David created this culture of code from the very beginning where we never commit anything to code. And this goes back to when we were three people, and it's true today, that we don't want to live with and look back on our future selves six months from now or three years from now or 10 years from now. The code has got to be good always. So we always talk about half versus half. And I don't think people really appreciate always who are doing the lean thing how good minimum is. You know what I mean? And what quality means in that context. And the software industry has a lot of deep knowledge in certain ways and in certain corners. And in other ways, the software industry is quite immature compared to, for example, the auto industry. And if you look at the literature around quality in the auto industry, they have so many different ways to describe different types of quality. And in software, we haven't really taken that up. So I think there's a lot of opportunity there. if you're interested in the lean stuff because the essence of it is make sense to to take a closer look at what quality means yeah so you're not against lean you just think in this case it's you're you're operating on a different type of uh team even like you've got an established team an established product yeah you know but lean is more for beginning and i think mvp as you said mvps have a good place but they're not it's not at all what you're trying to prescribe here you know honestly a different animal i have to say i don't really like that framing Because I think that the essence of lean is like ship to learn. Right. I can't find anything in a lean book that says more than that. So honestly, like if it doesn't say more than that, in my mind, and I'm being a little hard on it here, but it kind of goes into the BS camp. If I can compress it down that much, then what's in there? That's true. And I think a lot of the challenges are how do we actually, like, okay, we want to ship something to learn. How do we do that? How do we actually define something so that we actually know what the end looks like so that we actually get to the point where we ship it? So that already introduces questions of shaping. And which thing do we choose to spend our time on right now to learn about? Because there's a million different things that we could test in our MVP. We have to make choices so that gets into betting, right? And then even if we shape it well and we pick the right thing to do, it's very easy that if you just delegate a bunch of tasks and then you don't have a way to deal with all the unknowns that pop up, that you're going to get stuck along the way and it's going to take four times longer than you thought. So how do you deal with that? Like all these other things, I think, are the deeper problems. Because if Lean really helped you, everybody would have a successful startup, I think. You know what I mean? It's like... It's such a simple idea that you need to put together a lot of other skills, I think, to be successful. And those skills are just as true when you're in the very beginning and you're trying to figure out if something is viable. And when you're successful and you have an established customer base, but you don't want to waste your time and you don't want to be complacent just with the one feature set that works and you don't want to screw up your product. We're running short on time Ryan. I want to ask you a couple real quick questions about shaping about betting before we let you go here Can you share a couple of shaped? Pitches that were actually executed on by base camp in the last six months to a year so we can get an idea of like what Because I have a hard time with like what is six weeks of work? What is a shaped idea? What are those pitches actually look like? I'm sure the book fleshed that all out But for those of us just wondering what's a shaped idea and maybe a real-world one that y'all have built would be useful Yeah, sure. So I'll point to two examples that are in the book so that way people who are interested can dig deeper into them. So at the end of the chapter on pitching, there's two example pitches. And well, one of them is a feature that we call to-do groups. So we wanted the ability to sort of segment a to-do list into subgroups. We wanted to do it in such a way that it was going to be a big boost. you know it's like a whole other level of organization for the people who can take advantage of it but at the same time we really didn't want to add complexity to to-dos because base camp has this kind of we call it fisher price simple it's like almost toy like it's so simple for people to approach it so how do we how do we enable you to to how do we how do we not change one of the core features of base camp but introduce this entire new level of of structure in in a to-do that was a six-week project and um it actually touched a ton of stuff. And it involved a lot of hairy questions about how do we display completed items and it involved changing the JavaScript that we use to reposition items, not only within a list, but across lists, you know, I mean, hairy stuff. And that was done in six weeks. Are those the kind of things that were then discovered by the builders or was that known by the, what do you call it? Yeah, we can say shapers. Shapers up front, yeah. So, the shapers are, generally a shaping team looks like a very experienced designer and, or the most of what you have, you know what I mean? Because if you're a startup, you do what you can, you know what I mean? And then you need help from a technical person. to push back on the thing that you want to do. It starts from the customer end with the design, but then you need that tech pushback on feasibility. We never capture everything that's going to come up that's going to surprise us. But if you've seen enough projects and you've done enough software development, you can look through a concept and say, okay, this is reasonable, this is reasonable, this thing is going to be a mess. Like, what about that? Okay. So there's certain things in the shaping process. that we actually make calls on because we know that if we don't, if we don't sort of put a very specific solution to this one tricky point in place, the team might kind of get lost on it. And from a technical point of view, sometimes you're like, hey, that's a no go. Don't touch that thing. Just use this hack. You know what I mean? Like we're not going to regroup the completed items. We're just going to append a label to the end of them that says what group they were part of before. Right. And that that's a little part of the design that you kind of fixed. Because it's part of ensuring the success of the six-week viability. You know what I mean? So you're being very patchy with how you sort of, where you go down into detail about the design and where you don't. Interesting. So another random question. So one of the nice things about software as a service is the ability to always be shipping and to be constantly refining and improving. Are these things that you wait for the, for the two week down times to do or are there ever a pitch which is like here are a grab bag of amazing little things that we want like to get done in six weeks how do you approach refinement? Oh that's great because that touches on one thing I didn't mention so we arrived at this convention we call it big batch versus small batch cycles a big batch cycle is a single project for a single team for six weeks end to end and a small batch cycle is actually like a little grab bag So we're going to give a team six weeks and we're going to shape up a handful of things that are maybe like one to two weeks each, but they're not on a schedule to deliver like week one and then you ship and then week two and then you ship. There's no schedule for them. It's just like, here's a bag. We'd like it if all this stuff could get done. And then they figure that out. And they know the appetites for each individual thing. So they're not going to spend the whole six weeks unnecessarily on one of them, you know? And that's really... I mean, that's a real luxury having two teams because we can make progress on one big thing and we can kind of nip and tuck a bunch of small things at the same time. Before we had enough people to do that, we actually alternated. So, because it's actually also good for morale, you know what I mean? Like you make a big push, you make a big ship and you have to announce it and you have to do like new support questions come in, all this stuff. And you're like, man, let's just fix some stuff for the next few weeks. You know what I mean? Quick wins. Quick wins. Exactly. Right. So I think this, this comes back to the question about. scale. You know, I think a lot of this is that if you're bigger, you can parallelize some of these things. And then if you're smaller, you just take whatever was parallel and you turn it into an alternation. You know, a little bit of this and then a little bit of that. Very cool. Last question for me is how much fun is the betting table? I think that's probably, for me, that seems like it'd be a great meeting. Everybody get their pitches out. You got to argue who's what's in, what's out. I mean, you got to pick the work for the next six weeks. So probably a pretty big deal. There's probably some impassioned pitches going on. You know, it's funny. It may be our setup in our culture, but the thing is that if you have very senior people at a betting table, which is by definition what it should be, right? Because they're setting this course of a company. They have very little time. and their time is always very compressed and very dense. So what tends to happen is the betting table tends to be like an extremely rushed conversation that's mostly leaning on past interactions and kind of things that you've seen coming your way in the days ahead. You know what I mean? I actually think that... You're so much cooler in my head. Yeah. But this is the reality, I think, for most business, that nobody at the top has time. And they rely honestly mostly on trust. There's a whole book about this from the 70s called Managing the Resource Allocation Process by Joe Bauer. And it's about how a lot of the work that gets done actually moves up because of a channel of trust. And then once it gets to the top, all the people look at is kind of who it came from. Our organization is so much smaller that it really is about the work. But there's only a few things on the table. And there's been enough kind of back and forth I might be going back and forth with Jason about an idea and we can already tell is this coming together as like we should probably do this, you know, and then he's having some side conversation with David about other things that I don't know about. And then by the time the betting table clicks in, it's almost like obvious because everything has so much pre-work on it. It's like molecules that like snap together based on the, you know, the bonds and everything like that. It's just kind of like click. This is what makes sense right now. Gotcha. I could imagine it might be more contentious in other environments, but that's sort of where we sit in our current situation, you know? Well, the three of you have been working together for 16 years, too. That's true. There's a lot of deep trust and a lot of, I guess, good expectation because of that trust. I think you just pulled out the thing that I couldn't see from sort of swimming in the water, is that the fact that we have such a long history together probably makes those meetings shorter. I can imagine them being... quite long and interesting in another circumstance, you know. For me, the real juicy time is if I get in a room with Jason or I'm on a call with another one of the designers and we're like hashing out a totally new idea and we're shaping it, you know, or if I take that to David and he's like pushing back on it technically or, you know, like challenging aspects of it, like that. push and pull. I actually think that that's where the real negotiation happens that's meaningful. If you're fighting the hard fights when you're defining the work, then the process of scheduling stuff and choosing what to do I think actually gets easier. Yeah, especially have a good handle on where your company's trying to go and if you're fairly mature in your revenue models and cash flow and... you know, trajectory is a word you haven't said in this call here, but that's one that I actually attribute to me liking more because of your past kind of sharing, you know, rather than roadmap, it's trajectory, where we're trying to go kind of thing. Yeah. And I think when you have that, it's a lot easier to sort of sit there and say strategically, the next step should be these things because of these indicators. It can be, it can be. But the thing is that I think a lot of people who live in startup world, imagine one day the growth curve is going to go up. And then they're going to live up in some happy place where they're surviving forever. And the nasty truth is that the growth curve goes up and then if you don't screw it up, you get to stay there for a while. But eventually stuff will start to go wrong. And it comes down. You know what I mean? Like it starts to falter or... Sometimes it goes up again. Yeah. Or you have paying customers, you think you're fine, you build something and it's totally the wrong thing. And now the perception of you has changed. Customers have a different perception. They might not like it. They might evaluate a different tool. There's no guarantee that once you get up over the first growth curve that you're set. You know what I mean? So we definitely have periods where what to do feels more momentous. You know what I mean? It just depends on where you're at in the business and what's going on. I guess one last thing to point out too is that this... book is entirely free to read online, right? That's right. And so if you've been listening to the show thinking, gosh, I gotta get this book. Well, it's available to you for free at basecamp.com slash shape up and a slash books actually has all of your books. Is this the first, I think getting real was online for free, right? Or you had a, a, we are to getting real. It was for free online. We did put getting real for free online, but I think we were collecting email addresses for it and shape up. We're not even collecting emails. But you are if you want a PDF, e-book, or print version, which you're going to do in the future potentially. Yeah, so if anybody wants a different format, they can sign up just to find out about it. But that's not a gate to reading it. That's just a way for us to reach you if you want to hear about it. I like that. So, I mean, you can go to this page here. It's got everything. I think even the site for it, I don't know if it's actually Basecamp.com's marketing site. I don't know how this, if this is its own project. But I think you've done a great job of actually fleshing out the ability to navigate around this book. I love the... I don't know who did this, but I love the continue where you left off button. Yeah, that's Adam. Our marketing designer, Adam, did an incredible job on this. Yeah, great job on this. I just noticed that. That is nice. Back to where I was. And I'll just put the word out that if, I don't know when the podcast is going to air, but if it's before August 28th and 29th, I am doing a rare workshop on ShapeUp so people can come in and ask questions and really dig in and figure out how to apply it to them. I'm doing a two-day thing with Bob Mesta, one of my mentors. So the first day is going to be on jobs to be done, all about sort of figuring out like what to build and what strategically is the right direction to go in. And then the second day is all about shape up. And he's leading the first day. I'm doing the second. That's going to be in Detroit, August 28th, 29th. And I can give you guys a link for that or people can kind of look through my Twitter to find that. And it'll be an opportunity. Awesome. When you have, if you know it, you can say it now. If you don't know it yet, then we can definitely put it in the show notes. We love to do that. listeners of this show know we strive very hard to have show notes and then are also editable. So if you go to our show notes and you're like, well, this link was mentioned in the show, but it was not in the notes. Hey, you can edit those show notes on GitHub. That's right. Or if the link's broken, which never happens, but just in case. Never happens. Ryan, any closing thoughts on teams out there struggling to find process? Is it just as easy as going to basecamp.com slash GitHub? Or what? I would say go to Basecamp.com slash ShapeUp and then use it to create language within your team. And you'll find that it's easier to articulate the problems you've been experiencing that you didn't really know how to talk about. And then once you start to have that conversation, you might find different pieces of the method in the book that you can pull in right away. And other things, you'll at least be able to start having the conversation and that's going to set you down the right road. And people should also feel free to email. You can email ShapeUp at Basecamp.com. And that's going to go to me and I'm taking questions there. I've also been talking to teams all the way from tiny startups to major, you know, hundreds of people on the digital teams and thousands of people in the company with questions about how this applies at different scales. So I'm very happy to field those questions and also kind of curious about those worlds. So happy to talk about those things. I'm glad you said that because in the pre-call, Jared asked you about bugs and what to do with those. That didn't end up in the show, but you'd mentioned that that chapter wasn't there a week ago. That's right. Is that roughly the case? That's one of the benefits of publishing on the web. I started getting question after question about what about bugs, and I thought, oh, I have to put this in there. So I added a section about that. I actually have a handful of updates to the book that I'm working on right now based on the questions that are coming in. So it's really cool to have that feedback loop. Well, Ryan, thank you for sharing your time with us today. And I know you put a lot of work into all the things you do. And this book is probably just like everything else you work on. And I appreciate laying that wisdom down. In a lot of cases, we have people who want to give back, don't find time to give back. But you all at Basecamp seem to find just every possibility to reuse your exhaust, the byproduct, so to speak, of what you do. And I totally appreciate that because now we can. you know, sort of peek into the way you all do things and start to, as you said, create our own glossary, our own terminology, something to collaborate around and find some way forward in doing our projects. So, Lon Wendley saying thank you. Thanks a lot. It's been awesome to talk to you guys. And you guys are really thoughtful and you're also really good at what you do. So, this is a treat to be on the show. Awesome. Thank you, Ron. All right. Thank you for tuning into this episode of the changelog. Hey, guess what? We have discussions on every single episode now. So head to changelog.com and discuss this episode. And if you want to help us grow this show, reach more listeners and influence more developers, do us a favor and give us a rating or review in iTunes or Apple podcasts. If you use overcast, give us a star. If you tweet, tweet a link. If you make lists of your favorite podcasts, include us in it. Also, thanks to Fastly, our bandwidth partner, Rollbar, our monitoring service, and Linode, our cloud server of choice. This episode is hosted by myself, Adam Stachowiak, and Jared Santo. And our music is done by Breakmaster Cylinder. If you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master. Or go into your podcast app and search for Changelog Master. You'll find it. Thank you for tuning in this week. We'll see you again soon. Hey, guess what? Brain Science is officially launched. Episode number one is on the feed right now. So head to changelaw.com slash brainscience to listen, to subscribe, and to join us on this journey of exploring the human mind. Once again, changelaw.com slash brainscience or search for brain science in your favorite podcast app.

Ryan Singer, head of Product Strategy at Basecamp, joined the show to talk about their newest book — Shape Up: Stop running in circles and ship work that matters. It’s written by Ryan himself and you can read it right now for free online at Basecamp.com/shapeup (https://basecamp.com/shapeup) .



We talked about the back story of the book, how the methodology for Shape Up developed from within at Basecamp, the principles and methodologies of Shape Up, how teams of varying sizes can implement Shape Up. Ryan even shared a special invitation to our listeners near the end of the show to his live and in-person Shape Up workshop on August 28th in Detroit, Michigan.



Join the discussion (https://changelog.zulipchat.com/#narrow/stream/456187-interviews) 


Changelog++ (https://changelog.com/++)  members support our work, get closer to the metal, and make the ads disappear. Join today!


Sponsors:




  •  Linode (https://linode.com/changelog)  – Our cloud server of choice. Deploy a fast, efficient, native SSD cloud server for only $5/month. Get 4 months free using the code changelog2019. Start your server - head to linode.com/changelog (https://linode.com/changelog) 
     
     
     
  •  Keen (https://keen.io/changelog)  – Keen makes customer-facing metrics simple. It’s the platform that gives you powerful in-product analytics fast with minimal development time. Go to Keen.io/Changelog (https://keen.io/changelog)  and get your first 30-days of Keen for free.
     
     
     
  •  TeamCity by JetBrains (https://teamcity.com/changelog)  – Deliver software faster with TeamCity — a self-hosted continuous integration and delivery server developed by JetBrains. TeamCity is super-smart at running incremental builds, reusing artifacts, and building only what needs to be built, which can save over 30% of the daily build time.
     
     
     
  •  Fastly (https://www.fastly.com/?utm_source=changelog&utm_medium=podcast&utm_campaign=changelog-sponsorship)  – Our bandwidth partner. Fastly powers fast, secure, and scalable digital experiences. Move beyond your content delivery network to their powerful edge cloud platform. Learn more at fastly.com (https://www.fastly.com/?utm_source=changelog&utm_medium=podcast&utm_campaign=changelog-sponsorship) .
     
     
     




Featuring:

  •  Ryan Singer – Website (https://www.feltpresence.com) , GitHub (https://github.com/rjs) , X (https://x.com/rjs) 
  •  Adam Stacoviak – Website (https://adamstacoviak.com/) , GitHub (https://github.com/adamstac) , LinkedIn (https://www.linkedin.com/in/adamstacoviak) , Mastodon (https://changelog.social/@adam) , X (https://x.com/adamstac) 
  •  Jerod Santo – GitHub (https://github.com/jerodsanto) , LinkedIn (https://www.linkedin.com/in/jerodsanto) , Mastodon (https://changelog.social/@jerod) , X (https://x.com/jerodsanto) 




Show Notes:




     
     
  •  Shape Up (https://basecamp.com/shapeup) 
     
     
  •  Foreword by Jason Fried (https://basecamp.com/shapeup/0.1-foreword) 
     
     
  •  Principles of shaping (https://basecamp.com/shapeup/1.1-chapter-02#wireframes-are-too-concrete) 
     
     
  •  Example pitches (https://basecamp.com/shapeup/1.5-chapter-06#how-we-do-it-in-basecamp)  — “How we do it in Basecamp”
     
     
  •  Bets, Not Backlogs (https://basecamp.com/shapeup/2.1-chapter-07) 
     
     
  •  How to Begin to Shape Up (https://basecamp.com/shapeup/4.1-appendix-02) 
     
     
  •  Summary of the Shape Up method (https://basecamp.com/shapeup/4.2-appendix-03) 
     
     
  •  Shape Up glossary (https://basecamp.com/shapeup/4.5-appendix-06) 
     
     
  •  Ryan’s tweet (https://twitter.com/rjs/status/1158421397040795648)  about the Shape Up workshop (https://www.eventbrite.com/e/developing-successful-new-products-with-bob-moesta-ryan-singer-tickets-66122545313) 
     
     
  •  If you have questions — email shapeup@basecamp.com (mailto:shapeup@basecamp.com) 
     
     
  •  Getting Real (https://basecamp.com/books/getting-real) 
     
     
  •  All of Basecamp’s books (https://basecamp.com/books) 
     
     





Something missing or broken? PRs welcome! (https://github.com/thechangelog/show-notes/blob/master/podcast/the-changelog-357.md)