I like to think there are three phases to making any good group decision within a technical team: brainstorm, collaborate and communicate. Unfortunately too many engineers tend to do the first two steps in their head, and then are often confused at the negative reactions they receive upon their arrival at phase 3.
Here is the framework I learned early by trial and error as a young software engineer:
Step 1: Brainstorm
It is critical to enter the brainstorm phase with as few preconceived ideas as to the right decision as possible. In this phase, you should broadcast to the team the decision that needs to be made, and solicit feedback from anyone interested in influencing this decision. It’s important to be open to all possible ideas, no matter how out of the box they may sound. The ability to influence others is directly related to your willingness to be influenced - thus entering the brainstorm phase being open to influence will aid you in making the best decision (and also ensure buy in from the team who is impacted by the decision).
Step 2: Collaborate
At this phase you have identified two or three different possible directions you can take with a decision, and likely have an early opinion of the right choice. Now is the time to collaborate. Provide the key stakeholders on the team the available options, and openly discuss the advantages and disadvantages of each. Solicit group-think, recognizing that opening the decision to debate will both ensure the best decision gets made, and help foster later buy in from the team. Again remember the golden rule: you can’t influence others if you do not remain open to be influenced.
Step 3: Communicate
The decision has been made. It’s time to communicate it back to the team and help them understand it. If appropriate, it can be useful to communicate what alternatives were considered. For particularly controversial issues, you can solicit the help of the key stakeholders that helped you in the brainstorm and collaborate phases to support the communication.
Sounds simple right? Well I will confess to having been surprised many times in my career at the reactions I received upon making key group decisions without following these steps. I remember once receiving a strongly negative reaction to an early software design, and feeling as though the people criticizing the design just didn’t have sufficient knowledge of the available options. It never occurred to me that at least some of the people who were expressing the negative criticism would have been willing cohorts in helping me arrive at the best decision, and in the process of engaging them, I'd be making a better decision and one would more easily be supported by the team.