16 ms·

> Disagree and commit: I hate that this is such a common thought process. This is something that makes sense for soldiers in the military. But outside of thi

> Disagree and commit: I hate that this is such a common thought process. This is something that makes sense for soldiers in the military. But outside of this context (being a low-information cog in a gigantic machine), it's terrible. If you can't convince domain experts that the plan is sound, then maybe it's a bad plan. Honestly, disagree and commit goes against my... > Theory for excellence.

trgn 3y ago
lol Disagree and commit is like your mom saying she'll forgive but won't forget. sounds good on the surface, but really slightly manipulative and rancorous.
beisner 3y ago
> I hate that this is such a common thought process. In most teams, not everyone is on the same page: - There are people with varying levels of experience, some may not currently have enough background to fully understand all the aspects that a plan addresses. - Many/most people have the tendency to let their various biases creep into team-level decision-making. For instance, if someone had a bad experience on a previous team using technology X, they are less likely to support using X today independent of X's suitability for the current situation. And people tend to have a massive bias towards their own ideas rather than others' - so when two competing ideas are presented, one's own ideas are often preferred to others' ideas. - Especially in larger organizations, there may be political motivations for pursuing one plan over another plan - both for management and for workers. "Nobody got fired for buying IBM" and "resume-driven development" and "launches get promo more than landings" are a few examples that come to mind that I've seen. Unless you're on a golden A-team of contributors who are all incredible and on the same wavelength (this does happen sometimes! if so, cherish it!), you're going to have a mix of people with a mix of motivations+biases+experiences, incapable of reaching consensus around the "true" best plan in a reasonable amount of time. Making decisions in a reasonable amount of time is CRUCIAL to team performance. Obviously, sometimes you make a bad decision quickly when you might have arrived at a good decision with more deliberation+debate+waiting for consensus. But in my experience, the benefit of avoiding these "bad" decisions from time to time is dramatically outweighed by a team's ability to decide very on things very quickly and commit to a plan (and therefore execute). Famously, section 5.11 of the CIA's Simple Sabotage Field Manual [1] describes some pretty timeless ways to ruin an organization's productivity - all kinds of behavior that are kind of indistinguishable from the behavior I've seen arise from "disagreeing and not committing" in organizations. [1] https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/SimpleSabotage.pdf https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/...
- mywittyname 3y ago
  > Famously, section 5.11 of the CIA's Simple Sabotage Field Manual [1] describes some pretty timeless ways to ruin an organization's productivity - all kinds of behavior that are kind of indistinguishable from the behavior I've seen arise from "disagreeing and not committing" in organizations. Honestly, it seems like "disagree & commit" facilitates these bad behaviors. An "individual's opportunity to make faulty decisions" is a lot easier when that individual has the power to say, "shut up and do what I say" without repercussion. A lot of these techniques are feigned incompetence. A manager can abuse D&C to facilitate a lot of these activities, for example by requiring a worker to use a tool that needs to be maintained. And D&C doesn't prevent things like, starting fires around munitions or putting sawdust in fuel. That's a security issue. And C&D can be used to justify bypassing security procedures. For example, a manager telling a guard not to log their entry into a secured building.
  - em-bee 3y ago
    for me disagree and commit only applies to team decisions. a dictatorial team leader or manager is an entirely different problem. in such a case it is up to the team under the leader to figure out how to deal with that.
- delecti 3y ago
  Agreed. You eventually need to take some course of action, so if you can't get everyone on exactly the same page, someone won't get their way. Those people can either accept that their approach isn't being taken, and thus work towards the approach which has been decided upon, or refuse to cooperate, hurting the team in the process. The only real weakness with "disagree and commit" is if you have a deeply unreasonable leader, and then "disagree and commit" is the least of your problems.
skellera 3y ago
If you trust that the people you are working with are working towards the same goal, disagree and commit is important. You are not going to be right 100% of the time. If the group is saying X is the right way to go and you’ve already given your reason why you think Y, you should disagree and commit. If you sit there complaining for weeks that they should be doing Y without any new information, you’re just being a shitty teammate and dragging everyone down. The main point for the commit part is setting aside your ego to move the team forward. Most decisions are two way doors. If X doesn’t work out then try Y but don’t complain, work less hard, or sabotage because you didn’t get your way. One big exception is if someone is making a decision that goes against company principles or morals.
- em-bee 3y ago
  indeed, only working in unity allows a team to face and fix mistakes and bad decisions, because then there is noone shouting "i told you so" when something fails. unity in a team is more important than being right.
Aurornis 3y ago
> If you can't convince domain experts that the plan is sound, then maybe it's a bad plan The "disagree and commit" scenarios I see in the real world are usually one of the following: - Disagreements within a team. One "domain expert" disagrees with others about what should be done. The only way forward is to disagree and commit, or remove that person from the team (or company). So disagree and commit is the first choice. - Disagreements about NIH. Someone wants to build a custom framework or new library instead of using one off the shelf. Building things from scratch is fun, adapting existing things to your need is less so. Given limited resources and time you have to disagree and commit to using something off the shelf. - Disagreements about priorities. Someone thinks we need to rewrite the codebase or refactor everything or address a low-priority bug instead of working on important feature work for the business. There are cases where too much tech debt is bad, but often it's necessary to focus on what the business needs to keep moving forward. If someone can't disagree and commit to working on what the business needs, that's not going to work out. Some people simply can't commit to a plan they don't agree with, which means you're either letting them hold everything hostage to their own plan or you're going a different way while they sulk about it. Neither situation is good for planning.
BeetleB 3y ago
You're not providing an alternative, though. You have a team of smart people. They come up with 3 interesting proposals. You have the bandwidth to execute on only one of them. At some point, a decision has to be made (by you, by vote, whatever). Two guys on your team are going to hate that decision. Are you going to be OK with those two not contributing to the end goal (i.e. the "commit" part)? Are you going to be OK with them bringing it up in each team meeting and 1:1 over the next year? Are you going to be OK with them not voicing their opinions (i.e. the "disagree" part)? What's your alternative? As pointed out in a submission a few days ago, the worst experiences tend to be teams that always blindly do what the boss tells them, and at the other end of the spectrum, teams that question every little detail - all the time. Disagree and commit addresses the latter. I've been in that team - it sucks. Never again.

trgn 3y ago

lol Disagree and commit is like your mom saying she'll forgive but won't forget. sounds good on the surface, but really slightly manipulative and rancorous.

beisner 3y ago

> I hate that this is such a common thought process. In most teams, not everyone is on the same page: - There are people with varying levels of experience, some may not currently have enough background to fully understand all the aspects that a plan addresses. - Many/most people have the tendency to let their various biases creep into team-level decision-making. For instance, if someone had a bad experience on a previous team using technology X, they are less likely to support using X today independent of X's suitability for the current situation. And people tend to have a massive bias towards their own ideas rather than others' - so when two competing ideas are presented, one's own ideas are often preferred to others' ideas. - Especially in larger organizations, there may be political motivations for pursuing one plan over another plan - both for management and for workers. "Nobody got fired for buying IBM" and "resume-driven development" and "launches get promo more than landings" are a few examples that come to mind that I've seen. Unless you're on a golden A-team of contributors who are all incredible and on the same wavelength (this does happen sometimes! if so, cherish it!), you're going to have a mix of people with a mix of motivations+biases+experiences, incapable of reaching consensus around the "true" best plan in a reasonable amount of time. Making decisions in a reasonable amount of time is CRUCIAL to team performance. Obviously, sometimes you make a bad decision quickly when you might have arrived at a good decision with more deliberation+debate+waiting for consensus. But in my experience, the benefit of avoiding these "bad" decisions from time to time is dramatically outweighed by a team's ability to decide very on things very quickly and commit to a plan (and therefore execute). Famously, section 5.11 of the CIA's Simple Sabotage Field Manual [1] describes some pretty timeless ways to ruin an organization's productivity - all kinds of behavior that are kind of indistinguishable from the behavior I've seen arise from "disagreeing and not committing" in organizations. [1] https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/SimpleSabotage.pdf https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/...

mywittyname 3y ago
> Famously, section 5.11 of the CIA's Simple Sabotage Field Manual [1] describes some pretty timeless ways to ruin an organization's productivity - all kinds of behavior that are kind of indistinguishable from the behavior I've seen arise from "disagreeing and not committing" in organizations. Honestly, it seems like "disagree & commit" facilitates these bad behaviors. An "individual's opportunity to make faulty decisions" is a lot easier when that individual has the power to say, "shut up and do what I say" without repercussion. A lot of these techniques are feigned incompetence. A manager can abuse D&C to facilitate a lot of these activities, for example by requiring a worker to use a tool that needs to be maintained. And D&C doesn't prevent things like, starting fires around munitions or putting sawdust in fuel. That's a security issue. And C&D can be used to justify bypassing security procedures. For example, a manager telling a guard not to log their entry into a secured building.
- em-bee 3y ago
  for me disagree and commit only applies to team decisions. a dictatorial team leader or manager is an entirely different problem. in such a case it is up to the team under the leader to figure out how to deal with that.
delecti 3y ago
Agreed. You eventually need to take some course of action, so if you can't get everyone on exactly the same page, someone won't get their way. Those people can either accept that their approach isn't being taken, and thus work towards the approach which has been decided upon, or refuse to cooperate, hurting the team in the process. The only real weakness with "disagree and commit" is if you have a deeply unreasonable leader, and then "disagree and commit" is the least of your problems.

skellera 3y ago

If you trust that the people you are working with are working towards the same goal, disagree and commit is important. You are not going to be right 100% of the time. If the group is saying X is the right way to go and you’ve already given your reason why you think Y, you should disagree and commit. If you sit there complaining for weeks that they should be doing Y without any new information, you’re just being a shitty teammate and dragging everyone down. The main point for the commit part is setting aside your ego to move the team forward. Most decisions are two way doors. If X doesn’t work out then try Y but don’t complain, work less hard, or sabotage because you didn’t get your way. One big exception is if someone is making a decision that goes against company principles or morals.

em-bee 3y ago
indeed, only working in unity allows a team to face and fix mistakes and bad decisions, because then there is noone shouting "i told you so" when something fails. unity in a team is more important than being right.

Aurornis 3y ago

> If you can't convince domain experts that the plan is sound, then maybe it's a bad plan The "disagree and commit" scenarios I see in the real world are usually one of the following: - Disagreements within a team. One "domain expert" disagrees with others about what should be done. The only way forward is to disagree and commit, or remove that person from the team (or company). So disagree and commit is the first choice. - Disagreements about NIH. Someone wants to build a custom framework or new library instead of using one off the shelf. Building things from scratch is fun, adapting existing things to your need is less so. Given limited resources and time you have to disagree and commit to using something off the shelf. - Disagreements about priorities. Someone thinks we need to rewrite the codebase or refactor everything or address a low-priority bug instead of working on important feature work for the business. There are cases where too much tech debt is bad, but often it's necessary to focus on what the business needs to keep moving forward. If someone can't disagree and commit to working on what the business needs, that's not going to work out. Some people simply can't commit to a plan they don't agree with, which means you're either letting them hold everything hostage to their own plan or you're going a different way while they sulk about it. Neither situation is good for planning.

BeetleB 3y ago

You're not providing an alternative, though. You have a team of smart people. They come up with 3 interesting proposals. You have the bandwidth to execute on only one of them. At some point, a decision has to be made (by you, by vote, whatever). Two guys on your team are going to hate that decision. Are you going to be OK with those two not contributing to the end goal (i.e. the "commit" part)? Are you going to be OK with them bringing it up in each team meeting and 1:1 over the next year? Are you going to be OK with them not voicing their opinions (i.e. the "disagree" part)? What's your alternative? As pointed out in a submission a few days ago, the worst experiences tend to be teams that always blindly do what the boss tells them, and at the other end of the spectrum, teams that question every little detail - all the time. Disagree and commit addresses the latter. I've been in that team - it sucks. Never again.