SEASON 2 - EPISODE 0105 - APRIL 17, 2024

Disagree and Commit

“Consensus is cozy, but broad agreement is not our aim. The right decision is. Which is why we take the time to think, debate, persuade, listen and reconsider and then, someone, decides. If you disagree, that’s fine, but once the decision is made, it’s time to commit and support it completely.”

Tune in as Kimberly leads a chat with Jason Fried and David Heinemeier Hansson, co-founders of 37signals, about the concept of Disagree and Commit. Once a decision is made, everyone should be in 100% — no looking back.

Watch the full video episode on YouTube

Key Takeaways

01:01 - Breaking down how Disagree and Commit operates.
02:17 - Identifying the most suitable person to make the final decision based on the circumstance.
07:40 - Embracing the “manager of one” concept, empowering individuals to decide independently with reasonable supervision.
09:33 - Acknowledging that delegating decisions doesn’t compromise the emphasis on quality.
14:04 - Always keeping the door open to revisit and tweak things.
15:44 - Granting capable individuals the freedom to make mistakes, alongside providing guidance for improvement.
20:35 - Viewing hiring not just as an evaluation of current abilities but also considering potential growth opportunities.

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 Free and David Heinemeier Hansson. Well, if you’ve been to the 37signals.com website at all or you’ve read, it doesn’t have to be crazy at work. You’ve heard this concept of disagree and commit, it is one of the principles or signals that the company applies. You can find those on 37signals.com, but let’s talk about it. Disagree and commit. Let me read it as one of the signals which is consensus is cozy, but broad agreement is not our aim. The right decision is, which is why we take the time to think, debate, persuade, listen and reconsider, and then someone decides. If you disagree, that’s fine, but once the decision is made, it’s time to commit and support it completely. You guys, let’s talk about this. Disagree and commit. Who wants to start?

Jason (01:01): Well, we got this one from Bezos, right? Wasn’t this in some, I think originally in a shareholder’s letter actually is where we first read about it, but I don’t know where he got it from. I’m not sure if it was his thing or he got it from someone else or whatever it was, but it’s a great general approach to debates. You lay it all out, you put it all out there, and then someone’s got to make a call. I’m kind of summarizing it here, but basically someone has to make a call and then when someone makes a call, even if you don’t agree with the call, once the call has been made, you get in line and you make that thing happen. I think the way Jeff described it is he’s like, I’ll sometimes really strongly disagree, but a decision will be made then I’m rooting for this.

(01:44): I’m rooting for myself to be wrong. At that point, once the decision’s made, you’ve got to get behind it. You can’t have backstabbing, you can’t have sabotage, and you can’t have someone who’s just like, I’m sorry, I don’t agree, I’m not doing it. I mean, you can have that, but that’s just going to be a total mess. So it’s important to recognize that not everything’s going to go your way and you lay your case out and you make your point and you persuade as best you can, but at some point a decision is going to be made and you’ve got to get in line and make it happen and celebrate it and fight for it and work for it just like everybody else,

David (02:15): And it’s actually liberating. Once you’ve internalized this concept, you realize that certain decisions are up to certain individuals to make and you will. I will often be making a strong case to Jason, for example, about some point or another, but if that decision is within the sphere of product management, I know that Jason’s going to make the fine call and that’s wonderful. It’s really liberating to just be able to walk into a room, deliver the best arguments that I can summon in my mind at the moment and then go like I’ve done my part. Now it’s up to, in this case Jason, to decide what we’re going to do on this part, and then there’ll be other technical decisions where I will sit in that chair and go, let’s hear all the arguments, but ultimately I’m going to make a call. I think it really releases people from this idea that we’re going to wrestle until someone taps out, until someone gives up because that concept that you will just keep going until we’re all on the same page is just a death march of exhaustion.

(03:24): Whoever can speak the longest, whoever can argue the longest is suddenly in a position to make the final call. That’s not the right way to go. You should actually, before even beginning the discussion, be clear on who’s making the call, who’s on the line here to own the decision because this is the flip side, the release of authority, the release of responsibility is liberating, but it also has to be acknowledged on the other side. If Jason is making the call on some product direction or another and it goes sideways, that’s on Jason, right? It’s David’s fault. It’s always David’s fault. We all do things that sort of goes sideways from time or another, but this is the burden of leadership. The burden of leadership is if you make the call, it is your call and your quality as a leader is measured on the long-term, moving average on your decision-making sort of effectiveness, and I think a lot of people will actually find that they don’t necessarily want that burden or responsibility all the time in all the cases because it truly is a consensus decision now we’re all in right now, it’s on all of us if it fails.

(04:48): And what I see that as is the comparison to, there was a wonderful paper from the seventies called the Tyranny of Structurelessness, I think it was called, which is essentially this idea that if we’re all just sitting kumbaya in a circle and no one is a leader, no one is responsible for making these decisions, do you know what? A hierarchy will emerge. It’ll be an implicit hierarchy. We will not have spelled out that this person is responsible. It’ll just be sort of what emerges and it sucks. It totally sucks. What is far nicer is to have an explicit hierarchy, have an explicit person who has to make the call and who has to make the decision and disagree and commit really gets both the best of both of those things. There’s a person who’s in charge, that person will listen to everyone who has a opportunity or a seat at the table to influence that decision.

(05:42): But then once we go like, all right, this is the way we go. Awesome. Let’s rock a final point here. We had this exact case with an idea that Jason had for pricing called three free, which we ran a ago or a little over a year ago. We started this where Jason wanted to give Basecamp away for up to three users for up to a year. I thought that sounded like a terrible idea. I thought it sounded very risky, like you were not going to know until a year later whether it was going to work or not. I could totally see why you would pursue that decision. Hey, more people are going to sign up. There’s going to be sort of excitement, but oh man, giving the product away for a year, that seemed highly risky, but Jason made the call to this is what we’re going to do. We did it, and I was all like, all right, let’s bang the drums. Let’s get people excited about it. Let’s get the maximum out of this. And then of course the results come in a year plus later and it worked. I was like, awesome, fantastic. Love being wrong, love being wrong about those kinds of things. You disagree and commit on something like that and then the business prospers because you are wrong and this decision may move forward. So

Kimberly (06:51): Yeah, that’s perfect. I was going to ask you for a real world example where you guys have disagreed and commit, so that is great. I am curious about the 37signals, philosophies of being a manager of one and how that kind of goes along with this because what I’ve seen that I think is interesting in this environment that I haven’t seen in other places because employees have so much autonomy and kind of power over their own work, a lot of times I’m seeing even on the designer side, someone might say, oh, have you tried this? Or I might like it better if you did this. And really the designer is the one who goes, yeah, no, this is what I’m going to do. Or they’re really able to take control of their own work. I don’t know if that’s intentional or just an observation that I’ve had, but I’m curious about how that looks in terms of the manager of one kind of philosophy.

Jason (07:38): Yeah, I think we want as many people to make their own decisions as possible about their own work. There are decisions that are higher up that are more directional. Organizationally, what new product are we making? Everyone can’t just decide to make a new product all the time. So that kind of stuff, big picture, that’s my responsibility. David’s responsibility, Elaine’s responsibility, other people’s responsibility depending on what the decision is. But as far as the actual work goes, we’d like more people to make their own decisions. Now, that’s not to say that if we see something that we think is way off base or just something that wasn’t considered or something we think is let’s say too complicated for what it’s doing or too much work’s being put in to solve something that should be simpler, we’re going to speak up and say that. And look, the truth is there is an override here.

(08:25): I mean, we can override decisions, obviously that’s just the hierarchy, that’s how it goes. But that’s not the aim. I don’t want to do that. I don’t think that’s a good record for the company to have a bunch of things overridden at some point then people stop making their own mind up. They go, well, he’s going to override anyway. The hell does it matter? Or he’ll make the call anyway, what does it matter? You don’t want that. That’s helplessness. That’s learned helplessness, that’s giving up, that’s giving in. That’s just not really what we want here. So in fact, I’ve become, this is something I’ve changed on over the years. I used to be a little bit more like I want to look at everything before it ship everything before it ships and give my point of view. And I look at most things before they ship depending on the criticality of them. But many things, I just sort of trust the people and it’s going to be good. And sometimes it’s not as good as I would’ve liked it, and other times it’s way better than I would’ve made it. At the end of the day, I don’t want there to have to be a line out the door where everyone has to run their decisions by me before anything happens. That’s a bottleneck. That’s not healthy, it’s not good. So that’s at least my point of view on that approach.

David (09:33): I was about to say struggled with it. I don’t think that’s the right word because I think it is a continuum. I’ve been sort of swinging around it. How do you at one point deal with the fact that in my case, anything technical that goes out the door, the buck stop here, whether I actually sign off on it or not, it’s still my responsibility if it’s not right. So try to encapsulate that in the sense of hold the line, holding the line on quality that we have a certain bar that we’re aiming for, but at the same time, very receptive to the idea that Jason has, that if you just line people up and everything has to get that sign off, you’re actually infantilizing people and you’re robbing them of their own autonomy and power to make those decisions. And if you never let them make the decisions, how are they going to get better at it?

(10:23): So I’ve tried to pair that with a sense of, do you know what? Sometimes it’s okay to backtrack. I don’t review all the pull requests that go into the code base, but occasionally I will scan through it and if I find something that’s not right, materially not right, I will go, do you know what? That’s not okay, we got to redo it. So you shipped it, it got merged, but we’re still going to revisit it. We’re still going to go back and we’re still going to fix it. And it has to be both things at the same time to get the advantages of people making their own decisions and not just people making their own decisions, but making the decisions as close to the work as possible. Someone who’s spending four weeks developing this feature and really is in it, they have a lot of context, a lot of knowledge about all the specific trade-offs, and sometimes I realize I Walsh in and I don’t have that context and I go like, oh, this looks simple.

(11:20): It should be simple. And I try making simple and it’s like, oh, this is why you made the decision. It did because it’s not actually that simple. And if I’d been there for four weeks, I’d realize that. So you got to have that and then you also got to have the ultimate responsibility for quality. That really to me is one of those things where we’re not going to give there anything we ship has to be good. It does not have to be perfect. It doesn’t have to be all lineup, but it’s got to be good. And especially when it comes to code, my bar is I to actually smile when I look at this piece of code again in three years. In three years when we go back to revisit this feature because we want to extend it or do something else, I should be able to look at that code and go like, yeah, nice, awesome, great, I’m looking forward to working with this.

(12:09): That’s not the norm. The norm at most companies and most code bases is that when you go back and look at something that was written three years ago or five years ago, you go it’s, it’s a hassle, it’s legacy, it’s all those things. And why is it those things? Because people were inclined to cut corners at some point to get something out the door and we’re not going to do that. I mean, we’ve been around for 20 years. I got to be able to look at this code again in three or five years and it’s worth that investment upfront. So I think holding, having the capacity to hold both thoughts in your head at the same time, that’s really what this is about. Quality is really important. Ultimately at the end of the day on technical decisions, I hold the line on that on product decisions and design.

(12:59): Jason holds the line on that. We are ultimately responsible for anything that goes out the door and we don’t have to micromanage everything. We don’t have to sign off on everything. We can trust people to ship something. And if it’s really bad, which occasionally it is bad, I mean I’m talking about a piece of code that doesn’t make me smile. We can go back and we can fix it. And having that leeway, that’s a good place to go and struggling with both of those things, don’t think you can resolve it. This is ultimately a full game of trade-offs. I want quality, but I also want empowering individuals who ship their own stuff and I want them to be able to learn and I want more individuals to be making more decisions. This goes directly to our whole spiel and decisions. How do you get better making decisions? You make a lot of decisions. You realize that most decisions are temporary, that most code that gets merged. I can show up a month later and go like, I don’t like this. We can just redo it then. And 90% of the code that went in in that duration was fine and I didn’t have any notes on. So yeah, do it both at the same time.

Jason (14:03): It’s a great point actually. I’m glad you brought this up. This is the same thing on design, which sometimes something will ship and maybe I even glanced at it before it shipped and I was sort of like, alright. And then it ships and the product for real. And since we use our own stuff, we run into it in the real world in real scenarios and you’re like, you know what? This is wordy or this is weird. I don’t really get this or this seems complicated, or why are we explaining this in three sentences when we can find five words to get it right? And so we’ll go back and tweak that. And the nice thing is it doesn’t take long to tweak some of these things and this is not a rollback. We’re not like pull the cord and roll the whole thing back. It’s like it’s fine.

(14:40): What’s out there is okay, but we do need to make this better right now. And the nice thing about shipping things is that for some reason it just accelerates the clarity of quality. It just does. You can look at something before it ships and be like, yeah, and then it ships and for some reason, I don’t know what it is, but you’re like, wow, I really can see what’s wrong with this now or what’s really right with this now. And again, the good news is we can revisit these things quickly, usually come up with something kind of fast and better and make it happen. And David says it’s not like the whole thing. It’s typically like 10% or 5% or a sentence or a button or whatever, or a placement of something like this is too far away from this. These things are related but it’s too far away visually people aren’t going to connect the dots here. How do we make this more obvious? It’s like, well, we could do that. Okay, let’s just do that. So someone does it in 20 minutes and we look at it again and we ship it and it’s better, it’s fine. You could say it’s a penalty. Why don’t we get that right ahead of time? It wasn’t actually wrong, we just wanted to make it better after we saw it for real. That’s all.

David (15:43): I really like the musk heuristic on removing stuff. So he has this saying in whatever he calls it, his algorithm, the algorithm is that if you are not putting back at least 10% of the things you removed, you are not removing enough that to find the line exactly where it is, you have to take out too much, you have to remove too many things and you must be putting some of them back or we’re not aggressive enough. It is actually one of those epiphany points. There’s not a lot where I can read a single rule or note and go like that really clarifies a lot for me and I apply directly to this too. If Jason and I are not revisiting 10% of the decisions made, we’re not delegating enough, we’re not delegating quickly enough. We should have at least 10%. I mean not a hundred percent, but 10% of the decisions, the quality should not be right to some degree of what not right means because that meant we could have more quickly delegated responsibility to even more junior people who would’ve made even more of their initial high learning velocity decisions in that case.

(17:00): So it’s actually good. It’s a simple of the quality of the structure or the quality of the process that we will get 10% of it wrong and that we have to go back and fix that after the fact. And I don’t want that to go to zero. I think actually if you’re not going back to revisit things, A, you’re not shipping fast enough. B, you’re not delegating decisions broadly enough. C, maybe you’re not letting junior developers or designers be expansive enough in what they try to do because I see too this idea of progress in your career as Derek Sivers wrote in his wonderful essay, There Are No Speed Limits. Then at a lot of organizations they talk about, oh, to become a senior developer you need five years. No you don’t. Five years is just this placeholder for you need enough decision of consequence that you’d built up and you made and whatever.

(17:57): We can compress that. We can take someone’s five years and we can turn that into 18 months if we are willing to accelerate how quickly do you get to make the decisions? How fast will we move you up the ladder of criticality if you’re showing progress and promise and talent? And I’ve seen that with my own eyes with several people we’ve had at this company who come in quite junior, maybe actually junior, and in one case we even had an intern and you just go, there are no speed limits. There are no speed limits, there are no speed limits. Let this person cook. Let them just go full bore. Let them get it wrong 10% of the time. Show up, show them where it’s wrong, let them learn as quickly as possible. That’s how you take someone from an intern to a senior programmer in three years, which we did. Again, that requires some core ingredients to be in that soup. Not everyone is going to go from intern to senior programmer in three years, but you will never know whether they were capable of that unless you give them the autonomy, the freedom, the manager of oneness, the decisions and the breadth to be wrong and for you to show up after the fact rather than before the fact.

Kimberly (19:10): Okay, well on that note, we’ve talked about delegating and we did a podcast episode recently about hiring. So I’m curious about some of the qualities that you guys see in employees that fit this bill of being capable of being grown and also knowing this person is going to commit even if they don’t agree necessarily.

Jason (19:32): Based on the hiring podcast, I’d say the answer to this comes from the work section of it, the finalists, they do some work, they do a sample project and you have a conversation. In my opinion, you can tell pretty quickly whether or not someone’s even open to feedback. If they’re open to change, if they roll with it, if they push back, and by the way, it’s okay to do all those things. You can push back as long as you have a good point of view. If you push back because you’re just stubborn, that’s okay, but not really valued that much. So I think you can can start to tell purely through conversation. I mean there’s really no real way to know until you work with somebody. But that’s the closest we can get to actually working with somebody is that single conversation, post them doing their sample project. I guess you could talk to references. There’s a whole bunch of other things you could really do, but I don’t feel like that’s quite as real as having that actual conversation. So that’s the best I’ve come to be able to make a prediction because that’s all this is. You’re betting, these are predictions, we’re looking at probabilities here. Who knows? You don’t have that much information, but there’s some cues and some gives and some tells and I think you just kind of roll with those.

David (20:38): It’s also one of the reasons why we write this stuff down, why we literally publish it. We are trying to, and I feel no shame about saying this, indoctrinate employees before they even start, that to do well at this company, one of the core tenants is disagree and commit. If you don’t have the capacity to do that, it’s going to be difficult to be here. Now, as Jason says, you can’t always know in advance whether someone is capable of doing that, but you can list it out and say, we care about this. This is why we put it both in the book and we put it on the website and we sort of expect that if someone’s going to apply for a position here, they can take the whatever eight minutes, maybe five it takes to read through those 37 points and then there’s at least a seed that have been planted.

(21:21): Oh, this is a kind of organization with disagree and commit is important. But I have seen in the past people at this company struggled with that and needing reminders that, you know what? You might be forcefully invested in this one idea, but that’s just not how the hierarchy works. And there’s a negative version of that that is a caricature of the doofus boss that doesn’t know anything and just makes all the wrong decision. And really the people underneath them know everything. That’s right. And that’s a possibility and it’s totally possible. That’s why it’s called disagree and commit, right? It’s possible for you to disagree and actually think it’s the wrong decision, still realize that it is more efficient for us to operate this way. And disagree and commit does not mean that whoever has the decision making power, is going to be correct. I mean over the long run, the moving average of their decisions has to be good, but you’re not going to be like, see! See, I was, right? Because something fails. That to me would be a red double flag. Just waving both ways, right?

(22:30): Well, you have to embrace the practice or the protocol of working this way, not zooming in on each individual little decision. The other thing I’d say is it’s really difficult to know whether someone, how fast someone can progress. So when we try to hire, one of the things we look for is promise. How promising is this candidate? What can not just look at what are they today, what have they done and what have they accomplished? What is their title? No, no. If they’re here and we give them all the things that we get everyone, we give them full autonomy, how far can they go and how quickly can they get there? And that thing is very hard. And I’ve seen that time and again where we’ve had people who start here and they’re here for three months and I go like, I don’t actually know, even after three months, I don’t know whether there’s enough promise.

(23:23): And then suddenly you give enough opportunities and you go like, oh wow, did you see this last project? Damn, they just nailed it. And then my instinct is always, as soon as you nail a project or you’re close enough to nailing it, you got to get one of higher difficulty. This is how you progress faster. As soon as you’re like, alright, I’m highly proficient at this level, great, let’s give them something harder. And I’ve seen people go like, bam, bam, bam, bam. Just up a ladder because you think they’re capable of one thing. You think they’re capable at junior level and you go, oh, very impressive. Let’s give them a programmer level project. Let’s give them a senior level project. Damn, let’s give them a lead level project. This is just going. And some of it is, of course you’ve got to prove it not just once, but you are the person who can do all this stuff, but you will not find that out. You will not find out what the promise is unless you continuously look for ways to drop someone in the deep end of the pool and just see what happens. Again, it’s not that they have to be a swimmer right away, but you can tell in a way, there’s no other way to tell. You can’t sit down and just talk to them like, oh, I wonder if this is going to be, no, no, no, no. You got to do on the real project. Do the real thing in the deep end. How do they swim?

Kimberly (24:43): And Jason, I think the conversation part makes a lot of sense in the hiring process. I actually remember, not my interview with you, but my interview with Laura, I was asked, tell me about a time where you’ve disagreed and committed. So giving a real world example of I didn’t agree with this decision, but I went ahead and executed it Anyway, it’s What are those interview questions called? That style of interview. Tell me about a time when…

David (25:11): It’s retrospective. I mean, I think to me, we talked about that a little bit on the hiring thing. Talking about things that actually happened is far better than talking about what could happen in the future. Because once you are into the future, the person can tell what you want to hear and they can just give you that. If you’re talking about a decision that was in the past, it’s a lot harder to maneuver it into whatever the interviewer wants to hear. They kind of have to account for reality. So yeah.

Jason (25:41): I will say though that I think there’s a lot of value in discussing the now when it comes to design. We’re getting back into the hiring stuff, but looking at someone’s work, I go, what else? Where would you take this right now? Where would you take this if you had a few more minutes, a few more hours, a few more days. Yeah, they’re thinking ahead, but they got to answer it now. So I just want to see if they’re able to riff and think on the fly. So there’s something valuable about that. But I agree it’s not that useful to say in six months, what would you like things to look like or whatever, who cares? But can you think of something now on the fly? Can you riff now? That’s what I’m curious about.

Kimberly (26:19): Well disagree and commit is one of the 37signals on our website. Check that out. 37signals.com. REWORK is a production of 37signals. You can find show notes in 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 and run your business, leave us a voicemail at 7 0 8 6 2 8 7 8 5 0. You can also text that number or email us at rework@37signals.com.