Shaping, betting, and building

Ryan, we’re here to talk about your book, or I guess more of a topical thing that simply just your book. You always seem to have big ideas, let’s just say… Because you’re a big idea guy.

You’ve been with Basecamp - I guess 37signals/Basecamp; I guess we just moved to say Basecamp, right?

Basecamp, that’s right.

…for many years now.

Yeah, 16 years now.

That’s a long time. I’ve always looked up to you and the work you do, personally, and then corporately at Basecamp. 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, I thought that we had already 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, I looked at it and said “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. Because Getting Real is quite general. It’s saying 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 what we’ve been trying to say all along about how we work?”

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. 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 then you hire more people.

When we did v1 of Basecamp, the company was four people, and it was three of us who built v1 - Jason, David and myself. Now we’ve got – I think the core product team is around a dozen, and the whole company is about 50… So the dynamics have changed a lot. So it 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 actually have to 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.”

[04:25] So I feel like all the factors came together, but the big thing was, man, just talking to other people in the industry and hearing still - even though Agile and Scrum 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. I’m not sure 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 around 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 if you were untrusted, this would just be a book; it wouldn’t be something for everybody to be 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. Agile started off – those of us who were there when Agile was new were very invigorated by this huge swing of the pendulum, away from upfront design and masterplanning 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 is that the pendulum swung so far, to the point where there’s no planning, and there’s no clear direction…

Total anarchy.

…and now it’s like… You know, if you’re just working two weeks at a time and 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 “product role.” 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’ll happen.

Come on, you’re speaking my language here…! [laughter] You’re bringing up some PTSD. Come on…

Right…? But there is this thing where we need to sort of have a strategic, high-altitude perspective, where we’re looking a little bit further our in time, and we’re looking over a broader surface area and space, and we’re saying “What do we wanna accomplish? Where do we wanna go? What matters right now?” And this conversation about what matters doesn’t fit into a two-week cycle. So how do we 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 something that kind of breaks that duality between “Either you’re doing waterfall, or you’re 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, we do Shape Up… Are you trying to create that moniker, or is that just a byproduct of the book name?

It’s funny - you have to call it something… [laughter]

Right.

For us it’s just how we work, and we started to give names to the different practices. I was actually trying to figure out what to call the book in the end, and I was talking with my friend Chris Spiek, who helped quite a bit; he and Bob Moesta helped a lot with helping to pull out what we were doing and reflect it back to me, so we could figure out how to systematize it… And he said “Well, what do you guys say to each other when you recognize that you need to improve or that you’re off-track internally?” And I mentioned to him, we still say to each other sometimes “Hey, we’ve gotta get real with this.”

[08:27] Then I realized, you know what - when it comes to actually turning some kind of a raw idea or an impulse into something that’s actionable, that’s gonna ship and confidently ship, we actually say “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 ultimately is.

So that was the thing… Once we realized “Yeah, we’ve gotta shape that up”, ah - that’s actually a thing you can do; that’s a verb. Boom. We’ll call it that.

There it is.

And whether that catches on as a method name or whatever – I mean, you’ve gotta call it something. The important thing is I really wanna 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 back-end”, to “This is actually a project”, to “This project entails actual work, but we don’t know what the work is. You’ve gotta get under the hood before you actually know what the work is that you have to do…

Right…

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?

For sure.

So there’s all these different stages of “What I have to do” unfolding, and then figuring out how to tackle it and then completing it. We need language for all those things, so that’s a big thing that I’m trying to contribute here.

Especially if you have a product manager trying to drive a direction… As you said, they often fall into the product manager; like “Here’s what we’ve gotta do. Here’s stories, let’s do estimation…”, all the necessary Agile/Scrum methodology 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 task 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. We have to back-pedal to deal with things we weren’t aware of.”

Totally. In the book we call it “Imagined” vs. “Discovered” tasks. So there’s the tasks that you imagine, just by thinking in your head. “Well, we’re gonna have to connect to that API, and we’re gonna have to refactor this a little bit first, and then we’re gonna design some UI over there, and then it’s all gonna work.” And then you open the hood and there’s all this 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 back-pedal a little bit and describe what it is to be a successful team. 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, and methods and practices… I’m curious what you think – what are some things successful teams do to be successful?

Yeah… That’s a really great question. This is a little nerdy, but the way that I think about both Basecamp the product and Basecamp the company is that what it does well is it catalyzes self-organization. So you’ve got a whole bunch of people who kind of want to make progress together and want to work together and make something great, and that can happen as a Basecamp customer, where you’re in some other domain; you’re working at a creative firm, or you’re working at a non-profit, or a law office, or whatever… There’s some kind of sense of “We wanna work together to get somewhere.”

[12:17] And then the same thing with our teams internally - we’ve got programmers and designers who are extremely skilled, and are 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, 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 gotta be some genius somewhere who architects everything, and then delegates down a million tasks, and then that’s how the project gets done.

So I think a really successful team has this sort of guard rails, 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 guard rails 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.

Then they have the freedom and the autonomy, and very importantly, uninterrupted time - uninterrupted from the outside, of the team boundary - 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’ve 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. 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, and that’s where all the interesting work is and where all the challenges are.

So a good team is working together based on – I like to think of it that work has a natural anatomy… And this is not a vegetarian-friendly analogy, but the process of cutting apart the work is like butchering an animal; you don’t pick arbitrary points to make the cuts. 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 that often you can’t see… Interdependencies that play out in the current system, in one snapshot in time, but also interdependencies that play out over snapshots of time through time. Like “First if we do that, that’s gonna enable us to do that next, versus the other way around.”

So if we try to put everything into a plan upfront, like “These are the tasks, now go do it”, or if we try to segment everyone’s time, like “You will meet once a day, and then you will meet again once a week”, we’re trying to make something that has a very organic, natural, weird internal structure that we’re trying to determine - we’re trying to turn that into some kind of a periodic crystal. The structure of the project is not made in day-size bites and week-size bites. It’s like, you’re gonna have your head down for three days, and then all of a sudden you’re gonna be like “I’m ready for the next thing.” Or you’re gonna have your head down for 30 minutes and you’re gonna be like “I can’t even move forward. We’ve gotta talk”, you know what I mean? You can’t predict that when you’re doing novel work.

[16:00] So we try to set up the guard rails 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.

We should probably talk about the methodology, the major tenets, the cycles, the way it actually works… The shaping, the betting, 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’re even writing about…

Sure.

But I’m just curious, before we get into that, how long you 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 Shape Up 2, or do you feel like it’s been pretty solid for a while…?

Yeah… That’s interesting. Different parts of the method trace back to different points in our history. The basic notion of “We’re gonna set a fixed timebox and we’re gonna design TO the timebox”, as opposed to “We’re gonna estimate the work and then slice it into time units”, those are very different. There’s a huge difference between taking a – let’s say you take a ten-week project; let’s say you estimate something as ten weeks. Then you slice it into two-week slices. Now you’re doing the ten-week thing, but you’re just incrementally attacking it tactically, two weeks at a time.

Right.

It’s a huge difference between saying “We’re interested in spending six weeks on this thing.” So rather than estimating some solution as ten 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 timebox, whatever the size of that box is, started in 2003 when we did v1 of Basecamp… Because David was working ten hours a week.

We built v1 with one programmer working ten hours a week, so we were constantly asking ourselves – if we asked ourselves “How long does it take to build Basecamp?”, we would have never gotten it done; but if we said to ourselves, “Man, if we’ve only got ten hours of David this week, what’s a version of message categories that we’re gonna get done at the end of the week?” That’s a totally different thing. So that traces all the way back to the beginning.

Then the technique of scoping, which is instead of just splitting work out into tasks, we have this intermediate unit, which sort of corresponds to the anatomy of the animal, the big joints and muscle groups, and stuff… “How do we factor the project down into the main orthogonal parts?” That scoping practice started in 2009, because we had to build out – we had four products at the time: Basecamp, Backpack, Highrise and Campfire, and we wanted to tie them all together into a single sign-on, and have seamless movement when you’re authenticated from one into the others… And that was just a gnarly thing, to transition all those pre-existing user bases into a single sign-on, thing. So that was such a huge technical thing that we 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, 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. 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. It’s sort of the skunkworks thing. And then eventually you have to flip a switch and you have to say “You know what, 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 throughlines on it.” It’s not like this big research project anymore.

[20:12] And then you make this flip into production mode, and now you wanna give teams the responsibility to build out the features. So that’s kind of where the informal aspects of shaping and betting came together there… But we didn’t have a strict process around it yet.

Then it was in 2015 with BC3 when we were trying to – we were past the point of experimentation and we felt like “We want this thing to be done by the end of the year.” That’s actually when we formally adopted six-week cycles. Because we were really feeling the pain that our cadence wasn’t fast enough, and there was just too much to take on, so we’ve gotta 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.

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 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, 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. In the summers we do four-day workweeks, 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, on the tech stack we’re using, and the way that we’re structured, six weeks feels like the natural number right now.

I think we can probably 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. If you’re in a sprint, you feel like you’ve gotta 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, as fast as possible.”

Absolutely.

I can’t sprint for six weeks, you know…?

[laughs] No…

You totally can’t sprint for six weeks.

Just don’t ask me to sprint for six weeks.

And if you did, you wouldn’t like the result, because…

You can burn out real fast.

[23:40] And this is a huge problem… If you’re working two weeks at a time and your idea is push-push-push for the whole two weeks, not all work – you know, work is kind of like a wave. There’s a point where the work is gathering, and then it reaches a high point, and then it pushes and crashes, and then it recedes again. And inside the six weeks there’s an early phase where nobody’s pushing; everybody’s getting oriented. They’re trying to figure out “What is the existing system? What APIs do I need to connect with? Where are the boundary lines between different parts that are dependent or interdependent?”, stuff like that.

And then there’s a point where they start to figure out what the work is, and then they kind of gather steam and it’s like go-go-go for a nice (maybe) four-week chunk in the middle. But you can’t just race and then ship, because you also have to sort of take a moment and get some feedback on your pull request, and… You already have a better idea for how you could factor something that you did in the first week. You’re like “Oh, that shouldn’t be here. That should be there. I wanna separate that concern here and there…”

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, it’s because they don’t have that time built into this cycle to think about quality, or to make those clean-ups, or to make those adjustments to how things are factored and represented in the code, so that it’s better for your future self and for future others.

Yeah. How you described that kind of reminds me – 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 Hashrocket’s 3-2-1. I think they launched way back, and it turned a lot of heads, and people were like “How in the world can this team (or these teams) build a full-on VIP application in three days?” The premise was essentially “Hey, hire us. We’ll build your first prototype in three days, and then you can know where you’re trying to go from there.” And what you didn’t realize was that before the 3-2-1, the three days, so to speak, you actually had several weeks of very intentional meeting, planning, discovery etc, that was kind of preface to this, and was sort of necessary to build. You’ve got that sort of gap that you had to build in there, but it was sort of hidden in the–

What’s the 2 and the 1? It’s like two weeks and one…?

I could swear it was called 3-2-1; I could be wrong.

I remember the name, I just don’t remember the 2 and the 1.

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 in any code beforehand… So people have to show up for these 48 hours, and then the teams that are actually serious about winning, they put like weeks of preparations into what they’re gonna build; they just haven’t written any lines of code yet… And then it was time to kick it into high gear; talk about sprint…

Right. We’re far enough in though… We need to hear the summary of this methodology.

Yeah, take us through a cycle…

We’re teasing it too much.

…at a high-level. Don’t go into the details of how you shape, but tell us about the shaping and the betting, these multiple cycles… Go ahead and lay it out at a high level for us.

Sure, okay. So I think based on what we set up so far we could start 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 we fully intend and plan to deploy the thing. And not only that, if it doesn’t deploy at the end of the six weeks, something bad happened.

Like something bad happens to the employees? What do you mean? [laughs]

You know, we don’t have any roasting pits.

Lashings.

Oh, you said “something bad happenED”. Okay, I thought you said “Something bad happens.” I’m like, “Whoa…!”

There’s a sense of – you know, if it didn’t ship at the end of the six weeks, something went wrong. That’s not normal, that’s not business as usual. And then we’ve got two weeks of cool-down at the end of every six weeks. That originally started because we recognized that we needed some time to just look at bugs… Because there’s a certain amount of bugs. Most bugs don’t matter, and bugs aren’t special, as David likes to say. There’s just other work that you could maybe do or not do. They’re also, in a way, just the edges of what works.

[28:02] If the core of what works is valuable, then the bugs are just there sometimes; it depends on how competent the execution of the core flows is. We assume always, because we have competent people who have enough time to think, that the core things are properly done… But nonetheless, having that two weeks of cooldown between cycles gives programmers totally – they’re not guided with what to do at all. They’re totally free to just pick off that thing that they wish they had done differently, that bug that was brought to their attention that they would like to solve, the new library that they might wanna use but they haven’t had a chance to tinker with yet etc.

Then also those two weeks of cooldown give us an opportunity to put heads together and meet about what to do next. They give people a chance interdepartmentally - which is a goofy thing, because we’re a fairly small company… But still, when does the programmer get to talk to the data person, if they’re heads down for the six weeks trying to build something? So that’s cooldown.

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’re 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? This puts us into a risk mindset. If I give a team work that is totally underspecified, like “Go build a calendar”, a calendar could do 100 things. Which tenth of a calendar should they build first? They could build the best ever RSVP and invitation and schedule alignment system; kind of go down like a doodle direction, and make that the best ever thing… They could make the best ever high-fidelity native interaction for drag-and-dropping events on a monthly grid of cells. Where do they go?

So if you underspecify the problem, your risk is huge, because you’re giving way too much open space to the team. On the other hand, if you overspecify the problem and you say “You will do this task on Monday and this task on Wednesday”, then it’s all gonna 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 “How do we shape the work in such a way that everyone can see what the rough, basic solution is, without totally being specified? And how can we 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 wanna give a team a ticking time bomb, or a hole they’re gonna fall into… So there’s a certain amount of high-level design that we do, and a certain amount of technical stress-testing. “Architecturally, does this make sense? Do the APIs that we expect to use actually exist there?”, this kind of a thing. Performance-wise, if the designer has an idea that this project is gonna work like this, but then somebody who understands how all the jobs are gonna have to get queued could say “Oh, that might be an issue”, whatever.

[31:46] 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 cyle 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. So that’s the shaping.

Then the work that we do in the shaping phase - it doesn’t automatically directly go on to some kind of a conveyor belt or queue. There’s no backlog. Just because you shape something doesn’t mean that now it’s gonna go to a team, rather it means that you’ve done some value-add work on a raw idea, on an unshaped idea, so that it’s now a better potential bet. So you’ve improved your odds on the success of shipping this thing… But there’s still a separate question, which is “Is that thing strategically valuable for us to spend time on right now?” Or is the amount of time that you shaped it for.

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 how the team could solve it. Let’s do it.” And then we could have some push and pull, and somebody else, Jason or David might say “Eh… If we could do that in a week, I would gladly ship it… But I don’t wanna 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 like “What actually matters?” 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 risk. With betting, we wanna have the notion of “I know how much I’m betting, and I should have a capped downside and maybe an open-ended upside. At the most, I’m gonna bet six weeks on this thing and see what comes out of it…”, but I don’t wanna 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.

Right.

So with betting you put a certain number of chips on the table, and that caps your downside. So that’s the first thing. That’s totally different from “Let’s take two weeks, whack at this and see where it goes.”

Then the next thing is that betting is supposed to have a payoff. There’s no guarantee that you’re gonna get the payoff, but you’re only making the bet because you see a payoff ahead, right? So we wanna have that conversation - at the end of the six weeks, how are we gonna feel about this? Are we gonna be 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”?

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 gonna do this project, and we’re gonna give it to a team, and they’re gonna 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.

Wow…

That’s a circuit-breaker. And a circuit-breaker is a risk management technique. As soon as something gets above a certain level - pop! We’re not gonna allow more than that. 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 of whoever thinks it’s important to bring it back to the betting table. And if they’re gonna bring it back to the betting table for consideration for more resources, then it probably needs some new shaping work, right? Because whatever it is that we thought was gonna work out when we shaped it didn’t work out the way that we thought.

What if it’s super-close?

[36:18] Yeah, that doesn’t mean that we never extend projects; it just means that that’s the default.

Gotcha. You think “Oh, we need one more week. We just need one more week.” Do you ever do that?

The “We just need one more week thing” kind of takes us further into part three of the book; this takes us into the uphill and downhill work. So work has these two phases. 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 gotta geocode this data, but you’ve never worked with a geocoder API thing library before, or whatever; you have assumptions about how it’s gonna work, but you haven’t actually tried to piece it together… So there’s unknowns there.

So there’s an uphill phase where we kind of know what we want, but we don’t actually see – we can’t see “I will do this, and then that, and then this, 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 or libraries, you get to a point where you’re like “Okay, I tried wiring it 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 it’s like to stand at the top of the hill.

Then the downhill is where it’s like “Look, I know exactly what I have to do. It’s just a question of time.” I use an everyday example of planning a – you’re gonna have a dinner party. If you don’t know what you’re gonna cook at the dinner party, then you don’t know where you’re gonna go grocery-shop and what you’re gonna buy, and how many days beforehand you need to plan it. So there’s a certain phase of “Am I gonna grill out? Am I gonna cook Indian? Am I gonna do Italian?”

Then once you realize “Okay, it’s gonna be pasta, and it’s gonna be vegetarian, and it’s gonna 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 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’ve got that like “Oh, we just need one more week” or “We just need two more weeks”, the character of that work, whether it’s uphill work that has uncertainties in it, or it’s downhill work where we can see it all in the palm of our hand, makes a huge difference to how we wanna think about reinvesting.

Yeah, 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 gonna extend this for a couple of weeks. We’re gonna cut it off.”

Exactly. And we’ve seen both of those cases. That’s actually 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 is over, because we just leave the teams alone to solve it. But then the cycle is over, and there’s this UI problem; and it’s like “Man, we could go a year and never solve that. Or we could have a Eureka in the shower tomorrow”, but that’s not how we make bets. We wanna put that off onto the shaping track, where we’re gonna 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 gonna ship.”

So that kind of takes us through – there’s raw ideas, customer requests, stuff that the CEO dreamed up yesterday… All that stuff needs to get shaped before it’s a good potential bet. Because if it 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 gonna get boxed in with incorrect assumptions on the first week. We get into tools and techniques for how we hit that right level of abstraction in the book.

[40:11] 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 cooldown 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 solutions. Here’s the rabbitholes that we covered or identified. Here’s the things we’re not gonna do that makes it reasonable, and this is the appetite. This is gonna be a two-week thing that we’re gonna do as a small batch, as a set of smaller projects, or this is gonna be a full six-week project etc.” Those things are addressed in the pitch.

And then at the betting table, a handful of senior folks or executives are gonna look at that and say not only what’s valuable, not only what seems to be shaped up enough, but what is timely. We don’t wanna 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 skillset available is different. So that’s gonna influence what we bet on. And rather than grooming some giant backlog of stuff that we’re never ever gonna do, people are bringing a pitch to the table; you’ve got to personally bring it. So you’re only gonna have to three or four.

You’re gonna 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.

If we choose to make a bet on a project, that means - okay, we’re gonna give this to a team. Our teams are generally one designed and two programmers, or sometimes one designer and one programmer. We’re gonna give this to the team, and we’re gonna leave them alone for the six weeks, and they’re gonna figure it out and they’re gonna ship it at the end. And that is where we get into part three of the book, which is about handing off. Part one is shaping, part two is betting, and part three is building. And building starts with assigning people projects, not assigning them tasks.

We talk about the paper shredder. 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.” And on top of the fact that that was just imagined tasks, not even the real work that came up through the course of figuring out what you actually have to do.

So instead of assigning tasks, we’re just assigning the whole project, and then we’re giving the team the autonomy to do that inside.

It’s also the opposite of empowerment for your developers. It’s demeaning; it implies a certain level of code money, or grunt work, like “Here’s your task. Go do the coding thing.”

That’s exactly the terminology that you hear: code money, grunt work, ticket-taker… It’s just tickets on a queue that never ends.

Who wants to be that? Nobody wants to be that.

No. And programmers have expertise; there’s a lot of judgment calls that need to be made in the course of building something, and you want to sort of promote that fact that there’s gonna be judgment calls, there’s gonna be trade-offs to be made, and put them in a position where they’re making those judgments instead of just executing stuff that somebody else kind of planned out for them.

[43:44] And then we get into what are the techniques that the teams use to enable them to be successful. How do you go from this shaped overall concept to running code. This is where we get into some of the Getting Real principles, better articulated. The first thing is that the teams actually aim to get one piece done very early… And I think for people who really get what Agile is really about will feel that this section is familiar to them. So instead of doing a lot of horizontal platform work, where we’re gonna build out every piece of code we’re ever gonna need, and then we’re gonna layer out the features later…

It’s kind of like, you know, the people who are like “I’m gonna invent a new database before I write my app.” I think that happens in a kind of small way on ordinary projects all the time. “First I’m gonna get all this code back-end working, and then we’ll do stuff later.” Instead, what we wanna do is we wanna 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 gonna be a button here, it’s gonna show you this, and then it’s gonna take you over here; then you’re gonna fill in a field, and then it’s gonna do this calculation and it’s gonna spit out this other thing on that last screen.

So the affordances and interactions - the designer is gonna lead with a little bit of that, put that into place, and the programmer is gonna wire that up. And then that one little piece that you could carve out that has both front-end and back-end is gonna be done, and you’re gonna have a separate branch running, you’re gonna have a beta server running that shows this one little part is working, and you’re gonna be able to show the outside world “We finished something.”

That is totally core to how our teams work, and this 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 and then trust that your instruction manual and your design is all gonna come together.” Instead, actually integrate front-end and back-end together and deliver something that works, that’s some kind of orthogonal slice. We call that a scope. In the beginning, you can’t see what the scopes actually are, because you have to walk the territory before you can map it.

There’s this notion that the work we have to do has these boundaries on it from the shaping, but it’s also kind of like a wild jungle, and we have to sort of get in there to figure out what the major landmarks are, and where the ravines are, and where the river runs, and stuff like that… 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 gonna pick off one thing that they can say “You know what - this is the place to start.” And in the first maybe week, they’re gonna have something running, front-end and back-end working together, and then because they kind of dove in there and they started to get involved in the system, and get their hands dirty, they’re gonna start to see “Oh, okay, so we’re also gonna need this and that, and then we can work on that other part over here…”, they’re gonna start to see the lay of the land, and that’s where they start to define the work into scopes.

Scopes are a unit of work that’s lower than a project and higher than a task. It’s an orthogonal chunk of a work that we can integrate independently, and that we can finish – it needs to be small enough that we can see the end of it in maybe 3-4 days of work together… Because if it’s bigger than that, it starts to feel like a project. 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 modeling a new feature, you’ve gotta figure out what you’re gonna name the columns, what you’re gonna 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.

[47:58] 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.

Once they’ve mapped those, then actually they create to-do lists. I haven’t found a tool – this isn’t just promotion; I actually tried to find a tool other than Basecamp that enabled this way of working… So there’s an opportunity if somebody wants to try; and there’s also opportunities for us to keep going down this road, but… Basecamp has this hierarchy - you’re in the project, and then the project has to-do lists, and the to-do lists have items. It sounds stupid, it sounds very simple, but try it in JIRA.

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 a 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 gonna work on and what you can finish independently. And then as you discover work, which is a huge part of development, right…?

For sure.

“Oh, I’ve gotta do this. Oh, don’t forget about that. Oh, this doesn’t wire into that; I’m gonna have to research that.” Those tasks now have buckets that they live in. 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 wanna finish first, second, third? What do we wanna 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… Scope-creep isn’t like a bad client; it’s not bad shaping, it’s not just taking on too much. A lot of scope-creep is just the fact that you thought you’d be able to build what you described, but then once you discovered all the actual work you had to do you didn’t know you had to do, it’s way more work than what you characterized upfront. So it’s a natural function of opening the hood, that the scope grows.

So what we need is some kind of a machete in our hand, so that we are constantly cutting away at that and making judgment calls… And the machete that we use is this little key on the keyboard, it’s on the upper-left - depending on if you’re on a Sun layout or a modern layout… It’s the tilde. We put a tilde in front of a task if it doesn’t absolutely have to happen for this thing to ship. If I had to ship tomorrow and I didn’t do this thing, would I still ship tomorrow? 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 two or three little tilde tasks hanging off the bottom of the list. 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 discpline - coming back to your 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. It’s not just trimming off things that are easy to cut, it’s really being like “Man, do we really need that? What happens if we don’t do that?’

[52:20] It forces conversation too, right? If you have a team who’s trying to do work and is not collaborating, they’re sort of isolated, they’ll assume “Hey, we’ve gotta do these things, we’ve 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 tilde, 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 kind of feel almost guilty that you’re not finishing the things.

Absolutely, yup.

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 the 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 a tilde as a nice-to-have, so they’re constantly sort of managing the scope as they go…

Then the last piece is - the way we’ve built it in Basecamp is that scopes to-do lists in Basecamp, they map to dots on a hill chart. So the hill chart, if you just sort of look at it, looks like a normal distribution, a bell curve… But that’s not what it is; it’s just the same shape. And the left side is showing – if we’re on the far left, bottom left of the hill, it means “I might have ideas about how I’m gonna do this, but I haven’t actually cracked it open at all.” If you’re a quarter of the way up the hill, it’s like “I’ve identified some of the moving parts, I’ve stubbed something. I think I have an idea about the approach.” And the maybe nearly all the way up the hill is “I’ve stubbed it, I’ve validated that the things wire together; I thought that they would. I’m not seeing anything left that isn’t clicking together.” So now you’re on the top of the hill. Then maybe a little bit over the top of the hill is like “I have a lot of tasks left.” Toward the bottom of the hill, “I don’t have that much left”, and then all the way on the other end of the hill it’s totally done.

The good life.

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 try to drag a dot for the whole project, you couldn’t do that, because every piece of the project has a different probability and different level of uncertainty to it. Like, I know how to build Login, but I don’t know how to build this new algorithm that we’re gonna do for this analytics thing that we’re trying to do.

[56:18] So I can’t say that the project is equally certain and equally uncertain. But if I break it into scopes, now I can say “This scope is totally solved, but not done. This scope is not solved at all”, and then this gives us kind of a really instant single picture of the risk profile of the whole project. And it’s not just the snapshot, but it’s also the second order.

I can look at snapshots of hill charts, 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. And this is not algorithmic, it’s not automatic, it’s not like 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?

Yeah, for sure.

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 “Oh, okay.” You really get in there and now you’ve got 20 tasks, but they’re all very doable tasks, and you’re not worried about it at all. 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 is doing this piece of work, and it’s totally decoupled from the number of tasks. 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 uptick that hill chart. You forgot to drag the dot.”

[laughs] So what we’ve found is that actually the teams really enjoy – there’s a weird sense of triumph of like “Oh, I got that over the hill.”

Right.

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 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 gonna be like “Sweet! This is coming along”, you know?

Yeah. That’s a very insightful conclusion… Like “Hey, the best thing we can actually do is just indicate manually where we are, because we can’t accurately derive based on any particular data that we have in our system where we are on this particular scope.”

It’s epistemologically honest. It’s just reality. Like, look - nobody actually knows, but they can tell you about a single piece that they’re working on if they’ve gotten it straightened out or not. That’s a real honest thing that they can report. So we’re trying to map what we’re reporting and what we’re calling progress to what people actually know.

You said before that you kind of leave teams alone when they’re in a cycle, right?

Yeah.

Does that mean there’s no collaboration? How does the designer and the two developers for example doing the work, in discovery model, 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. The way that we do it - it’s not very formal, and I think that’s a feature, not a bug. There’s two aspects to it. One aspect is the team can get into a situation where they don’t feel like they’re making progress, and the problem is that very often teams actually don’t – it’s just human nature; it’s hard to raise a flag and say “I’m stuck.”

“I’m not doing so well over here…”

[01:00:09.15] Especially if you’re a developer and you’re supposed to have the whole logic of everything in your head all the time, and then you’re like “I don’t know what to do…” Who wants to say that…? So actually the hill charts are sort of a proxy for that. If something isn’t climbing over the chart, it’s a signal to the outside that something’s wrong internally, that something isn’t clear, or somebody’s stuck somewhere.

The other proxy is something on beta that I click through, that wasn’t there five days ago. The real truth is always the code; it’s the shipped code that actually does stuff. So if a team is working on something and someone who’s responsible for sort of – we don’t actually have exactly people who are managing the whole team, but we have people who are most senior, who those people report to. If somebody is wondering “I wonder how that project is going”, and they go and they look at the beta and they can see that new stuff is deployed, then it’s like “Oh, they’re building stuff. It must be fine.”

Or if nothing is deployed, but the look at the hill chart and they can see that something meaningful got solved recently, 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?” And then there might be an ad-hoc meeting, there might be a little troubleshooting session to untangle something… It can happen like that. But it’s totally ad-hoc, and it’s totally from the point of view of providing support. The teams shouldn’t need anything, and their performance proves that. Our teams are amazing, and they don’t need help very often.

Sometimes it’s in the nature of the work. Sometimes it’s just a super-gnarly thing that we’re trying to do, or maybe we left something out in the shaping that we didn’t consider, or couldn’t have foreseen… So things come up. But it kind of goes back to “Work doesn’t come segmented on a grid.” It’s a weird animal, and you have to figure out what kind of animal it is. 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 teams this is for, because you have methodologies… We talked about Agile earlier on, about where it applies. And you even have this idea of – geez, I can’t remember what it’s called, but it’s the VIP methodology; basically, is it fit for a brand new startup trying to discover their product? Or is this more for mature teams, or more mature teams? 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 your team of three people - let’s say a founder who’s also a designer, and two programmers, and you’re working together… It’s not gonna make sense for you to hold a betting table and plan six weeks ahead, and then delegate work to yourself. You don’t need to write a pitch necessarily, because who are you writing for…? You’re all just together at lunch every day, you know what I mean? It’s a whole different world.

Right. There’s some sort of like in-kind pitch, so to speak. It doesn’t have to be a formal, written document.

It doesn’t have to be formal. But the thing is that as we look at this transition in scale from three people, to a dozen people, to thirty and on, you have a transition from hats 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 gonna get lost and wander around. So we’ve been shaping work since the beginning, in the sense of being very deliberate and clear, and not just jumping into something that has a bunch of unknowns in it.

[01:04:16.29] But in the beginning, that shaping is gonna 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 to “This is the next thing we’re gonna build.” Versus when you reach a certain scale, it’s not practical and it’s not effective for everybody to be thinking about what to build next. You’re gonna introduce a more varied and specialized skillset as well.

For example, we have designers here, and all of our designers are gonna out-design me more than 10x when it comes to implementing and making all the choices and trade-offs in like “What is the actual design supposed to be?” But I think everyone would agree that I can bring something to the table that’s unique in terms of integrating the strategy and the technical side, and defining something at a higher level of abstraction that’s doable, that has business value… This shaping thing is actually a different skillset than the standard design skillset.

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 can do this better that you can, so I’m gonna figure out where I sit in the organization so that I’m adding value to this sort of–” you know, there’s a 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 to something that is getting built out, and mapped, and scoped to something that ships. These are different skills.

So the six-week thing, the formal betting table, two tracks where we’ve got shaping happening in parallel to building, and we’re dropping in shaped work for the next cycle - that’s all designed around our current size, which is like two core development teams that are running in parallel, plus senior people who are able to think about what to do and don’t also have to build it themselves all the time.

Yeah. The way I described it to Jerod when we were talking about the details of this was like “Is it like a recipe? Am I making a dish for six people, four people or two people?” Because the same ingredients go in, the same product (for a lack of a better term) comes out, the process is all the same, except maybe there’s two instead of four, or whatever it might be.

Right.

You just simply shrink down your recipe, so instead of six weeks, in two weeks… Does some other time factor make sense in different size teams?

Yes, I think it probably does, to be honest… Because when you’re really small and your product doesn’t do anything, the difference between nothing and something can be really big with a little bit of development work. I mean, I do a lot of side-projects; we all know how this is - you’ve got those four hours on a Saturday, and you went from 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 week and pursues it, and then moves on and the picks off the next thing to do. I don’t think there’s anything wrong with that, but it’s important to create the contrast that we’re not sprinting, we don’t have a backlog, we’re not doing grooming, and we’re not just incrementally biting away at something that’s bigger.

There’s a huge difference between as a tiny team defining for yourself a two-week appetite, and saying “We’re gonna come up with a solution that’s a two-week sized solution” and then using your ingenuity–

Because you’ve gotta move faster. Time is of the essence at that stage, too.

Yes.

[01:07:54.05] Working product, feedback loop etc. The methodology I was thinking about, that crossed 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 deliver, a gather information and rehash how it could change for the future, and 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’ve never adopted it whole hog myself; so this is just me looking from the outside in in other teams… There seems to be a lot of struggle with MVP, where people define the minimum viable product as something that kind of works and sort of validates the concept, but isn’t actually a quality thing that you would wanna 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 wanna live with and look back on, our future selves, six months from now or three years from now or ten years from now. The code has gotta be good, always. So we always talk about half versus half-ass, and I don’t think people really appreciate always, doing the lean thing, how good minimum is, you know what I mean?

Yeah.

…and what quality means in that context. 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. 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; you’ve got an established team, an established product… But lean is more for beginning – and I think, as you said, MVPs have a good place, but it’s not at all what you’re trying to prescribe here. It’s a completely different animal.

Honestly, I have to say I don’t really like that framing… Because I think the essence of lean is like “Ship to learn.”

Right.

I can’t find anything in a lean book that says more than that. So honestly, if it doesn’t say more than that, in my mind - and I’m being a little hard on it here, but it kind of goes into the BS camp. If I can compress it down that much, then what’s in there?

That’s true.

And I think a lot of the challenges are like - okay, we wanna ship something to learn; how do we do that? How do we actually define something so that we actually know what the end looks like, so that we actually get to the point where we ship it? 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.

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 gonna get stuck along the way and it’s gonna 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. It’s such a simple idea that you need to put together a lot of other skills, I think, to be successful. And those skills are just as true when you’re in the very beginning and you’re trying to figure out if something is viable, and when you’re successful and you have an established customer base but you don’t wanna waste your time, and you don’t want to be complacent just with the one feature set that works, and you don’t wanna screw up your product.

Right.

[01:12:00.11] We’re short on time, Ryan, and I wanna ask you a couple real quick questions about shaping and about betting before we let you go here. Can you share a couple of shaped pitches that were actually executed on by Basecamp in the last six months to a year, so we can get an idea of what – because I have a hard time with what is six weeks of work, what is a shaped idea, what do 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. I’ll point to two examples that are in the book, so that way people who are interested can dig deeper into them. At the end of the chapter on pitching there’s two example pitches. One of them is a feature that we called To-do Groups. We wanted the ability to 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. It’s like a whole other level of organization for the people who can take advantage of it… But at the same time, we really didn’t wanna 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 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?” It involved changing the JavaScript that we use to reposition items, not only within a list, but across lists… Hairy stuff. That was done in six weeks.

Are those the kind of things that were then discovered by the builders, or known by the…

Yeah, we can say shapers.

The shapers, upfront, yeah.

Yeah, generally a shaping team looks like a very experienced designer, or the most of what you have - because if you’re a startup, you do what you can… And then you need help from a technical person to push back on the thing that you wanna do. It starts from the customer end, with the design, but then you need that tech pushback on feasibility. We never capture everything that’s gonna come up that’s gonna surprise us, but if you’ve seen enough projects and you’ve done enough software development, you can look through a concept and say “Okay, this is reasonable, this is reasonable; this thing is gonna be a mess… What about that? Oh, okay.”

So there’s certain things in the shaping process that we actually make calls on, because we know that if we don’t 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.” We’re not gonna regroup the completed items, we’re just gonna append a label to the end of them that says what group they were a part of before. 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. So you’re being very patchy with where you go down into detail about the design and where you don’t.

Interesting. Another random question - 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 downtimes 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 is a single project, for a single team, for six weeks, end to end. A small batch cycle is actually like a little grab-bag.

Okay.

[01:16:10.14] So we’re gonna give a team six weeks and we’re gonna shape up a handful of things that are maybe like 1-2 weeks each, but they’re not on a schedule to deliver, like week one and then you ship, and then week two and then you ship. There’s no schedule for them. It’s just like “Here’s a bag. We’d like it if all this stuff could get done.” And then they figure that out. They know the appetites for each individual things, so they’re not gonna spend the whole six weeks unnecessarily on one of them.

That’s a real luxury, having two teams… Because we can make progress on one big thing, and we can kind of nip and tuck a bunch of small things at the same time.

Gotcha.

Before we had enough people to do that, we actually alternated… Because it’s also good for morale, you know what I mean?

Yeah, absolutely.

You make a big push, you make a big ship and you have to announce it, and you have support questions come in, and all this stuff… And you’re like “Man, let’s just fix some stuff for the next few weeks.”

Quick wins.

Quick wins, exactly.

Yeah.

This comes back to the question about scale. I think a lot of this is that if you’re bigger, you can parallelize some of these things, and then if you’re smaller, you just take whatever was parallel and you turn it into an alternation - a little bit of this, and then a little bit of that.

Very cool. Last question from me is how much fun is the betting table? For me, that seems like it’d be a great meeting; everybody gets their pitches out, you’ve gotta argue what’s in, what’s out… I mean, you’ve gotta pick the work for the next six weeks, so probably a pretty big deal. There’s probably some impassioned pitches going on there.

You know, it’s funny… It may be our setup and our culture, but the thing is that if you have very senior people at a betting table, which is by definition what it should be, 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.

It was so much cooler in my head…

But this is the reality for most business - nobody at the top has time, and they rely honestly mostly on trust. There’s a whole book about this from the ‘70s called Managing the Resource Allocation Process by Joe Bower. 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 it as kind of who it came from…

Our organization is so much smaller, that it really is about the work. But there’s only a few things on the table, and there’s been enough back and forth… I might be going back and forth with Jason about an idea, and we can already tell “Is this coming together? We should probably do this.” 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, so…

That’s true.

…there’s a lot of deep trust, and a lot of 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 - the fact that we have such a long history together probably makes those meeting shorter. I can imagine them being quite long and interesting in another circumstance.

[01:19:51.25] For me, the real juicy time is if I get in a room with Jason, or I’m on a call with another one of the designers and we’re hashing out a totally new idea, and we’re shaping it. Or if I take that to David and he’s pushing back on it technically, or challenging aspects of it - that push and pull; I actually think that that’s where the real negotiation happens that’s meaningful. If you’re fighting the hard fights when you’re defining the work, then the process of scheduling stuff and choosing what to do I think actually gets easier.

Yeah. Especially if you have a good handle on where the company is trying to go, and if you’re fairly mature in your revenue models, and you cash-flow, and - trajectory is a word you haven’t said on this call here, but that’s one that I actually attribute to me liking more because of your past sharing; you know, rather than road map, it’s trajectory. Where we’re trying to go kind of thing.

Yeah, yeah.

I think when you have that, it’s a lot easier to sit there and say “Strategically, the next step should be these things, because of these indicators.”

It can be, but the thing is that – I think a lot of people who live in the startup world imagine one day the growth curve is gonna grow up, and then they’re gonna 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.

It comes down.

It starts to falter…

And sometimes it goes up again.

Yeah. Or you have paying customers, you think you’re fine, you build something and it’s totally the wrong thing. And now the perception of you has changed, customers have a different perception, they might not like it, they might evaluate a different tool… There’s no guarantee that once you get up over the first growth curve that you’re set.

We definitely have periods where what to do feels more momentous. It 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.

So if you’ve been listening to this show, thinking “Gosh, I’ve gotta get this book”, well it’s available to you for free at Basecomp.com/shapeup. And /books actually has all of your books. Is this the first – I think Getting Real was online for free, right? Did you have 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 Shape Up we’re not even collecting emails.

But you are if you want a PDF eBook or print version, which you’re gonna do in the future, potentially.

Yeah. So if anybody wants a different format, they can sign up just to find out about it, but that’s not a gate to reading it; that’s just a way for us to reach you if you wanna hear about it.

I like that. So 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 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 don’t know who did this, but I love the “Continue where you left off” button.

[01:22:56.11] 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, boom.

Yeah. And I’ll just put the word out that if – I don’t know when the podcast is gonna air, but if it’s before August 28th and 29th, I am doing a rare workshop on Shape Up, 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 Moesta, one of my mentors. The first day is gonna be on jobs to be done, all about figuring out what to build, and what strategically is the right direction to go in, and then the second day is all about Shape Up. He’s leading the first day, I’m doing the second. That’s gonna be in Detroit, August 28th and 29th. I can give you guys a link for that, or people can look through my Twitter to find that. That’ll be an opportunity.

Awesome.

When you have – if you know it, you can say it now; if you don’t know it yet, then we can definitely put it in the show notes, we love to do that. Listeners of this show know we strive very hard to have show notes, and then 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 a link is broken… Which never happens, but just in case.

It never happens… Ryan, any closing thoughts on teams out there struggling to find process? Is it just as easy as going to Basecamp.com/shapeup, or what?

I would say go to Basecamp.com/shapeup and then use it to create language within your team, and you’ll find that it’s easier to articulate the problems you’ve been experiencing that you didn’t really know how to talk about. And then once you start to have that conversation, you might find different pieces of the method in the book that you can pull in right away. And other things - you’ll at least be able to start having the conversation, and that’s gonna set you down the right road.

And people should also feel free to email – you can email shapeup@basecamp.com. That’s gonna go to me, and I’m taking questions there. I’ve also been talking to teams, all the way from tiny startups to major, hundreds of people on the digital teams and thousands of people on the company, with questions about how this applies at different scales. I’m very happy to answer those questions, and also kind of curious about those worlds, so… I’m happy to talk about those things.

I’m glad you said that, because in the pre-call Jerod asked you about bugs and what to do with those; that didn’t end up in the show, but you’d mentioned that that chapter wasn’t there a week ago, something like that. Is that roughly the case?

That’s right. 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.

Ryan, thank you for sharing your time with us today. 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. I appreciate laying that wisdom down. In a lot of cases, we have people who wanna 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. 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. You guys are really thoughtful, and you’re also very good at what you do, so this is a treat to be on the show.

Awesome. Thank you, Ryan.