Shape Up Live 1: Adam Wathan, Founder of Tailwind CSS

and it'll be on the YouTube channel. So unless we say some, unless we go into some kind of classified area, then we decide we have to redact, you know? Sure, sounds good. Yeah, okay. So, you know, hi to everybody who's listening in here. This is kind of a new experiment where actually Adam reached out and said, hey, I've got some questions about applying Shape Up in this kind of new context that he's in. And I said, okay, well, how about we try doing it in a live format so that other people who might have similar questions or who knows where we're going to go, we might also just kind of make some stuff up and learn some stuff along the way here so that other people can benefit from it. And this is something that we'll try to do again and again, actually. on this platform of talking to folks who are trying to apply it and then learning from each other about where it works and where it doesn't work and sort of how to adapt it to different situations or when to not adapt it at all and do something totally different, right? Let's see kind of where this goes. So how did we... How did we get here, Adam? Do you want to like, yeah, sure. Some context. So like, of course, I've been like a big fan of like 37 signals and base camp for many, many years and followed a lot of the work that you guys have put out in terms of how you work for a long time, attended like the how we work workshop at the office in Chicago. Oh, that's right. You guys shut that down, which was really, that's really going back. Yeah, which was really cool. And that was really exciting for me because I learned a lot about how you actually use Basecamp in ways that I didn't expect. Like I talked to Jason about this on my podcast a couple of weeks ago, but it was a really inspiring experience to see like just how much you actually do in the tool instead of, you know, rather than just managing projects, it's really about managing the whole company, which was really interesting. And what kind of work were you doing at that time? Like when you came to that event, like were you doing web development work or like what? i was um so actually i wasn't really in the best place to really uh sort of make much of what i was learning there it was more like At the time I was working on info products, like I just left my full time development job. And I had because I'd released a fairly successful book on sort of functional programming for PHP developers. So there's more of that stuff. So just very independent work, which means that's super interesting. I never saw that actually functional programming for PHP. Yeah, it's pretty fun. So I really just came because I've such a huge admirer of the company and the way that you work. And I thought, I'm gonna learn something here that's gonna be useful to me one day, no matter what. And it would be just a really cool experience because it doesn't seem like it happens very often. And like you, Jason and David were all there and I know David's not there very often. It was like, oh, this would be a cool one to go to. You know, really like just get to be a part of this thing. So that was really cool. And then when Shape Up came out, of course, I was really excited to read that. and Reddit and it all made perfect sense. And a lot of it was sort of building off of ideas that you had shared in the past, like years and years of learnings through like your felt presence blog and through the signal versus noise blog and all over the place. So it was cool to see all that distilled into one place. And it all made perfect sense to me. And I was like, yep, this seems so straightforward and exactly how you should do everything. And then of course, like we start hiring people to work at our company that we're working on now, which is building open source tooling and sort of design resources for developers. And as soon as I start to schedule like our very first project as a team when it's no longer just me and my co founder who sort of just fly by the seat of our pants and make things up as we go. Yeah. All of a sudden, it's like, wait a minute, like, I immediately have all these specific questions that I never would have had if I didn't actually try and put this into practice. You know what I mean? I sent you an email. seeing if maybe you had some time to chat with me about it and give me some of your input on some of the stickier parts. And we thought it would be a cool idea to do it as just like a live stream so that more people could benefit from it, which is funny because there's this like, there's like a link here over years where, I don't know if I've told you this before, but like when I started the Fullstack Radio podcast years and years ago. Literally the reason that I wanted to start that podcast was because I'd been reading a lot of your work and I had a bunch of questions for you. And I thought if I just email Ryan, he probably won't just jump on a Skype call with me and just talk with me for an hour. But if I had a podcast, maybe he would come on the podcast because at least there's like some output. Yeah. So this feels like it's like that all over again. You know what I mean? Which is kind of fun. So yeah. So what's, what's what's what is Tailwind? And what do you what do you try to do there? And kind of where you at today with it? Yeah, so Tailwind itself is an open source CSS framework that we put out like at the end of 2017, that has picked up a bunch of steam and people are really into it. And what like when when does somebody reach for a CSS framework? And and like, why do they reach for Tailwind? Like what, what's that doing for people? Yeah, so kind of the value proposition for Tailwind is that it's a, it tries to fill the gap between like doing everything completely from scratch, like opening an empty .css file and kind of starting from nothing with no conventions and no, you know, architectural approach. But it tries to not go as far as something like Bootstrap, where it's like, we have a lot of opinions about how buttons should look, how form inputs should look. My experience has always been that when I try to build like a side project or something, I want to start like somewhere above like nothing because I want to move a little bit faster. But when I start with a lot of the stuff that existed, it was really hard to sort of put my own sort of visual look on things because you're doing all this overriding and there's not a lot of clear information about like what is the idiomatic way to like make a button new color? Should I be editing the SAS file? Should I be writing custom CSS? Should I be interesting? It's like there's this gap between like either you are you have nothing or you kind of like have too much structure that you're sort of stuck with. And then already, like if you use something like Bootstrap, you kind of immediately out the gate and look like all these other projects. Yeah. And you have to resist that basically, which is a bit of a challenge. So Tailwind tries to sit in the middle where we give you a bunch of useful constraints, but we don't give you anything big enough that. it's gonna be like recognizable. So it's worked out pretty well so far in that regard. We kind of pitch it as like a CSS framework for rapidly building custom user interfaces. Oh man. Yeah. I can totally see my, this is so funny. This is starting to sound like an ad. Because I'm actually thinking, I have like a side project right now and I'm thinking like, I actually need this. I could totally use this. this is the right level of abstraction for what i'm looking for you know yeah try it out and let me know what you think well things have evolved to the point where uh when i open up a like a blank css file it feels stone age and i just feel like i'm doing it wrong you know and then and then i've had that struggle of looking at the different frameworks and feeling like they're all kind of overly modularized and like overly i don't know what to say but they kind of go too far right so uh that's that's cool okay so you get this open source thing out there and then how does that turn into a like what what it sounds like it's turning into a business now like what's that yeah so it um picked up a lot of steam just as an open source project uh saw a lot of adoption which was really cool and it continues to grow rapidly today which is really exciting um but because we sort of deliberately picked this sort of stopping point for the framework which is like don't impose meaningful sort of visual design decisions on people's projects there's a lot of people who see Tailwind are excited about it like the workflow but feel like I still can't make something that looks good with this because like I don't know like what padding to put on a button or what I should do on the hover state like I need more opinions you know what I mean so are these is this like um are these primarily more developer types who don't consider themselves designers yeah that's generally like our who we who's using our tools the most for sure that's fascinating that's so fascinating because it's like if you look at it from a kind of uh like a value chain standpoint there's this like a bootstrap is kind of covering this whole spectrum where it's one it's one piece that's taking you from nothing to having a visual opinion of how you should look and then you've kind of unbundled that into like this framework level but then you leave this gap open that's like unaddressed yeah and if you're a designer you can come in and and integrate there yourself and fill that gap but if you're a developer like that's still uh open yeah so there's some kind of non-consumption there that's interesting so that's where we decided to like figure out okay well maybe this is where we can do something commercial essentially right so we built this um we have this product which is tailwind ui and uh if you if you wanted to look at it you could go to tell and do i.com and sort of get a sense for what it is but it's basically a big um directory of uh much more like opinionated component patterns like built with tailwind and tailwind as a css framework is sort of like the simplest way of explaining it is everything happens in your markup instead of in your css it's very low level little utility classes uh okay convenient for us because it means our deliverable is just pure html So we just give you the- So it's very like declarative and compositional. Yeah, exactly. So like, I don't know if there's like a, is there like a chat thing here? Here's like a link to like a specific one where if you were to look here, like this is like a collection of call to action blocks that you could stack on a marketing page. And the idea is- I'm going to actually post this. There seems to be a public thing, a public chat, which I think is maybe the YouTube thing. I'm going to drop it in there. Cool. So this is just like, you know, it serves as both inspiration and like implementation, but it is designed to be customized. So you can just go here and grab like the actual HTML snippet. And I don't know like what the experience is on this page if you're not logged in, if there's like a free one. Yeah. So at the very top, you can see there's like a preview tab and a code tab. You just grab that snippet and now you own the code, right? It's not like something that came from a library. So you can change the copy. You can. change the colors you can tweak the font size but you have like a starting point this is really yeah cool yeah so this is like what we build and we sell this as like a basically a lifetime membership to this like sort of private directory essentially that we're still continuing to build out over time and stuff and there's two sort of top level categories there's like a big chunk of marketing site components and then application ui components And we sell those separately or bundled together. And we put that out in like February, at the end of February, after the CSS framework had been out for about two and a half years. And it's done like close to $2 million US in revenue since then. So there was like a big need for this. And it's been great because like, we're able to make like a commercial thing that competes with like open source things in a way. And it's good for us because we still have the open source CSS framework. kind of powering it all serving as like the funnel to sort of bring people to this i love that like there's a there's a case study to be written here about like where you draw that line between what's what is that public framework and then like where you're doing the custom uh implementation on top it's like fascinating yeah yeah thanks so so that's like what we do from a commercial perspective but a lot of our work is also just continuing to do open source stuff because that's what fuels our ability to do commercial stuff. Interesting. Developing a framework, developing new tools and plugins for the framework. So one recent project, for example, is Brad, who's our first hire, just launched a VS Code Tailwind CSS IntelliSense plugin that just gives you all these diagnostics and stuff when you're in your editor telling you, hey, you've applied two CSS classes that target the same CSS properties. So this is probably a mistake. You want to fix that. and that's like not something we charge for or anything but it's just one of those things that makes people's experience with our tools better which just feeds into everything right so we have a lot of stuff like that still and we have a lot of other big open source projects kind of being shaped right now that um will eventually lead to our ability to charge for other new stuff uh in the future so there's sort of these like two um sort of yin and yang branches of the business. Well, this parallels with kind of what I saw Jason and David doing with Basecamp, which was like they were like creating an audience through a lot of stuff that they were giving away. You know, I think especially early on, like that's the way to think about signal versus noise. It was a way of creating an audience. And then if you can create an audience and you can sell into that audience. But then you kind of have to keep investing in both. Yeah, 100%. I think that's a mistake people often make. They build this big audience from building free stuff, and then they get a taste of what it is like to be able to sort of capitalize on that and turn that into some of the commercial. They try to just flip it all into the commercial. And they forget about what got them there in the first place. You know what I mean? Yeah. So that's something we're trying to be pretty careful of, at least. So yeah, that's kind of like the overview of the big picture of what we're doing. Yeah. And then, so it was you and a co-founder and what's the role split between the two of you? Yeah. So Steve is my co-founder and he is like a, just a visual designer by trade with like some HTML and CSS chops, but not like writing HTML that people are going to buy sort of HTML and CSS chops, something he's working on. But like, yeah, our roles have basically been development and design. And then, you know, marketing and stuff is sort of a shared effort and product strategy and stuff. So that is kind of the setup that we have. So all the stuff, if somebody looks at a component in this library and says like that, thinks like that looks great, that's like coming from his design direction. And then you're helping to sort of implement that in the like the most nerd correct way. Yeah, exactly. And then also building like all the tooling and stuff that even makes it possible for us to do all this stuff. So all the open source. framework and steve helps a lot with like okay let's figure out what the default color palette should be and really battle test these colors against a bunch of different ui ideas and make sure that our two these two purple shades aren't are close enough to be useful but not far enough to be you know like lots of kind of design r d and design systemsy work that kind of goes into that too yeah but yeah that's kind of been the split okay and then uh um you said that like you know when it was the two of you everything could just sort of be chaotic but now you started to bring in more is it is it just the uh the the third that you brought on board now or is there more or what's happening yeah there's three of us like currently working but we also have two more people who have been hired who haven't started yet so and okay and who so so who is the third again and what's his role so the third is brad and brad is a front end developer but also just kind of a can do anything developer just like a really talented guy who loves to get deep into bleeding edge stuff and figure out what's possible and we hired him because he had already been maintaining this tailwind intellisense plugin sort of like the first version of it but it's in its spare time and um we see that as like a really important project in terms of people having a good experience and we wanted to put resources into making sure that that was like able to be maintained properly and um We also could use Brad's help in a lot of other different areas. So we hired him with a role of like developer experience engineer is what we called it, which is like, Oh, interesting enough to improve the developer experience of people using our tools. But at the same time, the reality is when you're only three people, a lot of time, we just have to pick what is like, the most important thing to do. And we all just kind of have to contribute to however we can, right? Yeah, because you can't really like departmentalize. No, not yet. Yeah. Yeah, so that's kind of, so he only just started with us like just maybe three weeks ago, I think. And his first project was this big new feature for the IntelliSense plugin and also kind of making a splash as making kind of branding as an official thing. Whereas before it was just this third party open source tool. And since then he's been helping me out with. some of this Tellman UI stuff for like the last week. So working on some new components, design ideas, and some of the things we need to build to make those possible. Because a sort of recurring theme of our work is Steve designed something. We realized that like to implement this in a way that we feel good delivering to customers in a way that's going to be easy for them to work with, we actually need to introduce some new tool or some new feature to the open source framework or something. Oh, interesting. Like API that's exposed to them to work with, you know. So Steve is kind of driving changes in the underlying framework in order to like better, like express the thing that he's trying to do. In some ways, like unknowingly to him, I guess, you know, so like, yeah, like one concrete example would be one of the kind of categories of components that we haven't built yet is what we're calling like content sections for marketing pages. So imagine like a landing page that has like sort of a section with a big story in it where there's gonna be some paragraphs and headings and lists and stuff. Because of how Tailwind works where it's very much like add a class to set the font size, another class to set the color, another class to set the margins, trying to style like a big block of content is super. inefficient and impractical. Because you don't want to go to every P tag and add the same classes every single time. That's interesting. You get to a point where you kind of need a whole bundle together. Yeah. You need like, how can we call this like a content block and just throw one class at the top of it that just makes sure that like H2s look good, paragraphs look good, lists look good. Interesting. So we can't like ship that component to people right now because if people copy it and see there's like all these paragraphs, those duplicated stuff, if they wanna change the content, add a new list, change the headings, it's like, oh, I better find, was there another H3 that I can copy these classes from? It's not a good experience. So what me and Brad have been working on the last week is like, what can we invent that makes, that lets us expose a much simpler API to people where we can just have like a, right now the. the working class name is pros because we thought that sounded really classy so we could just sort of like a pros class on like a div and everything inside it's going to look nice and we have to figure out okay well what's the configuration api for this because some people are going to want to change the font size of things or change the color make the link color match their brand color so what do we need to expose what what do we want to own and kind of hide because a lot of people don't want to most people using stuff like this are the sorts of people who are like i've heard of the word vertical rhythm before but i have no idea how to make like that look good can you please just own that for me it's just so fascinating this is uh what you could technically call a scale transformation it's where like you're doing a whole bunch of little things with certain primitives and now you you want to forget about the primitives and you want to sort of speak a higher language yeah that kind of wraps all those primitives and then you you have all these trade-offs that appear because okay like how do i i'm giving up control in a way but then I'm offering all of this leverage at a higher level. Yeah, and they're in conflict all the time, which is really hard. Yeah. Okay, so, and then you've got, you said you have two more kind of like coming on board. Yeah, yeah, yeah. And then in what roles? So development as well. And then we're going to be looking for someone to come on to help with design in the near term too. So it went from like two super overwhelmed drowning people for two years to, okay, let's try and speed things up a little bit, maybe in like a more aggressive way than intended. Like what actually happened is we hired Brad and then we, and before we hired Brad, we were actually working with bringing on a third partner, but we just couldn't come to terms that everyone felt comfortable with. And we expected that to work out at the time that we hired Brad and then it didn't. So then we were like, we need to hire someone that we can kind of put in that role because we were planning to be four people. But in interviewing for that role, we found two people that we really liked kind of figured out, okay, well, here's like the map of all the work we need to do. How can we like draw the borders here and to make it so that these two people fit? So that's kind of what happened there. So yeah, it'll be three developer employees plus me, the developer founder and Steve, the design founder and then i think steve is going to become a bottleneck really fast and yeah and i think also would just really value having some another designer's input on things because right now like it's just me and him working on stuff so i can get feedback on the design stuff um because i i value design a lot and care about it a lot but it's not the same as having another person whose design skills like you respect and want to be inspired by giving you feedback right so totally okay so so um As you're going through all these changes now, and ShapeUp comes into your mind as maybe not just the new thing from those Basecamp guys to read, but something that might actually be applicable. Is it more about there's something that's going wrong today in how we're working that we need to fix? Or is it more about I'm looking ahead and I'm trying to imagine how we're going to function? when we have all these people involved and I'm kind of trying to prepare for that. I think it's a bit of both. I think there's definitely up until now, we've we've had our hands in so many different things at the same time all the time. And I can point to so many projects that we've kind of like got 60 percent of the way there on. But then something else more important came up and that kind of just set stayed unfinished and we never got back to it. And it's been OK as a team of two, you know, like we've been able to like. reprioritize and figure things out but there's just like a lot of unfinished work sitting around okay stupid question like what's what's bad what's bad about that i don't think anything's like an inherently bad about it but it leads to it leads to a feeling for us sometimes of like looking back over the last six weeks and feeling like what did we actually put out into the world in this time like nothing it felt like we just like got halfway there on a bunch of stuff but new more important stuff kept coming up and taking its place at like the top of the uh list which i see in some ways like i think you have to be able to adapt to that you have to be able to take care of more important things and more important things come up but my opinion right now at least is that that has to come with a balance of also it kind of ties into like what you guys talk about with like betting on things like let's just like give this project two weeks if something more important comes up like let's just be okay with the fact that if we don't start on it for another week That's really not going to change things that much and we will have gotten this thing done at least then you know anything Yeah, it's kind of like it's almost like this this unfinished work actually effectively becomes scrap because If it never is going to make it out then then then it kind of becomes scrap and then you have this sort of like I don't know what the right term for it is it but it's the sort of ratio of like What's our what's actually getting out the door versus what's sort of piling up? So yeah, yeah and for later. I wouldn't say it's always scrap, but it doesn't feel like that a lot of time because it feels like if you come back to something like two months after you last touched it, it's really hard to just like pick up where you left off. It feels like you got to get back that context and a lot of the time getting back that context almost means like doing the work from scratch again to sort of like really appreciate how you got to where you were. Oh, interesting. Yeah, that's interesting. Even like Tailwind UI, the first version of that, we designed like, we probably built the whole thing like 60% of the way there three times and threw it all out. Not because we didn't finish it, but because like, we just learned things and needed to start again, you know? Yeah. And it feels like that is even more likely to happen with something that kind of rots in the background for a while. So there's that piece, like the just feeling like we want some more structure, we want to have some things on the calendar where even if we're not working in the most efficient way possible, we can guarantee that every three weeks, something went out that is a milestone of some kind. So we can look back on the year and feel like, yep, these are all the things we got done. Because I've definitely had years where there was a six-month period where I didn't actually put anything out. And that's a crappy feeling. Yeah, totally. And the other side of it is the... just wanting to feel like the people that we're bringing onto the team are coming into a system and not coming into uh you know ad hoc figuring things out as we go yeah totally totally so like the in the short term it's like i don't want to have that bad feeling again that like we we didn't produce anything or we didn't ship anything yeah and then in the longer term it's like i need to set some kind of uh i need to actually be able to tell people like this is how we work when i bring them in yeah because i think and I don't know this for sure, but I'm trying to put myself in the shoes of someone joining a new team. I think it's nice to feel like you know exactly what to do and like what's expected and not just feel like, you know, I think it's tempting for me as like a founder with a team to feel like people want like a lot of autonomy. They want to feel like, you know, they're kind of like working on whatever's interesting. And I think some element of that makes sense. But I also think like. if you're not careful, that can probably create a lot of anxiety in people around doing something that the people paying me want me to be doing, you know? So trying to balance like giving people well-defined, clear work and also giving them the freedom to sort of execute it on it in a way that makes it rewarding and fulfilling for them, I think is something that is really kind of at the heart and soul of the Shape Up stuff as well. So, yeah. That's totally core because actually I think we're seeing so many startups and actually also non-startups, but especially like younger companies kind of over-indexing on some sort of a kind of like a fuzzy sort of naive democratic thing. I don't know how to frame it exactly, but it's sort of this notion of like it's a well-intentioned. idea of like, I don't want to limit anybody. And I also want kind of the maximum input from everybody. But actually, what you get is, is sort of, you get this sort of inability to act, because people don't really know where the borders are, and what the goal is, and how to make trade offs and stuff like that. And, and then you end up with basically like a lot of really long meetings, a lot of discussions. is a lot of talking and not a lot of doing, you know? And I think we are kind of... Shape Up in a big way is about how do you channel people's own ability to solve problems and contribute creative ideas? But how do you actually channel that by giving boundaries and direction without over-specifying it? Yeah. yeah so that's definitely something that has been on my mind a lot lately for sure and hoping that this will this a way of thinking about things will hopefully help with that okay so i can imagine that um you know it comes time to to actually try and think about what it would mean to implement this or to to actually do shape up and i'm guessing it wasn't just like wave the magic wand and now everything is different right like there's probably some yeah some struggle and some misfit. I can tell you like where the pieces that we kind of adopted first and like where we kind of tried to start. And the one that has always stood out to me is like something that made a lot of sense to me as being really important is picking deadlines for things, you know, just like the fixed time approach to things, which I think really helps with our first. Yeah, like our first problem that we kind of talked about, which is like feeling like things aren't getting done. I feel like if you don't give deadlines to things like. you're contributing to that problem whereas if we start throwing deadlines on things well maybe we can start kind of solving that problem yeah um so that's kind of how we started was just figuring out okay like let's prioritize some projects and um decide on a reasonable amount of time to give them and and i'm trying to be deliberate about actually like assigning way more time than i feel like is absolutely necessary for things because i think it's it's probably safer that way to guarantee to guarantee success in terms of like not having to push things back or something right so we will even pick like like brad's first project which was like the diagnostics linting feature for the intellisense plug and he already had like a prototype of that built that he'd worked on in his spare time um which was which was great wasn't really ready for prime time and of course like the last 20 is like 80 of the work sort of thing so we um i think we gave him like a week, a full week to kind of finish that off, which doesn't sound like a lot. But when something's like most of the way there, it was actually a lot of time. And the way that we've kind of been doing this, which I think has been working well so far is even when we give a project a week, it's not like a Monday to Friday week. It's like you have the full week, Monday to Friday, and then we're going to launch it on like the Tuesday of the next week. So you have like the Monday to sort of wrap up any final sort of details like. finish up a little announcement blog post or whatever put it out tuesday morning and then we use like the rest of that sort of launch week as like house cleaning help people out with their stuff kind of get like re organized and you don't start on like another project until like the next monday that's kind of been the way that we've been approaching it sort of like the the six week like two week approach that you guys take with like really compressed down um like a micro cool down Yeah, exactly. So that's kind of how we've been doing that. And that's, that's been working well so far. But again, we've only done it for two projects. And both of those projects were much more like base camp style projects and the sort of, there's some design, there's some development, both of them can sort of happen in tandem, because they don't really depend on each other too much. Like the IntelliSense thing, there's barely any design work for that. The only work that steve had to contribute was helping to put together like a little marketing like open graph image you know what i mean but even that was like a few hours of work to get right but that actually leads into like a discussion that we can have but maybe not like right this second around like should steve be allocated to that project if he's the designer and there's design work needed but there's certainly not a week of design work needed yeah that is that whole idea is like a one of the biggest points of friction for us right now and trying to figure out how to fit that into our process. And then the other project we had to we wanted to launch like a little micro blog for the company where we could post these announcements. Because we like having like these visible sort of like if we can scroll through this blog post and see these dates, and we're making sure that every project has like a little post that goes with it. That's kind of like capturing like all the output that we had for the year. You know, it's like one like central place to celebrate that stuff, which feels it's funny. We went we went through the same process early on at Basecamp. We when we first got into a rhythm of shipping new features for Basecamp Classic, like we're talking like 2000, I don't know, probably was 2005 or four or something like that. We ended up writing a custom tool called Champagne. And the whole notion was to like celebrate new releases by being able to publish them with some sort of a micro blog thing. It was totally like, this is like a thing that must happen to everybody. Yeah. Yeah. Yeah. Yeah. So, I mean, that worked well for both of those projects, but a lot of the work that we do is like work on this, like tailwind UI project where Steve has to design, like say, three or four new like hero sections for landing pages which yeah it's going to take him a lot of time and because unlike base camp like our the design team isn't also the front end development team there's like a handoff that has to happen and until there's like something to hand off there's not really anything for the developer on that project to do so it leads to this question of like how do we fit that into this approach and a bunch of things come out of that in terms of like options in my head one is like do we take a project like that and actually split it into two projects with two separate deadlines there's like the design kind of output and then there's like the development output which i know like probably like makes the hair stand up on the back of your neck working at base camp where like you just like are so opposed to the throw it over the wall like build the design thing um where like the high fidelity design is not actually I would put, you know what I mean? I've heard it a million times, so I know exactly what you're thinking. But then the other approach is like, well, maybe we just- I do have a framework to justify it though. I could twist myself into justifying it. But we'll see if we need to go there or not. And then the other idea is like, well, what if we make sort of the people assigned to projects a little bit more flexible? So instead of like, this is a two week project, which really means it runs from like Monday to like the Tuesday, like a two and a half weeks later. Like that's kind of like our version of a two week project instead of it being like, okay, Brad and Steve on that Monday are starting on this. And Brad is just kind of like twiddling his thumbs until Steve has something for him. Maybe like the project exists on its own as a thing with a two week deadline and people kind of come in and out of it based on when they're kind of most needed, but coming up with like a system for that. that feels structured is hard too. But then I have to wonder how much structure do we actually need in that? Like, do we really need to micromanage people like little ants or can we just trust that everyone is like a mature grownup person and they can see, well, yeah, this is coming up on the calendar in a week. I should check in with Steve and see if he's got enough for me to kind of hop in and start working on my part of this. But if you're doing things that way, what are people doing in the time that they're not needed on the project. Does that mean that you have like projects that kind of overlap and now things are getting complicated, right? Which I really hate the idea of people having to juggle things, you know? Yeah. How can you be efficient and also structured? I don't know. It's tough. Yeah. Yeah. There's also like an interesting trade-off there because juggling when you have too much is really, is really unpleasant. And juggling when you actually have a lot of free space is pleasant because it actually means kind of like, oh, like I'm sort of waiting on this. I have something else I can nibble at while I'm waiting on this. So there's a very different kind of universe of that. We actually have, until you sort of describe the situation, I didn't even appreciate this before, but we actually have a practice. when we schedule so-called small batch projects for a six-week cycle, we might have, let's say, three different projects that we plan to happen in those six weeks. And we'll give that to one team that we'll call the small batch team. And it's like, you're going to do these three things. And there's a sense in which each one of those individual three projects has a kind of appetite to it, which is like more or less, let's just say for simplicity, it was two weeks per project. which somehow totals to six weeks. The thing is that we're not actually saying after two weeks, the first one will ship and then you'll start the next one. And then after those two weeks, we're totally fine with allowing those to overlap during the six weeks. So there's this kind of like, it's funny, it almost reminds me of your pros problem of like something that used to be really discreet is now getting like mixed together into a container. But it's like, we actually have this thing where like, At the end of the six weeks, we are sure that these things are going to ship. And given the cocktail of work that we've put in, we believe that none of this stuff is going to sort of, we're not going to be spending longer than we want to on any of these things. But there's also going to be kind of enough flexibility that the team can self-manage. Like, look, we don't care how you do it, but there's going to be some design needed for these things. And these things are a little more programming heavy. But if at the end of the six weeks, these three projects ship we kind of don't care about yeah um sort of measuring our yield or whatever you know what i mean or like how the hours were spent um along the way that's kind of like an interesting alternative to the what i imagined in my head as overlapping which was more like okay well this is like a two-week design project but brad has been on like a two-week project that actually ends right in the middle of this whereas like ended like right before because of the fact that maybe like Steve did his design stuff and maybe Steve and Brad are like staggered the whole time. You know, it's like there's like the design week and then the building and then the time for the next project is happening. And that's where things start to feel like hard to. Exactly. So this is a planned overlap. It's very different than self-organized overlap within a box, you know, and there's this notion where like actually the more complex the timing is. the less you want to actually try and dictate it. And the more you want to create a wall around where that can sort of happen in a spontaneous way. Yeah. Yeah. I think that makes sense. And that's not like something that I really considered. So I'm trying to think of like, it still seems tough because if, if everything depends on the design, then where do you create like the first set of walls? You know what I mean? Cause it's no matter what the beginning of the, it's going to be design. So here's another place I wanted to go. I want to ask you, I want to follow that design work upstream more. So like, where does the idea first come that like Steve is going to start designing this thing? Like, how does that? Because I get that like, you need to have the design before you can implement it. But like, what? How do you get to like him working on that design in the first place? Yeah. So there, there's some just like founder level product strategy elements there, right? Which I think is up until now, we've sort of been working through a predefined backlog. Like we sort of worked to identify like, what do we think is a substantial sort of think of it as like a table of contents for this like components directory. site, what are all the kind of important UI patterns we can identify? So we have a checklist to sort of work against, and we still have a few of those left basically, because we released the product in sort of like an early access model, but we're starting to run out of that. And we still, still do discover new things that we didn't think of that we add. And a lot of this just comes out of just, um, we'll notice something during our day to day on something. browsing Twitter and we see someone linked to a website and we look at the website and it's like, that's an interesting little thing. That's a component. And we didn't really think about that. What other stuff can we put in that category? Yeah. Me and Steve talk on the phone a couple times a week, at least, you know, and these things are just sort of come up, just sort of like a catch up. What are you thinking about lately? And, and historically, like we've worked together to sort of identify this stuff on some call at some point in this. And this is like pre us trying to implement any sort of scheduled work. approach right yeah so we would sit in Figma or whatever, pasting in screenshots from websites, kind of figuring out like, does this kind of fit here? Does this fit here? And then make a list of like, okay, well, if we had to build like four of these, like what could they sort of be? And just kind of describe them in words, you know? So if it's like say feature sections for a landing page, we could say like, maybe it's like a two by two grid that has like the features, or maybe we can do like a zigzag thing, whereas there's like a description and an image and then an image and a description, or maybe we can do like a stacked list and we just sort of identify that stuff. And then he goes and starts tinkering with ideas for it. And then eventually he has them fully designed and then I start building it. And now the interesting thing about this is like there's like a design phase that has to happen before the development. But in my experience, the designer is still very much needed throughout the development process. Yeah. It's never like fully. hand it off and then it's done like no matter how hard steve works to think of every edge case in every situation um you missed like the focus state on this button here and we don't have an example of that and i tried something but it looks bad and you know right so there's always collaboration that happens during the development process but not necessarily during the design process like there's a little bit in terms of surfacing what are we going to make what are like the rough ideas, you know, like the shapes of these things and then Steve kind of goes and can fill those in. But something I've been wondering, which maybe is related to what you're talking about here that I was going to ask is like, could we almost consider like some of the higher fidelity design stuff to be like the output of the shaping phase? You know what I mean? So that's where my head is going and I'm wondering about that. And the thing that, you know, I don't know how far we can go. in this format, but let's try. What I'm curious about is from the initial conversation of like, hey, I think maybe we should have a component for X, right? To what you've called finished design, like this is ready to go to programmers. Finished, yeah. Yeah. These are like words that we use, but there's actually a lot of intermediate stages of the work where the work goes from Bob's partner, Greg, he's used this term with me before, from soft versus hard. The design is very soft in the beginning. Maybe it's going to be like this, maybe it's going to be like that. And then there's a point where it's totally hard. It's all fixed hard points in the design. Is there a point? before the design is finished, where it's, let's not use the word finished, but let's use the word like solved. Like, where's that point in Steve's work where he's like, you know what, I'm not done, but I'm not worried anymore. Versus like, there's that earlier part of like, I don't actually know what parts of this are like the... Yeah. You know what I mean? There is definitely a point where it's like, okay, I've landed on three ideas that like, these are definitely the ones that I'm going to take over the finish line. I definitely have them roughed out in a way that like most of the changes I'm going to be making from this point forward are probably going to be mostly superficial. Yeah. So what I, what I think the, what I'm imagining an opportunity is here and then push back on me if I, if it doesn't sound like it's fitting is. is actually I think what I imagine is happening is that Steve is taking something from zero to like 95. Yeah. Right. And then handing it off. And what I imagine is that there's actually an intermediate point where he could say, you know what, I know what this is and I believe this is doable now, but there's a whole bunch of dialing in that I still need to do. That line, whatever that point is, that's actually where shaping ends and production begins. And I think what's happening is, it sounds like there isn't a differentiation in his work right now between those two phases. And what could happen is if he actually played with stopping earlier and figuring out what is the fat marker equivalent of a component look like, where I believe in it. but there's still enough risk in it in the sense of like, I've still got to work out some details, but like we actually want to schedule this now. Where's that point? Because what could happen then is if he stops earlier, then actually the overlap will increase because there's more work that the programmers can start doing while he's still tuning the exact radius of the corner and the shade of blue and whether those two purples are. are similar or different enough or you know what i mean yeah it's tricky because with the sort of work that we do like the type of programming for these projects is very much just like implement exactly what's in the design there's not like a well i can sort of figure out the database schema for this while steve is doing that you know it's all like hyper isolated to the front end and um the risk i think is With the way that these technologies work, like HTML and CSS, something that looks visually like a very minor change can actually be like a substantial architectural change in the markup very frequently. So it's hard to start on something and not have a high risk of like it almost like going to waste, you know, like I'll have to like rework that completely. That even still happens when we get like the 95% design. and then work together in the final phases of it. You'll get something totally finished. And actually, this is a perfect example. You'll get something that feels totally finished. You build it all out. And then you think, what would happen if that text had to wrap in this list? And now the card next to it gets a little bit taller too. And now all the buttons have to get pushed to the bottom so that the buttons all stay aligned. But fuck, the whole way I built this. uh means i have to group these things together instead of these things together for those of you you know what i mean like that happens no i see now i understand better actually this it doesn't map so well to what we do on like normal product like you were saying when you worked on the um like microblog to announce features to announce new changes um there's actually a level of abstraction that you just don't have because it's not about like If I click this button, then I get to this other screen and it kind of doesn't matter how we exactly implement that. You're actually working lower in the weeds from the beginning because the work that you're doing is down at that level. It's like you're closer to the metal. I'm coming around. I think that your idea to actually deliver a fully suspect high resolution pixel perfect thing and treat that as the input for the bet. I actually think that's, I'm with you on that. I think that's actually the way to go. Yeah, no hairs standing. I think that's actually reasonable considering the fact that you are actually in a production line situation. There isn't like a higher level thing that you're trying to get to that has degrees of freedom in it that you're going to try and like learn by building, you know? I actually think the degrees of freedom aren't there. So you actually are in a more of a... like a value add production stage more of a factory situation i think you're in a different environment with that yeah okay so i agree with that but then the thing that becomes tough is it feels like that pushes steve's responsibilities into unstructured work land which um i don't think he'll be super excited about because like for him he's been totally into this idea of like, I feel like there's a lot more structure around what I'm doing now. I feel like I know I should be focused on this instead of kind of, you know, experimenting with all these different things at the same time. So do you have any ideas on how, how we can make his side of things feel more structured? Cause like, at least from my memory going through shape of the times that I had, I've read it and I haven't read it in the last probably month. I remember the shaping phase as being this very, some things take two years to shape, some things take two weeks to shape, you know, it's just kind of this idea that's been rolling around in the back of my head, and sometimes a little piece of clarity shows up. Yeah, I think I think I'm starting to see a suggestion here. So I think the first, the first thing we talked about with with with, I think there's an opportunity for him to just look at his process, and make this differentiation between when was I getting to the point of like, I think there's a component here and not just an idea for a component. And then his execution of that component to the fully designed version. I think that there is a shaping phase that's implicit in what he's already doing or what you're doing together. It might also be what's happening between you where you're kind of like, should this be a component? Is it possible to make this a component? Do we know how to... Can we set the boundaries on this? So this is a thing that you're going to go make and we believe it's going to happen. I think actually what could happen is it might be possible to think of Steve as an independent team that he basically has his own cycles, more or less. And you actually make bets on his time for what is he going to ship. And shipping has a different definition for him. He ships. to the input of a further cycle. We have a little bit of an analog to this in the sense that our web teams lead all of the work on our products and our mobile teams do actually follow. that work because the core apis are going to start from the web team because we're designed around the so-called majestic monolith that david calls it you know um we we would not um this is not i'm not claiming that this is the ultimate way everyone should do it but we are organized around a hybrid model which means that like the there is there is a core and that core is the web um because we're organized in that way a lot of the things that our mobile teams do is necessarily downstream. It's just got to be. So what's going to happen is the web team is going to prototype some new thing. Like, hey, when Jonas and Jason were working on, hey, there was a web inbox first. And then there were a lot of core architectural decisions to make around like, what is the inbox? And like, how does the screener relate to it? And blah, blah, blah. Like there were these core things. Once those were figured out, for example, iOS and Android could implement native inboxes. But they actually, in a way, were taking the full spec of how the web version worked as an input to their process. And this cycle was happening after some cycle had already finished from the web team. We have dreams of, because of course, like we would love to have some things be more native first. We would love to have like more cross collaboration between those teams. But you know what, like your org structure, and your basic processes just rule you. So at the end of the day, no matter what kind of collaboration we wish we could have at the end of the day, because we're a majestic monolith, because we're hybrid at the core, mobile is going to be downstream from web in a lot of cases. Yeah. And that's actually something that we kind of live with. And it seems to be all right. I'm seeing a parallel here. Yeah, that's really interesting. Yeah, I see that as well. um so i think the key the key step there is to the key step there is to is to is for steve to make a transition to saying where am i in the shaping point of like i never know if i'll finally have a way to think of this as a component versus like now i have an idea for a component but but i'm not going to start doing all the the in the weeds work on this until we make a bet on it yeah okay so the things that i think are still i'm still trying to figure out in that model are One, Steve is still needed during like the development cycle, right? Yes. So, you're doing the development cycle. Yeah. So, does that mean that we have to like schedule like a week project for him to do like these component designs, then like a week project to build them, but he kind of has to be on both and he can't start the next design cycle until like after that development cycle is done because they need his input during that period. But now there's no development to do, not necessarily no development, but it means we have to. shift off of the front end development component D type of projects and maybe find some open source stuff to do instead but it creates this sort of like out of every three week period only one of those can be like actually building components you see what I'm saying these are offense this is like so good these are amazing questions so I think what you're what you're pointing out is that there's actually a whole art and science of betting that the book doesn't even begin to touch which is You know, just for example, like we have people who go on vacation. We know that they're on vacation before we make a bet for the next cycle. So there's this whole calculus of like, what skill do they, what skill are we lacking because this person is gone? And then what type of work can we schedule because that skill is not available? So if it's like our super JavaScript person, then we're not going to do a super JavaScript thing that cycle because they're gone. So there's already a whole puzzling. aspect of betting that is not there in the sort of naive shape-up presentation of it. But then further than that, there's also just the notion of reserved capacity. And so what I could imagine could happen is that you could have a cycle starting. I mean, so much of this is just about actually having that moment where you have this deliberate thought process where the cycle is starting and you say, okay, we have some components that Steve has finished designing that need implementation. And those are going to take some portion of Steve's time this next cycle. So then how much capacity do we want to reserve for that? Given that we've now reserved, let's say it was six weeks. And let's say you said, you know what, let's assume that out of the whole soup of this six weeks, and we're not actually scheduling it in terms of sequence, we are allocating in terms of just sum, which is, you know, So let's say somehow out of this whole six weeks, let's say we reserve two weeks of capacity for Steve to play the supporting role of the unknowns that are going to come up in the implementation of the already designed components that are coming in as an input to the cycle. And you could say, well, like, let's say that leaves four weeks of capacity for Steve to do other stuff. Then out of that four weeks, what's our appetite given the new stuff that he might want to design and what is actually sort of ready? in terms of being shaped and what is sort of speculative in terms of um i want to explore this to see if i can get to a component idea on this thing right and then you can deliberately inside of that time box you could deliberately say look um we have two weeks of appetite for steve to get to the sort of finish line of this pixel perfect ending point of his design phase on this one component right yeah and let's say that leaves more or less another sort of two weeks that's not accounted for um you could choose to um bet that two weeks on the execution of another component idea that he's shaped but hasn't started yet so this is kind of where this hill chart idea comes in like if he's if he's got some sort of like he's he's done the shaping on some component but now like okay let's take that downhill on for his work of that for two weeks or um because you're so small you could say you know what um take that two weeks just for shaping and let's use that time to figure out like what the next most valuable component could be or um to to find an approach on some gnarly thing that we don't understand yet or or whatever you have a lot of latitude you know in in sort of what goes into that that box that you bet that makes sense i think the thing that i'm hearing there that i wasn't thinking before is that maybe our current approach of make really small bets is less compatible with that. And we need to think about that. Like you're talking, you're saying six weeks, six weeks, six weeks, but like most of the stuff we're doing is like one week, two weeks, one week, two week. Right. And if we do it that way, we can't say, well, let's reserve like 78 minutes for Steve to do shaping during this one week cycle or whatever. To use an unfair word for it, you're unintentionally micromanaging. Yeah. I think it can help for me when I think of the word micromanage, because I use it in my own mind very often. All it means is planning at the wrong scale. Yeah. And there's a scale at which it's just too small and the errors accumulate too fast. You know, like if we're wrong about this one week, then like the next week is screwed up and it's like, there's no way, there's no shuffling between them. versus when we plan at like more or less six week level, even if we're only doing one week long things, we can put them into a soup where they can slide around each other according to the dictates of the unknowns. And then at the end of the six weeks, we can be more confident that somehow this stuff will all get done, even though we couldn't have anticipated what got worked on on Wednesday and what got worked on on Monday. It feels like I have this like internal discomfort with that. for some reason that i think it feels like risky to me to bundle everything together into a six-week thing and then find ourselves in the last week realizing that there's still a week of stuff to do on each thing you know what i mean and now how do we prioritize what to get done and what to not get done whereas if we said like yeah for this two-week period we're going to build out these content sections components and then That's it. We don't have to worry about like making sure that we're not forgetting to move these other boulders a little bit up the hill as well. I guess it reminds me of that like doing too much at the same time world that we're coming from where it felt like There wasn't like deadlines on on everything to guarantee that they got done like there's still a deadline but it feels like The thing I like about how we've done it so far even though there's issues with it, of course, which is hard to do this conversation is that I feel very like sure that everything's always going to get released on the days that we're finding it to be released. And I'm trying to figure out how can I maintain that certainty when we're trying to do a lot of things at once. Yeah, totally. So a couple of thoughts on that. First of all, I just think that that's I just first want to say that I really like how you articulated that. And I really understand that that feeling of like. Like I get that, you know, cause there is, there is a trade-off that we make, um, with self-management. And basically we are, um, kind of constructing on purpose, a chaotic box because sometimes actually the chaos is the, is the way that we get the order we need. This is very counterintuitive, but it's totally true. And this is like something Jason, David are masters of that I've tried to. learn to articulate in this whole model. The whole notion of like, don't assign anybody any tickets and just give them the shaped pitch and then leave them alone for six weeks is exactly this kind of a trade-off. It has a similar feeling of like, I'm giving up control, but actually they need these degrees of freedom in order to solve it and win. So I think this is just like hugely important just to even sort of like feel that and acknowledge it. is two observations come in that might be helpful. The first one is, part of it I think is about easing into it. So it might be that you schedule two things that overlap in a slightly longer time box and you're not going straight to like six weeks with four projects happening inside of the six weeks, just so that you can step your way into it. The other thing that... i'm i'm i'm picking up a little bit and and and just tell me immediately i might i might be totally wrong but i'm picking up a little bit of this um um very um common mindset that we all have which is like i have uncertainty and so my way to solve the uncertainty is to pad okay like um and this is actually i think um wrong i think this doesn't work Because what it does is it doesn't actually engage with the uncertainty and get, it doesn't, it's like there's a swamp and it's like, instead of going in the swamp, I'm just gonna put on like heavier rubber gloves. And what we're always doing is we're actually trying to get in the swamp and figure out how to wrangle that uncertainty more. And so I think there's an opportunity to say like, We don't know how long it's going to take and and then sometimes we get surprised and then we run out of time and so let's add extra time instead of that what what what I think we what we try to do is we We put a lot of effort into what we call sequencing So we're having way much more like I don't know the right word for this like the word that came to my mind is aggressive and what I mean is like i want to interrogate the work like the work that i'm biting off right now i want to really challenge it and and pull it apart into little like it's sort of like factoring when you're coding yeah i want to really like insist on like single responsibility principle like that's you know you know the difference when you work with programmers who do that once you don't like all of us i think have an opportunity to do that more with the work and so like in the first week of what we're doing are we actually kind of looking at the interdependencies and picking that first thing that has the most unknowns in it? Are we really doing that or not? And if we keep doing that, what we're going to find is that all the stuff that's left at the end when we're starting to run out of time are all screw tightening things. And they're not those kind of like, oh shit things that we're like, oh, we're going to need another week and we didn't know it. My sort of gut sense is to, is to lean more into that sequencing work to get to a point where you feel more confident that if you say like we're only going to spend three weeks on this and and inside of a six weeks box the team knows that this is only worth three weeks that they are going to internalize slowly but they're going to internalize this slightly aggressive stance toward the dependencies in the work and they're going to be more productive inside of that variable scope. I think that makes a lot of sense for much more cohesive work, I think. But where I worry it falls apart for us is that to fill six weeks, we're going to have very unrelated things happening during those six weeks. Like what might be, let's design and build some content sections for Tailwind UI. Let's also implement like a dark mode feature in the Tailwind CSS open source CSS framework. So that's by design. So that's... I might be overstepping because I have so little context. But I think the opportunity there is that if all of these pieces of work are actually very different, it means that they can move forward at different speeds according to when Steve is available. I think that's true. But I guess my fear, and I could be wrong, is that when this... dark mode feature for example which we could probably do as like a three-week project gets stuck into like a six-week box yeah all of a sudden there's this feeling of like uh we still have to figure this out but like we still have like four more weeks um and then like you end up with like one week left at the end and a lot of things are in that same state where it felt like yeah this is what i'm talking about this is what i'm i'm i'm failing to articulate about the sequencing If the team internalizes this sense of urgency about getting over the hill, what our teams do with the small batch projects is they've got, let's say, three projects that are totally unrelated in a big box. They very aggressively get the biggest unknowns of all three over the hill first. So how do you do that in terms of... picking which one to start on and when to Stop like if you hit like a gnarly problem in one and you feel like I don't know what I could do on this right now and I think I just need to like Give it a couple long walks outside before like a solution comes to it Yeah, switch the other thing that I think I could try and push that boulder up the hill a little bit further like how do you avoid that risk of? Not actually getting everything over the hill early enough in that way you know what i mean like yeah you just say like i'm not i'm not taking a breath of clean fresh air until this is like over the hill because that it's there's too much risk that i'm not going to come back to it i think we're coming to another missing piece of the puzzle here which is um it's what it sounds like is um uh it sounds like maybe there isn't enough shaping on the technical implementation work before the bet gets made because here's the thing if we actually shouldn't be going into a project with like, I have no idea how I'm going to implement this. Yeah. We should, before we make the bet, we should actually have the tent poles of the implementation already clear. But there's still an uphill phase though, right? There's an uphill phase, but the unknowns, the purpose of the shaping work is to shrink those uphill unknowns to being minor ones. So there's gonna be a whole bunch of little unknowns, but they should all feel, technically we would say thin-tailed instead of fat-tailed variables. We would say like, every one of these unknowns is an unknown, but it's an unknown that has a certain character to its probability distribution. It's not a killer unknown. It's just an unknown. But all of those are bounded by the shaping work that we did where we said, look. Like it's gonna be like this, this, this, and those three things are gonna come together and that's the core idea here and we believe that's doable. So what I think is gonna happen is the more you actually de-risk the implementation work by doing a little bit more shaping with the programmers before the bet is made, you're gonna find that the work is gonna feel like its overall character is a little bit more downhill. There's still always gonna be those unknowns. but they're not going to be these big discovery how the heck am i going to do this kind of things and then um allowing these things to slot and slide over each other is going to feel much more trivial okay yeah that's actually related to another question that i had for you which is um just around like the difference in the amount of shaping that different projects might have and where some projects feel like 90 of the work is the shaping I don't know if you've experienced that with stuff you do at Basecamp, but like, there's been somewhere like getting to getting to the ideas, all the hard work. And then once you actually have the aha of like, the key, the key moving parts, then the implementation is pretty trivial. It's almost just a, it's a decision, like the project is a decision in a lot of ways, like a very concrete example is something we're literally working on right now, which is that pros plugin again, but the the biggest challenge with that project is figuring out like what do we expose in terms of letting people customize like these typography styles so uh kind of the tldr for like what we plan to ship as like the user experience is this plugin that adds a few classes to the framework like pros that is just going to you throw it on some markdown content essentially and it looks nice but also like pros-lg where if you wanted like a 20 pixel based font size you know like you read a lot of articles online where there's lots of different ways you might do this like a documentation site where like the documentation is like part of the whole UI, maybe like 16 pixels is like the right base size for that. But you're reading like a New York Times article, maybe it's like 24 because it's really supposed to be like this central experience, right? So you want to give people a few of these like modifiers. But now what if someone wants to add like another size that we don't offer? Or what if they want to customize one of the sizes? If they customize like the font size for a heading, well, now they need to be able to customize the margins above and below the headings. And now they need to. what if like they want the margin between an H2 followed directly by an H3 to be different than an H2 followed by a paragraph? You like very quickly approach like CSS is like the customization language, but it's like, we have to resist that because now we're not doing enough to help people. We wanna, how do we prevent it from getting to CSS while still being useful? And that is the hardest part of the whole project is figuring out what is the public API for this plugin? And that feels like shaping work. in a lot of sense. But how do I? Yeah, I mean, when does that shaping work happen? It feels like I need to put a two week block on the calendar where like, my project is the shaping of this project, you know what I mean? Yeah, so that's a great question. You when you are at the size that you are, there's no other way to actually do that deep shaping work unless you reserve capacity for it. We at our at our scale now, have dedicated shaping track because we have so many people that we kind of have people who are full-time building and full-time shaping we we didn't have that until until after many many years um that's absolutely a scale thing um so when um oh you can just go meta on this and say what's my appetite for um coming to a conclusion about whether or not i can shape this or not yeah so like am i comfortable risking uh whatever four weeks on coming to a yes or no answer of like, do I have a solution for this thing or not yet? Right. And then you can, you, you, you make that bet, you, you put that four weeks at risk. And then at the end of that, you either come out with a shape or you come out with a conclusion of like, this problem is, is I'm missing an insight that I don't have. And I could, I could sit around for week after week and not have the insight. And then, and then, and then, so what I like to do is I'll, if i believe that this is something important and i believe it's solvable but i just have to focus on it i will allocate that time and say like i am going to only work on this shaping problem for the next cycle but then what happens is if i get to the end of that appetite i can't just think about this one problem forever so i'm gonna i'm gonna say look like i did everything i could to understand the problem i still couldn't crack the nut i'm gonna wait until i have a eureka in the shower and that might happen a year from now right but when that eureka comes all of a sudden it's gonna be like ding. Yeah, okay. So now we know what to do, you know? Yeah, so that's interesting because like that was in some ways my plan for this project in a sense. Like I know that this particular project, if we knew exactly what we were gonna do, it's like a two day thing maybe at most. It's like not much work. Most of the work is in writing the documentation that tells people how it works. You know what I mean? But we allocated like a full two week cycle to it, like, which is like a two weeks plus two days, the way that we're kind of building in these like cooldowns right now, which maybe we should change exactly how that works. If we're going to bubble things up like a bigger scale and bundling more small batch work. But in this case, because I know that that, like, you could basically say that like this project that I put on the calendar is the shaping project for this like pros. Yes. You know? Yes. But. The reality is if we come to a conclusion about what to do and there's two days left, we can build it. You know what I mean? Yeah. So doesn't that in some ways become like contrary to the idea of like shaping before you work sometimes? Because it's like now we've created a project that has shaping and the work in one. I recognize that in general for bigger things, probably what you're doing here is introducing a hell of a lot of risk. You know what I mean? Because like now you're. Whereas you might have just bet like two weeks to shape it. And then if you came to a conclusion, bet four weeks to build it. Now you're betting two weeks to shape and build it. Where those four weeks at the end are sort of hanging on like, well, if we don't come, if we don't end up being able to shape it in the six weeks, well, we lost the whole six weeks instead of the two weeks that we bet on the shaping process. You know what I mean? I don't know where I'm going with this other than to say. Yeah, let me, let me say it like this. I think, I think the deeper point. of all this stuff is that work has different phases and these different phases of shaping and building have very different risk profiles. They have totally different risk character. Shaping is extremely fat-tailed and the thing that you think you might want to do could be really, really hard or it could come together immediately. And we don't want to make an expectation that we're going to successfully build something unless we've kind of thin-tailed the variable. And then we have this feeling, and we know that it's thin-tailed when we have this feeling inside of like, I'm not worried. Like if I had to go and sit down and just crank this tonight, like I could do it because I know what to do. As opposed to like, I would have to sit there and... and dream for and go on long walks for three days. Like no long walks. You know what I mean? I mean, unexpected things come up, but like fundamentally, no, right? So the thing is that it's all about our expectation. So we never want to say, I'm going to shape and I'm going to build as one bet because the way that probabilities multiply, if you have a fat tailed variable and a thin tailed variable. what's the product the product is fat tailed really fat tailed variable yeah it's it's it's it's as fat tailed as the most fat tailed part yeah at a minimum yeah so um so what it means is that um we we always want to seal off the shaping risk from the building risk and we and we and we only want to bet on stuff that we actually have gotten through that that shaping process because we can actually make the commitment to ourselves that this thing is going to ship So the commitment to ourselves, if we allocate time to shape, is not that this is going to get... You might have this really nice property that you get to ship it two days later if you're so lucky that you succeed in shaping it. But that's luck. That's not the bet. The bet is I'm willing to risk this number of weeks on shaping it to see if I can get to a solution or not. truly you actually have a separate bet to make that you know would only be two days worth of work after but it is a it is an independent separate thing yeah yeah does that make sense yeah that totally that totally makes sense and i i can totally see how on especially on most projects the value proposition is even more clear than it is for like this one specific example you know what i mean this is almost like the most extreme example of it that i can think of for our own work So I think that makes sense. And I think what I'm happy with at least is that I feel like I'm getting permission to sort of do what we've done, at least in a sense. You know what I mean? Where it's like, because I was going into this sort of thinking like, this does feel like the hard part of this is all this shaping, but when am I going to give myself the time to do that unless I put it on the calendar? And half of the shaping work is prototyping it. to learn like does this idea even work and then yes once i know that the prototype works there's like no difference between the working prototype and the finished product in this yeah uh in this type of project you know yep um so yeah so it feels like at least what we've done there is okay and allowed um but i do have other questions two more questions for you i guess if you have time yeah which is one is related to that, just general idea of like allocating shaping time on a small team. Because there's even some projects like the project that Brad started on, he knew way more about than me, right? And he's sort of like an expert in that area. So in a lot of ways, like, we should collaborate and figuring out exactly like what we want it to be, but like, it needs more of his input than mine. And that means like, he probably needs to be given time to like, figure that out before like we put it on the calendar but we are also doing the work um so if you have like and if you bring this back to the me and steve sitting in figma throwing screenshots on the page to figure out what components fit into what categories what we should build next like that sort of um shaping work too like you know just figuring out what opportunities are out there and what we should be working on like fitting that in in a structured way i guess is something i'd like your advice on because there's the easy version of that which is just like every two weeks on wednesday afternoon like we sit on a call and uh talk through like ideas we've had and play with some that we're both excited about and see what direction but i wonder if you have more insight into that and um in terms of like how you've done it in what way you think works best for making time for that sort of stuff yeah so i think this absolutely maps back to first of all we have to put it in context of scale when you reach a certain scale, everything can get crystallized into six weeks, two weeks, six weeks, two weeks, and you do this and I do that. But before you reach that scale, you can't regularly schedule a certain number of weeks to do shaping because you need to use your time in a, how do I say this? Like the, When you're small, you know, like this two weeks is different than that one week. You know what I mean? Like this week is different than next week. Like so many things are moving and changing and happening. And it's like, it's a very different environment when you're small. And so I think the thing to work on is less about the schedule, is less about like a repeating schedule because that is a larger scale structure. and you aren't at that scale yet for repetition. The thing that you want that you can hone is your, you can develop, you can refine your sort of Geiger counter for this risk. So what you want to do is you want to have like some, any random project comes up in front of you. and you want to be able to hold up your geiger counter to it and it goes like and you're like up this is like this is not shaped enough um and what you want to do i think is um um you want to be um we have this uh term from from from uh the uh like complex system science we say patchy okay like you don't want to be black or white you want to be like like a little patch here and then a different patch here and then a different because That's how life is. When you become larger scale, you become more like a crystal where it's like ding, ding, ding, everything the same size. But when you're small, it's more like weird patches that you have to customize to what you're trying to do with who you have and the time pressure and the urgency and all this stuff. So if you have the Geiger counter, then what you can do is you can say, this thing that we're about to take on is setting off the not shaped enough alert. Now let's just use our cause and effect. If we start working on this thing, it's going to become one of those things that gets 60% done and then gets set aside because it turned out to be a little bit gnarlier than we thought. We didn't get done inside the appetite and then we had to move on to something else because of availability of people. And we don't want that to happen. So what do we do to not let that happen? When something appears that it's not shaped enough, and we're aware of that. We've trained our awareness of that. And it's also valuable. Now we need to make a special case and allocate time to do that shaping work, right? So it becomes a little bit more like a Tetris kind of a thing. You're fitting together different chunks of work of different sizes, but you're very conscious of what's shaped and what's not. And then what's my risk level if I kind of allow somebody to, like, this is what they're working on next. It's developing that sense. And it's going to be more chaotic in the beginning. But because you have the Geiger counter, you're going to be able to make a lot of custom, but wise decisions. And then as you grow, once you grow to have more people, then... depending on how you kind of design your growth in terms of your org structure, you can design yourself into a way where your org has constant reserved capacity for these functions all the time. That's what we have, right? But until you can afford all of that reserved capacity, you have to interleave it. And the way to interleave it is to constantly make those judgment calls about what's shaped and what's not. And then what are we going to work on next? So how does that fit in with like this idea of trying to move towards like grouped small batch work with like the bigger boundaries? If we're making these like little small bets like placed after each other, you know? Yeah, you're asking like amazing, really good hard questions. So I'm just learning how to spell this out. Okay, I think I understand it, but I'm just learning how to try and articulate it. What I believe, I believe that when we cannot see the exact interdependencies of when are we going to need some design help on this particular programming project, when we have opacity and we can't see that, then we can't plan it. So if we can't plan it, the alternative of planning is timeboxed soup. And I don't have better words for this yet. when I can't predict like today and then the next day and the next day, I need to just mix them together into a container and say, but do I believe that they can all happen in this box? Yes. Sometimes the answer is no, right? But if the answer is yes, then I can use this as a technique. This is actually a scale transformation also. This is, there's some rigor behind this, but I haven't learned how to spell it out completely yet. It's that. If I try to control the things at the fine scale, I don't have enough flexibility to deal with the unexpected. That doesn't mean that I just have no plan at all, because I might understand enough about the nature of the unknowns that if I box them into this slightly bigger box, now I'm talking about this one box instead of five small boxes, right? that's what a scale transformation is. I'm talking about one bigger thing that has different rules than a bunch of small things. This bigger box, it has different degrees of freedom in it. People can say, oh, not today, but tomorrow. They can say that to each other and they can customize the way that they schedule with each other inside of that box, but the box still gives them this pressure where they're like, yeah, but it's... if it's not today, it's actually has to be tomorrow. And it's like, okay, I can do it tomorrow. You know what I mean? It can't just be next week, right? That's a thing that is not easy, maybe to get an intuition about. But it's a it's a very powerful trick. It's a way that we handle unknowns at a small scale by bounding them in a larger scale. Yeah, I think like the thing about that whole concept that is most intriguing to me right now, or that I'm linking to like, concern of my own is in some ways it feels like when we when we take these like one and two week projects and we kind of stack them after each other and we always kind of have this like two or three days after each one to kind of like get reorganized before we start on the next one at a grand scale it feels like very inefficient sometimes because it feels like the metaphor that's like coming in my head is like imagine you have like a bunch of spheres that are like the size of a fist and you're kind of like sticking them all in a big bucket the amount of like volume of each one added to the amount of empty space than if you just put like one big sphere and counter the volume of that whole sphere rather than like the combined small ones because there's all these gaps between them right so it feels like in a lot of ways it'll be more efficient because like you can do two two-week projects in four weeks when you call it four weeks but we can't do two two-week projects in four weeks when we call them two two-week projects if that makes sense because that is exactly That is exactly why we do it. Because we get more efficiency from the self-organization than from the planned version. That's exactly what it is. Because for two people to say, actually, this thing I'm working on today is taking longer than I thought. I'm going to stay in my groove this afternoon and let's push that other thing off two days. That is more efficient because it's allowing for the information that's arising from the unknowns to be addressed in the scheduling the scheduling is getting customized according to the discovered information that's coming out of what was formerly opaque so the only fear that i still have which we talked a little bit about before but i have another question related to it is is just this risk of being at like the last day of the cycle and thinking you just have a couple loose ends to wrap up but each one takes a little bit longer than you think and that would have been no problem if you if it was like like it already feels to us and i don't know if this is true of base camp but like the last day or two of like a cycle feels like a little bit more crunch time ish still like it's not like people are working overtime or doing anything crazy like that but it is kind of like okay like there's these things on the checklist like you're a little bit more focused and a little bit more um things are a little bit more urgent if that makes sense yeah um and i i worry that when you're when you have that feeling for like the last four items on five checklists instead of one checklist That you're still gonna leave it all to one day and find yourself like this is actually not doable now like I guess the other question or the other way of thinking about this question is is there a risk that when you're batching all these projects together that none of them get like that bow tied on top of them until the very last day because they don't need bow tied on till the very last day So this is where We're at grad level shape up here. This is the subject. We're in like a deeper level with this question. And the answer is really like, this is what Hill charts are for. So what you want to imagine is that you've got, let's say you have a cycle with four projects in the cycle that are all more or less small appetites, one, two week projects, but there's no scheduling for how they get done inside of the, six weeks. What you're going to have is you're going to have four separate hill charts. And each hill chart is going to show you your risk of having last minute chaos. And what you do not want to see is you do not want to be in week four of six. And all four hill charts have important scopes on the uphill slope. I'm not even talking about that, though. I'm talking about things like the very last day we are going to write up like a little announcement blog post for like the new feature. And Steve has to design like a marketing card. And like, we think that's going to take him 15 minutes. But then it takes like three hours because we just can't find like the right way to present this thing visually in this tiny little card. Yeah, yeah. I'll expand a little bit more than we expect. Okay, two answers to that. first of all um there's a question of whether or not that should be bundled into the cycle or not okay so um i would much prefer to um to expand extend your cool down time and reserve capacity and cool down for stuff like that like marketing the stuff that got built and that way you can you can narrow the cycle time to just the building of the actual thing that's the first thing second thing is um even if you if you did continue to include it in the cycle um I think very often what happens is we actually, if we're not very rigorous, or rigorous isn't the word, if we're not very, I want a word stronger than disciplined about using the Hill chart, even create the marketing, put the card on the marketing site should actually be a scope that starts at the bottom of the hill to reflect our uncertainty about it. And very often what happens is we kind of tell ourselves, that's a known. And we kind of don't even consider to track it in that way. And we, in general, take an extremely conservative stance toward every single scope of work, which is that it's- Everything is high risk by default. Everything is unknown. Everything is unknown. And it's only a question of if it's a thin-tailed unknown or a fat-tailed unknown, but it's all unknown. And the basic intuition difference is like, look, if we If we had to, if somebody put a gun to our head and we had to release this marketing card tonight, like we could manage somehow. Sure. Right. And that's versus if you can't necessarily say that about the pros problem. You know what I mean? Like, it's like, no, you can't. I don't care how much time pressure you put on me. Like, I need to have the Eureka to get there. Right. That's the fundamental difference. But in both cases, there's an uphill. and if we're really declarative about the uphill part then then this is communicating to everybody hey this could actually take three hours you know so even still i still wonder like given like a call it like a four week cycle or something so it feels like a little more on our scale or something that we're bundling like three things into um does it make sense that like say the four projects that are stuck in there the three projects that are stuck in there all of them don't get finished until the last week you know what i mean the last three days of the last week or does it make sense sometimes and not even does it make sense but is there like pressures in the system that will encourage people to like if you've only got like four hours of work left on this thing and every everything is over the hill on every project say right and um all i have I'm not launching this for two more weeks, but literally all I have to do is write this little blog post and make this Twitter card. Should I just do that now? Because I think that intuition is like, that's so straightforward that I should go do some of the other little bit more complicated stuff, even if it is mostly figured out. But it just means that there's always a little bit of everything that's left until the very end instead of being able to just... cross it off the list and be like okay now i've only got two out of the three projects for this cycle left and that one i literally don't have to think about it all anymore like does that happen at base camp or not and what is your thinking around that um i i personally would err on the side of um uh if i would i would err on the side of like knock it out and get it done because um it feels great it feels great to finish something and you get a little bit of a, do you know this like energy push that you get when you finish and you get this like little like boost of like, all of a sudden there's a little more gas in the tank for the next thing because you don't feel like you have so much on your shoulders at the same time. I think that is something that can be, that's a good cultural value to be like, we prefer to not have inventory and inventory kind of smells. And so then if you're inside of this, let's say, four-week cycle, like you said, and then inside of that box, it's not just chaos, it's values and practices. So we're using the Hilt chart, we're prioritizing our unknowns, but we also have a value that we always prefer to ship as soon as possible. So if I really think that I'm two days away from something and I'm... And I'm not trying to play Tetris with someone else's availability. You know, like err on the side of just knocking that thing out. Yeah. Okay. That's what I was hoping there was a way to make it work that way. Because like the other element of that is like, forget like a team productivity perspective, just from like a pure marketing perspective, plus like a morale. kind of perspective when you finish something you want to be able to like celebrate that in public like right away while it's fresh right totally if everything's getting done at the end of the cycle we can't realistically say okay we're we've launched five new things today like that's just bad from a marketing perspective it's better if we're it's better if maybe we're quiet for three weeks but then like two things come out like two weeks before the cycle is over then like another thing comes up next week and No, I understand better where you're coming from. I took it for granted. And in the future, I would actually spell out more carefully that we don't want to ship everything all at once at the end. The fact that we allocate this four weeks for all these things to happen is just giving us optionality. It's just giving us wiggle room to deal with the unknowns and the scheduling of these people. But we still absolutely prefer in every chance to ship as early as possible. Absolutely. That's the best place to be. And we take advantage of that as much as we can. I think that basically answers a lot of my questions. Like for me, the big takeaways for me, again, is this like bundling of work for multiple reasons. One, to increase efficiency because now you're not baking in unnecessary sort of break time, I guess. Not that we don't want people to have like freedom to work on stuff, but it solves a lot of other problems that I was trying to solve in other ways, which was like, we gave this sort of break time at the end of each product. project because we wanted to make sure we had built in capacity for like Steve to help someone with the one design element of what is otherwise like a programming project. Or I wanted to be able to pull in Brad to like pair with me on my project when I'm working on something kind of nasty. But if we kind of bundle that all together, where we're as a team responsible for like a shared set of multiple sort of projects, whether they're related or not, it's, it's easier for me to just Talk to Brad and be like hey Brad let's pair on this like tomorrow because there's like a really nasty thing and see how far we get with it See if we can get this piece over the hill exactly then let's pair on like this other part of this other thing and then we'll come back to this kind of once we got all that figured out and You don't have to build in as much of these like break times because you just have that Controlled chaos like you're sort of talking about yes that plus this idea of Just because something is Given six weeks doesn't mean it has to take six weeks. Like I think like there was a thing that happened when I was at the workshop in Chicago where someone asked this question they were like what happens if the work gets done and sooner than six weeks and David was sitting at like the very back of the room like up in a chair and he just kind of shouted from there. He's like that never happened So that's kind of baked into like part of this like It here's the distinction though. It happens. That's a big batch project. Exactly. It happens all the time on small batch and it never happens on a big batch. Exactly. Right. And this, um, we've never really taken, we, I didn't try to really explain all these nuances of small batch. And I didn't appreciate when I was writing shape up how relevant this sort of small batchy world is to small, small teams, very small. Uh, yeah. So this is, uh, it's been hugely valuable for me i've learned a ton from this uh from from digging into this yeah i'm super excited about like my takeaways from this for sure so um again that's basically like all the stuff that i was trying to figure out and i think like we've been going for a bit over an hour and a half now which i think is a good probably amount of time for yep for this totally so dude thank you so much um i'm sure tomorrow when we go to put it into well monday when we go to put it into practice i'll realize i have no idea what i'm doing again and maybe i'll send you right now i feel great so thanks so much for taking the time to do this hopefully other people uh found this found this valuable i think this was like i mean from my perspective this has got to be like a one of the most interesting like deep dives into this that's been shared publicly that awesome so i can't wait to share it i think i think i think other people are gonna um i think some other people are gonna find it really valuable too Cool. Well, thanks again, dude. Really appreciate you taking the time. All right, man. We'll see you. Okay.

Ryan interviews Adam Wathan about how his team adopted Shape Up and answers questions.

Read Shape Up at https://basecamp.com/shapeup