Have you come across those heated email exchanges between customer stakeholders (manager, architect, tech lead, senior engineer etc) and stakeholders from your team including developers, tech lead, managers or architect? If you have worked in IT services company whose primary business is to work on development, support and migration of one or more applications in different technologies, instances like these are more likely to appear.
If you want to act as an equal partner and contribute to maximum in overall growth of your customer’s business, you are surely expected to contribute much more than just do what is asked to be done. In that regard, you may be expected to contribute during design discussions, code review discussions, general planning meeting etc. If you do not contribute, you are bound to have customers rightfully complain on “lack of initiatives”. And, if you contribute but not in polite manner, there is high chances of bad reputation which is not going to serve any purpose. Thus, what to do?
Let’s try and see what are those phrases/statements, scenarios that would have your customer stakeholder get offended and respond sharply:
- Can I know….
- Yes, but I do not agree…
- Start with one of above without mentioning “thanks”
- Bad English with grammatical mistakes along with above 🙂
- Not giving enough credit to customer stakeholder for raising the point.
Lets try and understand some of the ways in which you would want to disagree in a polite manner:
- Say “Thanks” to the customer stakeholder for bringing one or more points on the table, even if they sound against you. This brings them back on to table and have ears for your arguments.
- If you agree to their points but at the same time want to put additional points, choose words such as “rightfully pointed out”, or “thanks for pointing that out”, or “valid point”.
- Use interrogative style for putting your points. For example, start your argument by “Did you get a chance to also look into xyz areas?“. Or, “would you want to look at…“
- Use verbs such as “may”, “might”, “would” rather than “can”, “will”, “should” etc.