> 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.
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.