One of the most important skills of a senior engineer is successfully design and implement complex software. Most software design courses and articles cover how to write proprosals, however, a well written, accurate and correct proposal is not a guarantee of successfully getting people to understand, review and approve it.

Like any process that involves people, correctness is only one factor, that determines whether a proposal will find a favourable response. Too many times we hear ourselves complain that a great proposal was not approved or found a lot of disagreement, but that should not come as a surprise. There are only two reasons why such a scenario would arise. Either the criticism is correct and the proposal has to be improved, or some of the human elements are missing with the proposal (or the proposer) that caused such a reaction. In this article I will explain about some of the factors that influence suceess in the latter case.

It is important to realise that your proposal is under review even before you have written it! People always start reviewing, based on who has put up the proposal and the technical capital of that person will be the first thing that comes into play. So all the future proposals are dependent on how much confidence people have on the capability of the person writing it. Note that this is only perception, and may not reflect the actual capability, for example of someone new to an organization.

It is only fair that the review of a proposal written by someone new would be scrutinized more than if were writtn by someone who is already familiar with the existing architecture and probably has written designs for it before. This may seem like a daunting entry barrier, but the initial apprehension is something everyone faces. It can to be navigated by good core work that does not require design proposals or architectural changes initially.

This is the build up phase, where subconciously everyone watches and makes an opinion of the "new joinee" based on the work done and it is very important to make sure that it inspires confidence amound the peers. Subsequently, how well the past technical decisions and proposals went, will continue to decide how smooth the review process goes, but it does get easier with the momentum.

For a medium or large architectural change, it is important for the proposer to identify the primary stakeholders for the affected areas. Usually it is enough to chat with one of the members of each team (or area) and get an understanding of the ideas that come up off the top of the head.

Taking to the decisions influencers before or early into writing a design document gives a good insight into the probable right approaches. These may not always be complete because it is quick advice and not a through assessment. The primary objective though is to make sure that the proposal does not come as a surprise to the teams. Any internal refactoring or similar work going on is factored for and the proposal can be streamlined with the other parallel changes.

Once the design document is ready, a considerable number of people will be looking at it. This is a critual time and the right preparation from the proposer goes a long way and maybe one of the most important factors that influences it to be approved. Empathising with the viewers will help navigate the difficult moments and challenges of the discussion phase.

Even though the primary stakeholders know about the change and the approximate direction the document is going to suggest the changes, it should not be expected that the discussion will sail through without apprehension. The key is to be ready for incoming queries around the proposal and to be sure to expect probing questions and suggestions.

A lot of times the resistance from the approvers and the reviewers group in general comes as a surprise, which derails the conversation. The purpose of the review phase is to scrutinize and understand the design document, so it is only fair that questions will be asked, even if all parts have already been discussed with the right people. Be ready for it.

A good design document already considers a number of alternative approaches and then selects the one that appears to be the best. Sometimes, the discussion phase revolves too much around the chosen approach which feels as if the descision has already been made. The right way to approach a design discussion is to suggest the solution, but be open ended about the final decision.

How a proposal is pitched is very important for its acceptability, because people must know that the intent of such an excerise is to find the right solution rather than pushing a pre-determined outcome. So the apporach must be to propose and not to tell what needs to be done.

During the review process, a lot of times new suggestions or questions around alternative approaches come up. The best case scenerio is that those cases have already been thought about and documented in the design proposal. If that is not the case (and in a constructive design review, there should be such cases), those suggestions should be appropriately considered. Some may be immediately resolved during the discussion and others may be included in the document along with its pros and cons.

The intent of considering suggestions, along with ensuring that the document is complete, may not be to actually change the outcome and decided on a totally different solution than what was proposed, but to make sure that the reaction from the proposer to a new suggestion is not considered dismissive.

Complex software design decisions require a lot of explanation and different approaches to be considered. This leads to large documents and a proportional amount of effort required from all reviewers to go understand, give suggestions and approve an approach. For this, as well, empathising with the reviewer and making the decision process simpler makes the entire process much faster.

For example, at the very top of the document, a summary table with appropriate weightage to different aspects for each alternative solution can sum up to a total that would help give a clear picture of which one is being selected and why.

There are some situations that call for a meeting or discussion to be paused, for the priticipants to rethink and re-evaluate their arguments. Even though these should be rare, whenever there seems to be strong opinions on either sides and the discussion leaning towards a impasse, the best way to deal with it is to postpone the decision.

This allows both parties to be better prepared for the next round, with all the aspects of the discussion already known. It also allows the situation to cool down and better sense to prevail in case the argument went in the direction of a to and fro between different ideas and their pros and cons.

In summary, being successful in having a complex software design proposal approved requires skills other than only a well written document. The right preparation, with a background of good work and known stakeholders, along with an empathatic approach towards people reviewing the document will help not just in getting more agreement towards the proposal but also much time saved for all the involved people.