How to stop endless discussions and start doing work

When you start a new project, there are usually numerous choices engineering teams have to make. Starting with the basics like repository management, language, database, storage, CI/CD, cloud-native or not, etc. And by chance your engineering team can make these decisions fairly quickly, then they still can't start the work before making some more choices. For example, once you select a language, your team will need to decide on different frameworks (or whether to use one or not), linting tools, code formatting, code structure, design patterns, ORM (whether to use one or not or which one to use), etc. So your team spends a lot of time discussing the options (or arguing) and leaving a fairly small window for implementation. Even after all this, the tools you select might still come short for the job, because the team might not have considered some requirements or missed some development angle. Moreover, the small implementation window will lead to poor code and will be hard to maintain in the long run. This is one of the human behavior fallacies. You can steer your team away from this fallacy.

The rule of a Dictator

The first method is to be the dictator and tell your team about your choices of technologies and tools and your team will carry out the tasks. This method works well if you're going to be working with only contractors or a temporary team. This is because engineers usually don't like dictators. They want to feel empowered. But if you work with contractors or a temporary team, you probably won't care about their preferences and your team probably won't have any issue doing your bidding.

The rule of the corrupt government

The second method is a bit gentler approach. You would first create a list of technologies and tools that you feel would be most acceptable to your team. Then show your reasoning about your choices to your team. If someone finds some issues in your reasoning, be prepared to change your choices. The main thing here is to settle on a starting point as soon as possible. It would be easier to coerce your team into making the same choices you made if you are a manager but it would still work regardless of your position in the team.

The rule of the democracy

Another approach is to remove the discussion from the decision-making and instead only present the choices. This method is more democratic than the other two. You would essentially still ask everyone for their opinion but remove the time-consuming and endless process of discussions.

The rule of the republicans

If you would like to have micro-architecture for your product (I usually don't prefer this though), then you can split your entire development into individual features that individual developers are responsible for choosing their tech stack, and you can then connect these features into a final product.

TLDR

Sometimes these discussions provide a great way to iron out some business requirements and other times they are just a hindrance to getting things done. You have to decide how much time and in what way you want to facilitate these discussions. You can either dictate every decision or coerce your team to make what you wanted all along or you can create a democratic election for making these decisions. Whatever you choose, don't forget that you might need to readjust when something does not work out.