“I’m sorry, I don’t speak back end.”
How I’ve overcome the language barrier with clients…
The Tech Industry perhaps more than any other has a pervasive culture of buzzwords, anachronisms and downright confusing esoteric jargon. Just think “Cloud Computing” and you’re there. We also have a wonderfully diverse ecosystem, nay universe, of incredible tools, techniques, theories and practices, all of which have their own bewildering set of terminology. As acolytes, we strive to understand them; as outsiders, we struggle to grasp them.
I admit that the geek in me takes pleasure in being able to hold court on the semantic differences between programming languages and in whiling away an hour or two arguing the toss for mico-services. However, I am also painfully aware of how alienating tech speak can be: you only have to clock the eye rolling and head shaking from less tech infatuated better halves to know how annoying it can be.
When I was younger there was a temptation to use this shroud of mystery surrounding technology for commercial advantage, and indeed there are some for whom this is a tactic still today. My own personal journey has taken me on a less esoteric, more informative path where I have found there is no question that can’t be answered with an A3 flipchart, a suitable array of Sharpies and a helping of creativity and patience.
In attempt not to contradict my own advice, and also to avoid assuming everyone reading this article is familiar with the principles of web development, I will provide a quick definition of back end development. The server-side (or “back end“) code resides on the server and is largely unseen by the client/consumer. This type of development usually concentrates on, security and data management.
I have found that clients really appreciate being let into the inner circle. Furthermore, once they have grasped core concepts, particular those that relate to back end development, and become relaxed enough to admit when they don’t know what a term or concept means, we can have really meaningful discussions around the use of technology within their business.
This is no one way street: all organisations big, small commercial, or social have their own domain specific language where a shared understanding of terminology is alienating to outsiders. One of the first things I do when establishing a new project with clients is to create a language dictionary / project glossary where each side enters terms and descriptions including usage examples to help all project collaborators communicate better about the project. Transparency is key to the success of all collaborations, and this is no less true when it comes to technology projects.
These are a few key lessons I have learnt along the way that may be useful to adopt in your own projects:
- Maintain a glossary of key terms / phrases This is not restricted to technical terms. It should include any domain specific language used by the project team, and will include technical, UX, design and product / brand terms used by your client.
- Use diagrams “A picture speaks a thousand words” is a truism. Just remember to keep it simple and, if it’s getting crowded, break it out into smaller chunks. Try: Balsamic, Gliffy, 53 Paper, or the more traditional pen and paper.
- Think clearly about how much detail your client / co-workers need to know A little knowledge is dangerous; a lot can be overwhelming. You are aiming to empower them in their role through better understanding of key concepts, not drown them in the vagaries of garbage collection.
- Encourage a learning culture Project collaborators should feel empowered to ask and answer questions about their specialities. This can easily be facilitated by setting up a Slack team for the project. (Other collaborative messaging platforms are available.)
- Be confident in what you know and understanding of what others don’t
In conclusion, every project is different and technology evolves at a pace so this process will be a living part of each project. Remember to encourage team members, stakeholders and project participants to ask questions but don’t necessarily feel pressured into giving detailed technical answers there and then: take your time to think through the best way to explain your answer and come back with something measured and pitched at the right level for the knowledge base of your target audience.
As always, if you would like to have an informal chat with us about a build or development project, please feel free to send a note to hello@spicerack.co.uk
Justin Boynton: Technology Director | Spicerack Media Ltd