As developers we work with non-technical people and we can do a better job connecting with them. Non-technical people don’t care about the technical jargon certainly don’t want to hear about how the repository doesn’t fit into the polymorphic inheritance. What they do want to hear are trade-offs or implications.
For example: If someone non-technical asks “Can x feature be developed and deployed within the next month?” The answer is of course “it depends“. Most likely the person asking if the feature can be developed doesn’t necessarily understand the trade-offs of building the feature within 1 month instead of 6 weeks.
Don’t blindly say yes or no with technical jargon. Find a way to connect that brings value to everyone in the conversation. Adjusting what you say depending on who the receivers are. In our example above we want to explain that we can finish the feature within the month, but recommend not to and explain.
Our answers may be:
Finishing the feature within a month will increase technical debt, make it difficult to implement features in the future, and push the limit on capabilities. If any other requests came through during the month we most likely would not finish the feature in time. 1 month is best case scenario and is risky.
If we take 6 weeks instead of 4 we can test our code maintaining stability, keep our sanity, and maintain application flexibility.
In both answers above we explain the trade-offs in a non-technical manner. Arming the person with information necessary to make a proper decision. The most important part is to actually give the person enough information to make an informed decision instead of making it blind.
* Keep in mind recommendations are not always adopted and certainly don’t take offense if the recommendation isn’t adopted. If you provided them enough information to make an informed decision that’s most likely all that can be done.
