The Changelog: Software Development, Open Source - Shaping, betting, and building (Interview)

Episode Date: August 16, 2019

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. 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.

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 five bucks 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 lynda.com slash changelog. 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 Shipwork That Matters. It's written by Ryan himself, and you can read it right now online for free at Basecamp.com slash Shape Up. We cover the backstory of this 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 ShapeUp, and Ryan even shared a

special invitation to our listeners near 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 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 with Basecamp, maybe. That's right. 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, it was, 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. We actually had to learn through that growing process how to formalize what we do because otherwise you can't just have a bunch of opinions and principles at that size. You have to actually have 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 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 what you're saying here. Because, I mean, if you were untrusted, hey, this would just be a book.

It wouldn't be something for everybody to like, oh, wow, this is Ryan writing this and have the 16 years, as you said, experience behind you, Basecamp 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, were 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. Come on, you're speaking my language here. You're bringing up some PTSD. Come on. 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 something that kind of breaks that duality between either you're doing waterfall or 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 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. You know, for us, it's just how we work. And 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, in the end, and, uh, I was talking with my friend, Chris Beck, who, who helped quite a bit. He had 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 when you're, when to each other, when you, when you recognize that you need to, to, to improve or, or that you're off track internally. And I, I mentioned to him, you know, we still say to each other sometimes, Hey, we got to get real with this, you know? And, um, and then I realized, I realized, you know what, uh, 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, and, and confidently ship, we actually say like, you know, we have to shape that up. Because shaping 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, we'll, we'll call it that. And whether, whether that catches on as a method name or whatever, I mean, you, 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. 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 backend 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, of what I have to do unfolding and then, and then figuring out how to tackle it and then completing it. We need language for all those things, you know? So that's, 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 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 you know practices to do the cadence and to do 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 we weren't aware of. And now our two-week sprint isn't really a sprint on that. It's like, well, we have to backpedal 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 about processes, methods, and practices. I'm curious as 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 Basecamp, the product and Basecamp, the company is that what it does well is it catalyzes self-organization. who kind of want to make progress together and want to work together and make something great. And that can happen as a Basecamp customer where you're in some other domain, you know,

you're working at a creative firm or you're working at a nonprofit or a law office or whatever. There's some kind of sense of we want to work together to get somewhere, right? 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, and then delegates down a

million tasks. And then 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? 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, that work, work has a natural anatomy. And, uh, it's a sort of a, you know, the, the, it's not a vegetarian friendly analogy, but the, you know, the, 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 up front, 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. You know, the structure of the project is not made in day size bites and week size bites. It's like, you're, 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 like 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? 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. 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. We built V1 with one programmer working 10 hours a week. And so we were constantly asking ourselves, if we asked ourselves, how long does it take to build base camp? 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 workout 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, um, that scoping practice started in 2009 because we had to build out, we had four products at the time, base camp, backpack, high rise and campfire. And we wanted to, uh, tie together the, 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 preexisting user bases into a single sign-on thing. So that was such a huge technical thing that 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 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 switched, 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 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 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. 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 can be up and running in 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 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. Don't ask me to sprint for six weeks. And, uh, and, and if you did, you wouldn't like the result because burnout real fast. And this is a huge problem is that if, 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, 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, and then it recedes again. And inside the six weeks, there's a, 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, what APIs do I need to, 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.

You know, it's not over, but you need that time. That's a huge part of why people have so much technical debt. 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, you know, it's better for your future self and for future others. Yeah. How you describe that kind of remind me of, this is nostalgic too, by the way, I'm sure you'll both nod your head when I say it, but it reminded me of HashRockets 321, a 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 could know where you're trying to go from there and what you didn't realize was that before the three two one the three days so to speak you actually had several weeks of you know very intentional meeting planning discovery etc that was kind of prefaced to this and it's 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 in the what's the two in the one, like two weeks and one. I could,

I swear it was called three, two, one. I could be wrong. Somebody, I remember the name. I just don't remember the two. 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 teasing it too much at a high level 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 and the, 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.

Like something bad happens to the employees? What do you mean? Well, we don't have any roasting pits you know oh you said something bad happened like okay i thought you said something bad happens there's a sense of you know if 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 um and then we've got two weeks of cool down at the end of every six weeks. And that originally started because we recognize 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 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 they 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, whatever. 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 interdepartmentally, 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. You know, if I give a team work that is totally underspecified, like go build a calendar.

I mean, which, you know, a calendar could do a hundred things. Which 10th of a calendar should they build first, right? They could build the best ever RSVP and invitation and, like, schedule alignment system. Like, kind of go down, like, a doodle direction, you know, 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, right? Where do they go, right? 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 overspecify 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 upfront, 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, to use actually exist there? 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, we might need to, that might be an issue, whatever. 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 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 the work that we do in the shaping phase it doesn't automatically directly go on to some kind of a conveyor belt or a queue there's'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, right? 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, 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. So you have this question of what actually matters. So that's where we get into betting. Betting is very different than planning. Planning has a general connotation of certainty, and betting 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, I know how much I'm betting and I should have a capped downside and maybe an open-ended upside. So you know what I mean?

At the most, I'm going to 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, 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. And then we also have this thing 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, some, some new shaping work, right? Because whatever it is

that we, 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. So that's, 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, the, the, we just need one more week thing kind of takes us further into, into

part three of the book. This takes us into the uphill and downhill work. So 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 and so there's there's unknowns there so there's an uphill phase where we 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. 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 what 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 a everyday example of, of planning a, you're going to have a dinner party. If you, 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 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, OK, 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. 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, 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, then 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, that's not how we make bets. You know? We want to put that off onto the shaping track where we're going to, 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, you know? So, so that kind of takes us through, there's a raw ideas, customer requests, stuff that the, that, that the CEO dreamed up yesterday, all that stuff needs to get shaped before it's a good potential bet. Cause 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 we get into tools and techniques for how we kind of hit that right level of abstraction in the book. 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. 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. 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, that have been risk reduced as much as you can manage. Of course, you can never take all the unknowns out, but we've done our best. And 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, when you, if you, 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, 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 what you actually have to do right so 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 like what it's like demeaning that it implies a certain level of code monkey or like grunt work like here's your task go do the coding thing there's like a that is exactly that's exactly the terminology that that 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 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, and you want to, 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, and put them in a position where they're, where they're making those judgments, instead of just executing stuff that somebody else kind of planned out for them. Yeah, and then we get into sort of what are the techniques 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?

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 are who are um 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 in a kind of small way on ordinary projects all the time. Like first I'm going to get all this code backend 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 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 that 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 program 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 going to 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 trust that your instruction manual and your design is going to like, it's end and back end together and deliver something that works. That's 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 like 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 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 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, 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 a, in a, maybe, I don't know, three, four days of work together, you know, cause if

it's bigger than that, it starts to feel like a project, 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 what you're going to name the columns, what you're going to name the major methods. 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 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. So 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 try it in Jira. You know what I mean? 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 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 and 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, 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, way more work than what you characterized up front. So, so it's, it's a natural function of opening the hood that the scope grows, you know? 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, and the machete that we use is, is this little key on the keyboard. It's on the upper left, you know, depending if you're on a sun layout or a modern layout, you know, uh, it's the till day. And so we put a till day 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 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 it's it's it's not just like trimming off things that are easy to cut it's really being like man do we really need that you know yeah 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 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 TeamCity. TeamCity is a self-hosted continuous integration and delivery server developed by JetBrains. 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. We'll see you next time. 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, is the way we've, we've built it in Basecamp is that scopes to do lists in Basecamp, they, they map to dots on a hill chart. So the, the uphill, the hill chart, if you just sort of look at it kind of looks like a, like a, like a, what do you call it? Like a normal, like a normal distribution, a bell curve. But, curve. But that's not what it is. It's just the same shape. And the left side is, is, is showing if we're, 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, I've identified some of the moving parts, you know, I've, I've stubbed something. I think I have an idea about the approach. And then maybe all the, nearly all the way up the hill is like, I've, I've stubbed it. I've kind of validated that the things wire together. I thought that they would. And, um, I'm not, I'm not seeing anything left that, that, that isn't clicking together. So now you're on the top of the hill. And, and then, you know, maybe, maybe now you're on the top of the hill. And then, you know, maybe, maybe a little bit over the top of the hill is like, I've, 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,

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, 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 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, you know? Yeah, that's a very, I think that's an insightful conclusion that 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 is. It's just reality. Like, look, nobody actually knows, but they can tell you, they can tell you about a single piece that they're working on

if they've gotten it straightened out or not. You know, 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 that there's no collaboration? How does the designer and the two developers, for example, doing the work 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 check-ins along the way? Is there 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're, 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. I'm not doing so well over here. 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 um 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 that um is is something on beta that i can click through that wasn't there five days ago you know know, that's, I mean that the real truth is always the code, right?

Is the shipped code that actually does stuff. So if, if, if a team is working on something and, 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, 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, you know, 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 the 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 even have this idea of, uh, geez, I can't remember what it's called, but it's, 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, 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. Cause 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, 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 okay 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 that this is the next thing we're going to build right um 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 know 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 like 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 like, 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, 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 supply chain 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 bedding 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, 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,

the way I described it to Jared, when we're talking about 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, you know, maybe there's two, you know, instead of four or whatever it might be,

you know, right. Do you just simply shrink down your recipe. So instead of six weeks and two weeks, does some other time factor make sense in different size teams? I think it probably does, to be honest, because when you're really small and your product doesn't do anything, 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 teen 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. Yes. Working product, feedback loop, et cetera.

And the methodology I was thinking actually that dropped my mind and I have no idea why is the lean startup methodology. 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 in this iteration cycle. But 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 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 tends, 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 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 operating on a different type of team, even like you've got an established team, an established product. Yeah. You know, but lean is more for beginning.

And I think, 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, 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 don't, I can't find anything in a lean book that says more than that. So, 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, if I can compress it down that much, then, then what's in there. That's true. 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? 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 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, 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, you right well we're running short on time right i want to ask you a couple real quick questions about shaping about bedding before we let you go here um 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 fleshes that all out but for those of us just wondering what's a shaped idea

and maybe a real world one that you all have built would be useful yeah sure so i'll i'll point to um 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, 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 nother 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 do's because Basecamp 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 how do we how do we not change one of the core features of Basecamp, but introduce this entire new level of structure in a to-do?

That was a six-week project. And 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 used to reposition items not only within a list but across lists you know i mean hairy stuff and um and that that that got that was done in six weeks are those the kind of things that were then discovered by the builders

or were that known by the what do you yeah we could say shapers. Shapers up front, yeah. So the shapers are generally a shaping team looks like a very experienced designer and the most of what you have, you know what I mean? Because if you're a startup, you do it, 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 push back on the thing that you're that you want to do um it starts from the customer end with the design but then you need that tech pushback on on feasibility we never capture everything that's going to come up that's going to surprise us but um if you've seen enough projects and you've done enough software development you can you can you can look through a concept and uh and say okay this is reasonable this is reasonable this thing is

going to be a mess like what about that ah. So there's certain things in the shaping process that we actually make calls on because we know that 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'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. 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 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 would 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 uh we'd like it if all this stuff could get done and um and then they figure that out and they they know the appetites for each individual thing so they're not gonna spend the whole six weeks on necessarily 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, 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? 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 and 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. Exactly. Right. So I think this, this comes back to the question about, um, scale. You know, if I think a lot of this is that if you're bigger, you can parallelize some of these things. And if you're smaller you just take whatever was parallel and you turn it into an alternation yeah 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 i like that seems like it'd be a great meeting everybody get their pitches out you know you gotta art you gotta argue who's what's in what's out i mean you gotta pick the work for the next six weeks so probably a pretty big deal there's probably some impassioned pitches going on you know um it's funny uh it may be our setup in our culture but um 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. You know, the, the, but this is the reality, I think for most business that nobody at the top has time and, uh, and they rely honestly, mostly on trust. There's a whole book about this from the seventies called, um, uh, managing the resource allocation process by Joe Bauer. And, uh, it's, it's about 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. You know, that's not 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 snap together based on 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. 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. One 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 where the real negotiation happens. That's meaningful. If you're, if you're fighting the hard fights when you're, when you're, when you're defining the work, then the, the, 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 is trying to go. And, you know, if you're fairly mature in your revenue models and cashflow 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 i think when you have that it's a lot easier to 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 um 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 to it starts to falter or sometimes it goes up again yeah or or or or you you you have paying customers you think you're fine you build something and it's totally the wrong thing and now and now the perception of you has changed customers have a different perception they don't like they might not like it they might evaluate 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 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 prior to getting real, it was for free online. We did put getting real for free online, but I think we were collecting email for free, right? You had a book prior to Getting Real that was for free online. We did put Getting Real for free online, but I think we were collecting email addresses for it. And ShapeUp, 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.

Yep. 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. Right 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 ShapeUp 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 yeah it'll be an opportunity awesome when you have if you if you know it you can say it now if you don't know it yet then we can definitely put in the show notes we love to do that so listeners of this show know we strive very hard to have show notes and then they're also editable so if you go to our show notes and you're like,

well, this link was mentioned in the show but 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. Never. 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 shape up or what? I would say go to basecamp.com slash shape up 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, I'm taking questions there. I've also been talking to teams all the way from tiny startups to major, you know, hundreds, hundreds of people on the, on the digital teams and thousands of people in the company, um, 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, um, uh, happy to talk about those things. I'm glad you said that. Cause in the pre-call, Jared asked you about, uh, bugs and what to 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. is 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 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 long-windedly 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, Ryan. All right. Thank you for tuning in to this episode of The Change Log. 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 changelog.com slash brain science to listen, to subscribe, and to join us on this journey of exploring the human mind. Once again, changelog.com slash brain science or search for brain science

in your favorite podcast app. Bye.