SEASON 2 - EPISODE 121 - SEPTEMBER 4, 2024

How We Work: Kickoffs & Heartbeats

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.

Watch the full video episode on YouTube

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

Transcript

Kimberly (00:00): 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 Hansson. 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’s a writeup 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 writeup process when the company was small, just three to five people. Do you remember when it actually started?

Jason (00:50): It probably started around the time we started to really formalize Shape Up, the Shape up process because over the years we tried a bunch of different things. I mean, way back in the day we just built stuff. There’s no cycles, there was no deadline. We just 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 in 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 kind of made sense to fill it in from both perspectives, both sides.

Kimberly (01:59): 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? What goes inside of it for someone who’s listening who might want to implement something like this?

David (02:13): 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.

(03:08): 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 Shape Up, the 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.

(03:55): There is not a scenario where you’re just going to be right about exactly how long a collection of projects is 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 reins 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. Here’s the thing we’re trying to do. This is a rough 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 going to work on this. Oh, interesting. Actually I just heard from a customer this one thing.

(04:42): 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 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, and 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?

(05:30): 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. I’m not following up every day with what Ops, the 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 and 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.

(06:40): 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.

Kimberly (07:09): 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, 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 writeup to the company?

Jason (07:34): 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 product on Basecamp and HEY side, 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 here’s something I think could be valuable, and there’s some cases, for example, I’ll give you something very real. We’re about to start a cycle and David and I have a conversation. We had this idea to do 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.

(08:22): 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 personal anyway, had this idea to do it again, and this was a few days before Kickoff, so 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 of days to define some of the, 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.

(09:04): 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. Then they lose, their muscle atrophies basically. They can’t make this up for themselves moving forward. So it’s a delicate balance. But for example, I don’t, even though 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. It’s a give and take. There’s no 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 a feeling. It’s a feeling based on a bunch of different things that are going on in the organization at a given time.

David (09:54): 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 that very often I will get the instinct, I really want to see something happen. And I know the process is, do you know what?

(10:41): 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 a chance to dampen a little bit. But it allows us this space where we can capture ideas, if you will, without acting on them. And I think 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.

(11:29): 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, say, we want a free plan, so that’s going to fit in now, we had an opportunity to do it, but if we came two weeks into the cycle and said, oh, now actually we 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 the virtue of owning a company, but 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.

(12:17): It’s 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 project 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.

Kimberly (13:23): 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.

Jason (13:44): For sure. There’s different teams with different kinds of work. So some work is very much essentially plan based and where you can set it out ahead of time. And 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, especially in the Heartbeat, some of the reactive work or a lot of the reactive work that they ended up doing. Sometimes Ops will post a Heartbeat and they’ll take a screenshot of all the to-dos they completed over the last six weeks.

Kimberly (14:17): It’s crazy.

Jason (14:17): 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.

(14:27): 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 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. They’re keeping track of what they did and they’re sharing that. 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.

David (15:08): 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 a hundred percent. If you schedule something for a hundred percent, you have 0% flexibility, you have 0% capacity to adapt to change in the reactive work that comes on. 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.

(16:05): 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, you know what I should think of major projects to 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.

(16:50): 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 gives a calm and it vastly reduces the need as a manager to constantly check in.

Kimberly (17:38): 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 writeup process.

Jason (17:57): Yeah, it’s a good point. The Heartbeats tend to have these more shoutouts because it’s very specific what was actually done by who. Ahead of time, we don’t always know who’s going to do what, even though there might be a programmer and a designer on a project, there’s 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 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 would not know this otherwise unless you were part of those teams.

(18:41): 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 ’cause 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, but 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 a group, especially in groups that you’re not part of.

David (19:29): And I think that level of celebration is really important to the 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 cumulative 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 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 at 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.

(20:21): 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 a cumulative 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.

(20:59): And if that’s not true, it’s just as much of a benefit. If you are able to go six weeks and you feel like at the end of those six weeks, what was I doing? Was I pulling my own weight in comparison to everyone else? Sometimes that does lead to a conversation of there’s something’s not right here. 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 or 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.

Kimberly (21:59): 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?

Jason (22:41): I mean, just like anything else, just 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 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 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 writeup 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…

(23:28): 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 where there’s ahs and ums and gaps and nothing’s really presented very clearly. That sucks. Who wants to do that? Who’s going to watch 24 hours of footage like that? 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.

Kimberly (24:05): Well, perfect. With that, we’re going to wrap it up. Rework is a production of 37signals. You can find show notes and transcripts on our website at 37signals.com/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 7 0 8 6 2 8 7 8 5 0 and we just might answer your question on an upcoming show.