Technical decision making, a topic of choice, when a developer becomes a senior developer/architect on the team, means having more resources to influence. There are also cases where bad decisions are made without positive feedback.

There are three main reasons why architects make bad decisions on technical solutions

  1. Lack of knowledge: the content of technical decision is beyond the current cognitive range of the individual, such as new technology, new field, new business. The review process is not clear about the relevant content, and it is difficult to find the potential risk in the plan.

  2. Self-motivated: The technical solution is optimal for the individual (or related), but not optimal for the team. For example, the benefits of a certain project are large, but the long-term maintenance cost and risk probability of the team will be increased.

  3. Lack of energy: Due to scheduling reasons, there are conflicts in some meetings, or time is too tight, so that the background, reasons and details related to the plan are not clear. The technical decision-making process goes through the process without interaction, such as lack of energy to attend the meeting or being interrupted by higher things.

How to circumvent the above three reasons, there are several ways that you, as an architect, can advance yourself, mainly in the following four ways.

  • Take the initiative to ask questions: Generally speaking, a technical solution, the review of the technical solution, unless the review personnel are excellent enough, consider extremely comprehensive, otherwise there will be risks. The discovery of risk points is related to the depth of the assessment personnel’s understanding of the field, and also to the degree of exposure of risk points. Low risk points are relatively easy to spot. For deeper risks, it takes multiple inquiries to discover the risk point. As for asking questions, the risk point is here, which will be triggered sooner or later. If you do not ask questions, the cost of risk restoration will be higher later

  • Collaborative decision making: Collaborative decision making is also an effective way to avoid risks. There are two main situations: 1) In areas where you are not good at, find out potential risks in advance by visiting experts in the field; 2) The collaborator, because the change of the technical solution has an impact on the relevant personnel or business, or the ability in the collaborative product construction is needed, the collaborator must not be omitted in the review of the technical solution. Even if it can be done at all, it needs to be aligned with the people involved, who are aware of what is going on, to avoid conflicts between parallel efforts.

  • Stick to the Bottom line: What’s the bottom line? Looks like the word says a little grandiose, objective position is different, the bottom line has a different nature, different goals, the bottom line is different, as a representative of the architect is the team goals, technical solution should be more reasonable, see, the more fully to see again a little bit far, don’t let the team is in a state of passive even passed for a long time. To sum up, the general principles and bottom line cannot be changed by someone. Encourage and support the team’s values, and prompt and correct the deviations that do not conform to the team’s values.

  • Prioritization: prioritization is not the only important thing, no matter what is not important, with the risk, the result is needed someone to pay, prioritization is refers to under the limited energy, is associated with their preference to effective participation, determine the necessity of the participation of individuals, avoid meaningless resources. When the personal energy is insufficient, the priority can be decided to follow up the order of matters, or the agent to follow up, to help solve practical problems in the process of technical decision-making (discussion), to avoid the situation that someone is in charge of one thing, but there is no energy to invest.

Similarly, for the scheme promoted by the architect, it is necessary to conduct review and target alignment. As the promoter of the review, it is essential to prepare complete and effective information in advance and synchronize it to relevant participants to avoid wrong decisions in the review process.

Other reference

  • [Thinking about the process of architecture Optimization] Quality over efficiency

  • Avoid random trial and error

  • [Thinking on the process of architecture optimization] Continuous technological innovation

  • [Thinking about the process of architecture Optimization] the value of specifications in R&D work

  • Summary of componentization benefits of R&D process

  • [Thinking about the process of architecture optimization] It is better to determine things by people than by people

  • Five key points of CR

  • Three dimensions of technical solution evaluation

  • The meaning of communication

  • [Thinking on the process of architecture optimization] Platform ecology is given priority

  • [Thinking on the process of architecture optimization] The sorting principle of technical requirements

  • The basic principles of active communication

  • [Thinking about the process of architecture optimization] The difference between architecture optimization and function iteration

  • [Thinking about the process of architecture optimization] Assume that the data is not believable

  • [Thinking about the process of architecture optimization] The value of the review

  • [Thinking on the process of architecture optimization] Multi-end solution alignment

  • [Thinking on the process of architecture optimization] Risk classification and avoidance