At Tivix, we engage with a wide spectrum of amazing clients, each with a unique background. Our job is to make our clients satisfied with our progress, from the beginning of the project until the final hand-off.
For us to build great software for a new client, we often need to start by learning the language of their domain knowledge. A typical new client for us might be a founding CEO who is an expert in financial services, banking, real estate, or biotech. So our learning the language of his/her domain knowledge is often a crucial element to building a great client relationship.
In everyday life, two complete strangers can start talking about a subject they have a common interest in: sports, music, cooking, etc. They each know the jargon, idioms and expressions specific to their subject, and can dive into a spirited discusion on the topic.
But code wizards (including me) don't necessarily know the client's language. We are used to talking about software code, analyzing input/outputs, evaluating development methodolgies, and judging engineering risks. Clients, on the other hand, talk about features and benefits for users in a particular sector. Traditionally, organizations have used product managers as 'bilingual' go-betweens to solve this problem. Product Managers are the translators of the development world.
However, often engineers today need to communicate directly with the client. What if the product manager isn't available? What if we have some questions that need to be answered by the client directly, before they become a complete blocker. What should we do? Engineers with some ability to speak the language of the client's domain of knowledge have much better tools to both understand and to be understood during interactions with clients.
Some of the valuable engineering skills I learned back in school were actually taught, not in Intro to Computer Science and Object-Oriented Programming classes, but in writing and language classes. Written or spoken, language is all about elaboration, explanation, persuasion, and conveyance of ideas using shared contexts. A client is likely to articulate ideas, expectations, and needs using language particular to their domain of specialized knowledge. Using clear, precise communication skills and seeking follow-up clarification and explanations when necessary, engineers can gain a degree of familiarity with the jargon – and by extension the mindset – particular to the client’s domain of knowledge. Establishing a shared context with the client makes the engineer markedly more adept at crafting a product that can be coherently integrated into the domain it was originally intended. This is actually a main difference between programmers and engineers today. Programmers may produce great code, but engineers produce great features that fit the context of the client's business, and deliver actual value.
Engineers should go an extra mile to make & keep great relationships with clients. Our client feedback proves who we are and the quality we craft.
The way I think of it, our clients are the visionaries with the blueprint. We are the architects. By building their dream, and ensuring its structurally sound, we hope to establish a solid foundation – and that we will see them again soon when they return to us with their next great project or big idea. By taking the time to really understand their business, we get smarter about their domain topic, and they get their vision transformed into reality.
Picture Credit goes to Yupi666 at en.wikipedia
