How We Work: Kickoffs & Heartbeats – REWORK

Welcome to Rework, a podcast by 37signals about the better way to work and run your business. I'm your host, Kimberly Rhodes, and I'm joined as always by the co-founders of 37signals, Jason Fried, and David Heinemeier Hansen. Well, if you watched the behind-the-scenes podcast episode we did several weeks ago, I mentioned that some of our most popular episodes are ones that go into the details of how we work at 37signals. So I thought I'd bring you just one of those episodes today. We're talking about... a process, a ritual that we have every six weeks here at the company called Kickoffs and Heartbeats. It is a write-up that our department heads do, and we're going to do a deep dive into them today. Before we get started with that, guys, when did this start? I'm assuming you didn't need to do this whole formal write-up process when the company was small, just three to five people. Do you remember when it actually started? Yeah, it probably started around the time we started to really formalize ShapeUp. the shape-up process because over the years we tried a bunch of different things i mean way back in the day we just like built stuff there's no cycles there's no deadline we just like made the thing as fast as we could with like three people And then as we grew, we had to institute some more process. And there was a time when we would let things go as long as they took. And there was also times when we'd say, well, maybe three months is enough time. And we didn't formalize it. So there weren't this tight cadence of check-ins, basically. I think around the time we did the six-week cycle thing is when the kickoffs and heartbeats really were born. Because when you have a tight cadence like that, and a regular cadence, something's predictable, you can hook on. different things to that cadence essentially. So at the end of something, you can do something. At the beginning of something, you can do something. And so it turns out that heartbeats are essentially the review of what the team did over the past six weeks. And the kickoff is what the team is expected to do over the next six weeks. And so it just, it kind of made sense to fill it in from both perspectives, both sides. Okay, perfect. So let's kind of go into detail about how these work. At the beginning of a cycle, department heads are writing what we're calling a kickoff. And what does that kind of contain? Like what goes inside of it for someone who's listening who might want to implement something like this? So the kickoff is a description of the types of projects and most importantly, the appetite often that those projects have in the next six week cycle. So for example, on product, if we announce that we are going to be working on four different things it'll have who's going to be working on it and how long do we i was going to say expect that's actually exactly the opposite of that how long do we dedicate for that project to be some projects are full cycle that means we will give them the entire six weeks that's usually the case with big projects big new features we will assign a team to work on that for the six weeks and that becomes the ultimate cutoff that's why we have the cycles be six weeks in the first place because that is the duration during which we think we can deliver almost anything as it pertains to a single feature it's the constraint that keeps us from just going on and on and on and longer and longer but there are also features or things we want to do that don't take six weeks. And therefore, you might be able to do two of them, or you might even be able to do three or four or five of them in a single cycle. And the kickoff kind of just spells out. Here is those things, how long we're giving them, not how long we expect them to take, how long we're giving them, what are they worth from our perspective? This is straight out of ShapeUp, straight out of the idea of running with budgets instead of estimates, which really is key to this whole thing. that if you have kickoffs that are describing the next six weeks and those kickoffs are based on estimates well that's going to fail because your estimates are going to fail because estimates always fail there is not a scenario where you're just going to be right about exactly how long a collection of projects are going to take that's why we flip it around we don't expect to be right about a specific estimate of a given project we expect a team to be able to hit a budget if they're giving given free reigns on how to get there on what the scope is going to be so that kickoff for let's say the product team is going to have those five different projects and it's going to describe those projects in about a paragraph like here's the thing we're trying to do this is a rough idle outline of what the concept is in part to invite others who might have input on that to be able to interact like oh we're gonna work on this oh interesting uh actually i had i just heard from a customer this one thing i should pass that on to the team or i know that's a tricky part of the code i had to work on that two cycles ago let me um reach out and we can try to figure that out and i think that's also what's key about the kickoff the kickoff is for the entire company Sometimes companies within product development, for example, will kind of have their own plans and they're related to just that department and they will keep it inside themselves. And then occasionally, maybe they'll say, we did something. We put out the kickoff to the entire company. Everyone gets to read it. Everyone gets to comment on it. Everyone gets to follow up on it. That is a really powerful way of combating this natural notion that creeps into every company as soon as it's larger than, let's say, 10 people. What are we actually working on? What are they working on over there? What are they working on over here? I don't know. The kickoff is our attempt to essentially let everyone inside the company know what everyone else is doing inside of the company. And that... models very well to the things we do on a weekly basis where we have what have you worked on today what are you going to work on this week that's kind of the miniature scale but the kickoff and then the heartbeat is the macro scale that's kind of i'm not following up every day with what ops operations team is doing but every six weeks i'll get sort of the list of things that they're going to try to pursue so It's a bunch of things at the same time. It's autonomy for the team in terms of setting their own direction. Jason or I will often be part of that discussion. But at this point, most teams have a high degree of autonomy in setting what the kickoff should include. What are the projects we should work on? Distributing that information to the entire team. And then building a kind of automatic sense of responsibility. that these are the things that we said we were going to do. Often you won't get to everything, but you should generally speaking, get better and better at getting to the things you say you're going to work on. And I think at this point, we've gotten really good at that. If you look at the kickoffs we've had for years now, and you then look at the heartbeats, that's kind of the other side of it. You do the kickoff. That's what we intend to do. You do the heartbeat. That's what we actually did. There's a really nice degree of overlap, a degree of overlap I have never seen in an estimate-driven organization. Okay, on that note of autonomy, tell me this, because I'm curious as leaders of the organization where or when you're having your input on what should go in a department's kickoff. Like, I'm sure there's times, like Jason, you're like, I want us to focus on this, or David, we're going to focus on this now. Where does that happen in the process before a department head is sending out their write-up to the company? It depends on our purview, perhaps. I work with Brian. Brian typically writes up the heartbeats and kickoff for product because he sort of broadly manages the product on Basecamp and Hayside. But I'll work with him on the ideas that might go into the kickoff, so into the shaped-up cycle projects. He's ultimately going to pick them, but like here's something I think could be valuable. And there's some cases, for example, I'll give you something very real. So David and I were catching up a few days prior to a cycle starting. And we had this idea to do like a basically a free version of Basecamp. So Basecamp currently is not free. There's two paid plans. You get to try it for free, but you have to end up on one of the paid plans. And we've for a long time had a free plan in the early days when we first launched Basecamp 2004, we had a free plan, we kind of kicked off the whole freemium thing. Then we didn't have it for a while, then we had one, then we didn't have one, then we had Basecamp personally, anyway, had this idea to do it again. And this was a few days before kickoff. So like most of the projects were already defined, but we felt like this was one of those cases where we really want to do this for the business. This seems like a business move that's higher than just which features make it in this cycle. Those features can wait in a way that we didn't feel like this could and that does not happen that often. So I told Brian like, hey, Brian, we want to get this in. So we've been working on the last couple days to kind of define some of this. There's a hand, it sounds simple, but there's actually a bunch of edge cases you have to deal with and consider and plan out before things go too far. But we don't want to do that too often. You don't want to jump in at the last minute and change plans very often. And you also don't want to tell teams what to do very often because then they lose their own muscle, their muscle atrophies, basically. They can't make this up for themselves moving forward. So it's a delicate balance. But like, for example, I don't even know support reports to me. I don't tell them what to do for the next cycle, although I had some suggestions this time as to things I think that Chase, who's the head of support, could do a little bit differently. And so I'll make that suggestion whether or not that shows up this time or next time or never. I don't know. But so it's a give and take. It's not a it's not a there's no like real rules here. It's a bit of an art and figuring out when it's important to step in, step out, push for something and not push for something, sort of take over or really give up the reins. It's just it's just a feeling. It's a feeling based on a bunch of different things that are going on in the organization at a given time. The technique I've been using with some of the teams that I manage, for example, operations, technical operations, and our SIP team, our security infrastructure and performance team, is that we keep a card table with essentially the ideas of what to work on next. That is not the same thing as sort of an issue tracker. It's not this thing that's being put on the table has to be solved right now and pull some other things off the table right now. In fact, if anything, it's the opposite. It's a parking garage. for ideas where you're not going to take them back out until it is time for discussing what should go into the next kickoff so what's so nice about that parking garage is very often i will get the instinct i really want to see something happen and i know the process is you know what i'm going to put it on the card table and we will pull that card back out again when it's time to decide what to work on next and what happens quite often is i'll be so excited about the thing i think we should work on the minute i record it and then three weeks later when it's time to do the kickoff do you know what i can see that there are some other things that perhaps have been on the card table for longer that's more important because my sort of initial reaction of enthusiasm had had a chance to to dampen a little bit but it allows us this this space where we can capture ideas if you will without acting on them and i think if if anything that is the prime virtue of the cycle to protect the time for six weeks at a time for someone to simply work on what you've decided on you get another chance to decide again we do six of these cycles every year that means we do six kickoffs and we do six heartbeats for each department so there are plenty of opportunities for you to as we said with jason um say we want a free plan so that's gonna that's gonna fit in now we had an opportunity to do it But if we came two weeks into the cycle and said, oh, no, actually, we've got to really change up our priorities. We should do the free plan now. I mean, we could. We get to tell anyone what to do at any time. That's the virtue of owning a company. But like, would that be good? No, it would not. It would not be good if we did that on a regular basis. Perhaps occasionally that's needed, but quite often it's not. So it's just as much a process for Jason and I as people who get to tell other people what to do. to restrain ourselves so that we don't act on every single impulse that comes in and just continuously pulling people off one project onto another project off that project onto the other part because that's how you get nothing done that is how you get nothing done by constantly trying to multitask and constantly trying to schedule any idea however great it might be that pops into your head as soon as it pops into your head it's actually better to just sit with it for a second and to let the team finish what's on their plate first to give them the sense of accomplishment that they're finishing things in the first place i've talked to so many people who work for bosses where they never get that sense of are we actually shipping something it feels like we start five different things four of them are left half done or not finished at all and then we move on to something new and it's hard to get the sense of satisfaction that you're actually moving forward because of course you're not if your plate is full of half finished stuff that never actually ships and makes it out to customers you can't get that satisfaction from a job well done a job delivered a job shipped Okay, Jason, you mentioned support. So I want to go into kickoffs for departments like support, like ops, that have these kind of ongoing functions. We get a lot of questions from customers who are like, how do we work in these cycles and do these kickoffs when we're in accounting or finance? And it's just kind of ongoing work. Kind of tell us what those kind of kickoffs look like. For sure. There's different teams with different kinds of work. So some work is very much... you know, sort of essentially plan based and where you can set it out ahead of time. The other work is reactive work, which is what oftentimes SIP, which is security infrastructure performance or ops, technical operations or support could be. But they often have some sort of ongoing project going on or some project that can be scoped to six weeks. And they'll talk about those things. They'll also talk about some ongoing things. And they might even talk about in the, especially in the heartbeat. some of the reactive work or a lot of the reactive work that they ended up doing like sometimes op will post a heartbeat and they'll take a screenshot of all the to-do's they completed over the last six weeks and it's like hundreds and It's important to note that when we go into a new cycle and write up a kickoff There's never a to-do or a task in these kickoffs Kickoffs are not assigned work at that level. They are big picture ideas about what we're going to be working on. And then the team decides all the little bits that have to be done. So they get to decide how they're going to approach the work, what they're going to do. Ops, sometimes things are thrown at them because like something goes down or there's a big change or we need more storage or whatever it might be, performance issues, denial of service attack. Could be a million different things that could happen or happen and they need to react. So they're keeping track of what they did. and they're sharing that. So I would say that their heartbeats are often a bit more informative and interesting to look at from those kinds of teams because they don't know what the next six weeks are always going to look like, even though sometimes there are some scoped projects that are going to happen. That also reflects the fact that on some teams, like operations, from the outset, we don't try to schedule everyone. We don't try to schedule in the kickoff, here is how you can be busy for the next six weeks for 40 hours a week because that's going to clash with the reality of the volume of reactive work that a team like ops deals with versus on product where you could say do you know what it's not unreasonable to schedule this team for say 80 capacity even on product there are things that pop up so you should not schedule anyone anywhere for 100 if you schedule something for 100 you have zero percent flexibility you have zero percent capacity to adapt to change in the reactive work that comes out but some teams have like 50 50. That's often how we think about things on SIP or Ops, that half of the time even is dedicated to reactive work. And there's another half that is dedicated to work we can plan out that we can include in the kickoff. So having that sense, and this is something you develop over time and it changes. And sometimes the cycle is more full of reactive work and other times the cycle is less full of reactive work. But on a moving average, you get a sense for what level of ambition is realistic. So on ops, for example, we have, I think, nine people right now. We think like, you know what? I should think of major projects that move things forward as, let's say, four, four full-time people. The other half of it, the other five are going to be dedicated to all the reactive work that just comes up as a natural consequence. And also, by the way, will take precedence. We have all these things we want to move forward. We want to improve our infrastructure and improve our setup. And it's really important. But if the servers are down, it doesn't really matter. It's very clear what will be put aside and what will get priority when you deal with teams like that. So I think that's a big part of it. But as Jason says, the heartbeat is actually quite similar in some regards, that it's a description of what happened over the past six weeks. Some of that description is going to match what was in the kickoff for all teams. And then for some teams, reactive heavy teams, they're going to have a bunch of stuff up there that they had no idea was going to be in the heartbeat at the start of the cycle. But it still gives you this sense of, oh, I know what's going on here. I know what people worked on last cycle. I know what they're going to work on. And it just, it gives a calm and it vastly reduces the need as a manager. to constantly check in and i'll just also add to this i feel like when i read the heartbeats from departments it also seems like it's an opportunity to kind of shout out people on the team because you're specifically saying this person worked on this and highlighting the work that they've done which i don't know that we would always have that opportunity if there wasn't this kind of formal write-up process yeah it's a good point i'll just say that the heartbeats tend to um Have these more more shout outs because it's very specific what was actually done by who ahead of time We don't always know who's gonna do what even though there might be a programmer and designer on a project There's there's like things that happen over that cycle that were particularly interesting or surprises or whatever and you can call people out in a good way On that and really highlight them and give them sort of kudos Which is which is really nice to see especially on things like on call and ops and these kinds of in some cases, temporary teams or permanent teams where there's just so much reactive work and you can go, wow, so-and-so really dealt with that and really dealt with that and really nailed that. And that was a huge help for them to step in here. And you wouldn't know this otherwise unless you were part of those teams. And this is one of the beauties of these write-ups is that... the rest of the company gets exposed to all the work that's happening inside of an organization. And this is really important because it helps to build and layer in trust and recognition of what other people are doing. Because there's something that happens in companies when you're like, I'm busting my ass, but what's anyone else doing around here? And when that happens, and this happens a lot in organizations, resentment starts to pile up and people start to feel like they're just pulling too much weight. And so when you go, oh, I think I'm doing a lot, but oh my, look at what X, Y, and Z is doing or look at what they're doing and wow, they really stepped up and that's not their job, but they came in and helped here. You start to hold people in a higher regard almost by default because you see all the work that's happening across the group, especially in groups that you're not part of. And I think that level of celebration is really important too. rest of the company everyone gets to see what this team has worked on but it's almost just as important for the team itself because it is often quite difficult to appreciate the accumulative value you've delivered over six weeks you might be working on some reactive work on a single day and you're like okay i didn't feel like i get that much done or maybe even over a whole week and you go like i i wish i've gotten more done but if you zoom out and you look at six weeks it's very frequent you'll go like oh damn That's a lot. That was worthwhile. That was not six weeks wasted. Even if the individual day or even the individual week felt a little weak, the whole six weeks suddenly feel very meaningful. They feel like there's some gravitas here. There's some weight. We actually did move a bunch of things forward. We dealt with a bunch of issues that came up, and I get to appreciate my own work. through that lens. And I think that's often the value of all of these kinds of check-ins. They are for other people to know what you're doing for sure, but they're also for you. It's a way to keep a journal and a journal that long time span where you can really appreciate that accumulative value that's there. And then you can lean back and go, this was a good cycle. I actually did something, even though you had these occasional moments where you're like, I wish I'd done this or that or the other thing. And if that's not true, it's just as much of a benefit, right? Like if you are able to go six weeks and you feel like at the end of those six weeks, like what was I doing? Like pulling my own weight in comparison to everyone else? Like sometimes that does lead to a conversation of there's something's not right here. And what we've seen repeatedly is. When something's not right in the role that someone's in or the configuration of the team, it becomes difficult to write the daily check-ins. It becomes difficult to write at the beginning of the week, what are you going to work on? It becomes difficult to summarize it in a meaningful way that feels weighty enough at the end of six weeks. And that's a really good prompt to make a change. something needs to be reconfigured, maybe someone needs to be moved over to another place. There's something that needs to change when these things are hard to do. And I think doing that six times a year is a healthy cadence of that. Okay, I've been over here nodding as you've been talking, David, because as an employee, I feel exactly how you're saying. At the end of each six weeks, I'm compiling a list for Brian, head of product. Like, here's what I worked on to contribute to the team product that you're going to write up. And every time I do it, I'm always like, oh gosh, did I do enough? And as I'm making that list, I'm like, okay, this is a lot. And you don't really think about it until you're forced to compile it and put it in one document, which, I mean, exactly to your point, I think it's helpful for the employee as well as it is to the entire company. Before we wrap up, anything else about heartbeats or kickoffs you think someone needs to know? Someone who might be on the fence if this is something that could work for them? I mean, just like anything else, you don't have to adopt this all the way. Just try it next time. And also, typically, someone who's listening to this might go, we do that. We do that. We have these status meetings and weekly things and stuff. And maybe you do, maybe you don't. Maybe you do a different version of it, maybe you don't. But try writing it up instead and one of the real advantages of writing it up and not like saying it out loud and then transcribing it but writing it up in a way that it's going to be delivered only through the write-up is that you build this institutional knowledge and history so when new employees come into the organization they can read up at their own pace on what the company's been doing over the last year. That is a gift to new people. It's not a gift, in fact it's a slog. to say, hey, go read these AI-generated transcripts or recordings of these Zoom calls where we went over the stuff, you know, where there's like ahs and ums and gaps and sort of nothing's really presented very clearly. That sucks. Who wants to do that? Who's going to watch 24 hours of footage like that, you know? It's one thing to binge watch like a great show. That is not a great show, I can promise you. It's just a pretty crappy show. But to read something that people wrote with the intention to be read. clearly, concisely, tightly. It's a wonderful gift to the rest of the organization. And I think that's how I would begin to look at this, not as a chore, but as a gift. Well, perfect. With that, we're going to wrap it up. Rework is a production of 37 Signals. You can find show notes and transcripts on our website at 37signals.com slash podcast. Full video episodes are on YouTube and Twitter. And if you have a question for Jason or David about a better way to work or run your business, Leave us a voicemail or send us a text to 708-628-7850 and we just might answer your question on an upcoming show.

37signals works in 6-week cycles, which begin with a Kickoff and wrap up with a Heartbeat. In this week’s REWORK podcast, co-founders Jason Fried and David Heinemeier Hansson break down the purpose and benefits of the Kickoff and Heartbeat documents and share tips for implementing this process across an organization. 

*Key Takeaways*

00:40 - When 37signals started using Kickoffs and Heartbeats

02:13 - Details of the Kickoff write-up process

07:34 - How much input Jason and David have in the Kickoff

13:43 - What Kickoffs & Heartbeats look like for departments with ongoing work

17:37 - The Heartbeats as an opportunity to highlight and celebrate the work of individual employees and team

22:50 - The benefits of writing up work summaries for institutional history

*Links & Resources*

Shape Up – https://basecamp.com/books/shapeup

Books by 37signals - https://37signals.com/books

Sign up for a 30-day free trial at Basecamp.com 

Once. com – https://once.com/

Campfire – https://once.com/campfire

HEY – https://www.hey.com/

The REWORK podcast – https://37signals.com/podcast/


*Let's be social!*
Twitter: https://x.com/37signals
Tiktok: https://www.tiktok.com/@37signalshq
Instagram: https://www.instagram.com/37signalshq/
Newsletter: https://www.basecamp.com/newsletter

Rework is a production of 37signals. You can find show notes and transcripts on our website. Full video episodes are available on YouTube and X.

If you have a question for Jason or David about a better way to work and run your business, leave us a voicemail at 708-628-7850 or email, and we might answer it on a future episode.