Throughout my career, I have been blessed with the ability to effectively translate technology issues to business users. At one point I was even told that I “explain technology to the users in a way that makes sense and does not make them feel stupid.” This has also been a focus for this blog, explaining and discussing technology with the idea that many people that read this blog are not software developers.
I started thinking about this recently for a few reasons. First, Chris Brogan wrote about talking in a customer’s language:
Would you give that same kind of opportunity to connect if it were your customer? Do you talk in their language, on their device of choice and about the topics that interest them?
There are two important things to note in that quote. First, are you talking in their language? Do you use their terminology? Do you try to make technical issues sound understandable? The second point is which communication medium does your customer prefer to use? These ideas are very important for any software engineer above the most junior levels of experience.
Speak Their Language
When you are talking with a customer, you need to speak in different terms than you would with other software engineers. This should be obvious to most people, but it is not an easy skill to master. First, when do you give the users technical detail and when do you give them a summary of the situation? For example, if you have a data issue that needs to be fixed, do you tell the users the details of the issue? Or do you explain the problem in terms of how the application reacts? So, your data issue may cause an error in the application, and that is what the users understand.
The communication also needs to use the same terminology as your users. In blogging software, most of the textual content is described as posts. However, your users may describe things in terms of articles. This may not seem like a big difference, but hours of discussion could be lost due to such terminology differences. It may even be helpful to create a glossary of terms when developing any documentation, that way the terminology is documented for when new people join the team.
Use Their Tools
The second question about which communication tools to use is just as important as the terminology. It may seem like a small thing, but if a company typically uses conference calls to meet and make decisions, then an email will probably not convey the same level of importance. In some companies, the opposite is true and email is the main communication medium.
The choice is not as simple as phone or email either, and it changes with each department. Your fellow programmers probably communicate using instant messaging. When you are dealing with QA, you probably will communicate using your task/issue tracking software like JIRA, Bugzilla or TRAC. In some cases, the communication medium could even be a status report sent to your manager. Each group typically will require a different method of communication.
As a software engineer, you may not think that all of this is important to your job. However, only the most junior developers do not need these types of communication tips. As your career progresses, communication can become as important as your coding skills. Developing a breadth of business skills in addition to a breadth of technology skills is very important to your development even if you do not want to be in management. If you are thinking of going the entrepreneurial route, these skills are even more important than if you stayed in a large corporation.