Have you ever felt that collective sigh wash over a room during a system demo, when a colleague goes into excruciatingly unnecessary detail describing how a feature or fix was implemented? Have you ever asked a question expecting a simple yes or no answer, and had to sit through a diatribe on the merits of one esoteric technical consideration over another?
Or worse yet: Have you been that jargon-plagued colleague, the one geeking out over tech esoterica?
A frequently overlooked trait of most experts is their ability to convey their expertise to a lay audience. Most of the stakeholders you’ll encounter in your career will have limited knowledge in your area(s) of expertise, and deep knowledge in other milleus. Communicating your ideas to those people takes a special set of skills, which every engineer owes it to themselves to develop.
To communicate clearly and more effectively, you need to clear one big hurdle: the overuse of technical jargon, acronyms, and domain-specific language. These tools can be very effective when communicating with your peers, who share similar engineering backgrounds and experience. They’re shorthand. But when speaking to an outside audience, they put up, essentially, a language barrier.
Few things contribute as much to someone’s comprehension of a topic more than copious amounts of context. Understanding why a choice was made is just as important as the choice itself. Many specialists are quick to jump to the nitty-gritty details of an issue, before spending adequate time explaining the problems, resolutions, and trade-offs that lead to the technical choices that were made.
Before explaining your solutions, it is imperative that you provide enough information for your listeners to fully understand the nature of the problems you are trying to solve. You may think that goes without saying, but think about how many times you or your colleagues have had to interrupt another engineer to ask for some of that precious context.
It is far more useful to ‘dumb something down’ in order to communicate your ideas than it is to bewilder listeners while proving how knowledgable you are. The practice of distilling the information you are presenting down to its essence will help you and your audience gain a holistic understanding of the material, without getting bogged down in technical details.
If you don't distill information down to what really matters to your audience? This is what you think you sound like:
This is what you actually sound like:
‘If you can't explain it to a 6 year old, you don't understand it yourself.’
—Albert Einstein
While it may sound obvious, you cannot be an effective communicator without considering your audience. Who are they? What do they know? What do you want them to come away from your interaction with? If you don’t know the answers to those questions, then you should ask them before you choose your language. You can save time and energy by simply understanding who you are talking to, and what you want them to get out of it.
Here are some examples of how to quickly explain some Cloud Native concepts to someone with little to no knowledge of the subject. (And you can find more definitions here.) These can be helpful, but as the next section emphasises, always make sure you take the time to evaluate your audience, the context they are equipped with, and their experience.
‘Web-scale software often requires many applications running together. Sometimes running these programs on the same computer(s) can lead to wasted resources, conflicts, and configuration headaches. Virtual machines allow you to run many different isolated copies of Windows and/or Linux on the same computer. An individual virtual machine presents itself to the application exactly the same way a physical computer would, but you can run many of them on the same hardware. Each one is a fresh clean copy of the operating system, usually running a single application, so there is much less complexity in setting up and maintaining each one.’
‘Containers are an even more efficient way to run more than one copy of an operating system on each computer. Instead of completely isolating the virtual operating system, it shares some key components with the host operating system that it is running on. Because of this, containers require significantly less computer horsepower to run, but sometimes require a little more care to ensure that critical components are effectively isolated’.
‘In the old days, applications were monoliths: All functionality lived in the same program. The modern approach is to write many small single-purpose programs that, when assembled, function as a whole application. This allows the different components to be scaled independently, and managed by specialised teams’.
‘Software used to be validated manually and released infrequently via physical media (floppy disks, CDs and DVDs). Modern software, delivered on the web, can get updates and bug fixes instantly, pushed to end-users as soon as they are ready. In order to ensure readiness, you need automated tests to ensure your applications don’t break before they are eligible for deployment, and simple processes to deploy that software to production systems without having an impact on the users. Those processes and the tools that enable them are called Continuous Integration and Continuous Deployment’.
‘On your computer, you can run Task Manager to see what programs are eating up all your CPU, RAM, or network bandwidth. The same sort of information can be useful in the world of containers and microservices and can alert us to potential problems before the end users even notice. You can also monitor application-specific events by exporting them from your application code’.
For some great insight into how to adjust your explanations based on your audience, check out this playlist from Wired, where experts explain their work to five different people, with varying levels of expertise.
You can glean a lot from watching these videos, especially the experts’ focus on the effects and implications of their work, rather than the technical specifics and how they use feedback to adjust their explanations as they go.
The only exception is when they are paired with other experts, and the technical jargon becomes an effective shorthand for communicating more efficiently and precisely.
Above all else, they are always careful to construct their narratives based on the experience and comprehension of their listeners. After all, if you’re not thinking about your audience, then why even bother opening your mouth?