The Software Developer’s Guide to Communicating with “Others”
If we want to be heard, we have to speak the same language as others.

We have often heard during meetings “Oh this sounds like rocket science” or “This is all tech talk”. As developers we are often branded as people with our own lingos and non technical folks can often not make sense of what we speak. This leads to a situation where our ideas and thoughts are disregarded.
During my career I have been part of meetings where all stakeholders are present, and the developer often doesn’t speak or speaks in a language that no one in the room can follow.
To progress in our careers and have our voices heard towards innovation and decision-making we would need to master the art of understanding how to communicate with non-technical folks within the organization. It is cool to have our little tech chat with our fellow developer, but we must know how to translate that to our non-technical teammates.
Here are some tips that I have gathered over the last few years of my career that have helped me communicate with the “Others” effectively.
1. Make the Complex, Simple

The biggest mistake we as software developers make is complicating the already complex nature of software. We have to learn to simplify concepts and keep things simple. This is evident in the way we communicate with others.
The next time you are in a meeting with a bunch of folks, step back and put yourself in their shoes. Think about how someone with no background or knowledge of your algorithms and code would perceive the information you are about to share with them.
Instead of talking tech terms, algorithms, big O complexity, talk in plain english.
For example,
Before: “This won’t be optimal since the time complexity is O(n2).”
After Simplifying: “This is going to lead to a significant performance issue, which could slow down the system.”
You can practice this art of simple communication with your spouse, friends and family and test if they can understand you.
This comes with a lot of practice, but will ultimately enable you to be an effective communicator within your team/company.
2. Teach your non-tech coworkers some crucial tech terms
At times even the most effective communicators may not be able to translate all the tech terms to simple english. After all, you are working for a tech company and some lingos would still need to be understood by all.
Try a fun exercise to teach your co-workers simple tech terms over time. Use analogies and explain it to them in a fun way!
During my previous job, I taught my solution designers differences between front-end and backend. They didn’t need exact definitions, they just needed to know how they all worked together. We used analogies like mind and body. Where the body was the front-end, the mind was the backend.
We have to wear the teacher’s hat and help our non-technical folks understand some basic technical concepts which will enable better communication amongst us. While doing that we could also ask to learn something from their world in sales, marketing, product design, etc..
So this ends up being a win-win situation for all.
3. DO NOT code during a meeting
This may sound ridiculous to some, but it happens. We get bored easily in meetings, and sometime resort to coding, compiling, running tests etc.. during the course of a meeting.
What happens when we do that?
We are not a part of the decision making that happens during that meeting. Soon all decisions are made by people who have no idea about how the technology behind all of this works. And once that happens, we may start our blame game of how we were not asked for an opinion.
To circumvent this situation, always be present during meetings, and give your best inputs. If you think you have nothing to contribute to the meeting, politely decline or walk out. But don’t be present at meetings and code.
4. Build Prototypes/Proof of concepts

Building something and showcasing it, will have a far better outreach than just talking about it. If you run into a situation where it makes sense to spend few hours and build a prototype to showcase to the team it’s merits, go ahead and build it.
This will make people really pay attention to your idea and also help them clearly understand it. Since we love coding, we can utilize it to our advantage and build proof of concepts to showcase to our teams.
It will spark interest in your audience about your ideas and also eliminate the communication barriers.
For instance if you wanted to propose building a dashboard for your team to track issues, go ahead and build a simple proof of concept and showcase it to them team on how useful it could be. This will help speed up things for you to get your ideas approved.
End of the day you want to be heard as a software developer to lead innovation. Master the art of communicating and remember you don’t become an effective communicator overnight. It all comes with Practice, Practice and Practice!
Where can you reach me?
I am Adhithi Ravichandran, a Software Consultant, Author and Speaker based in Kansas City. I am the owner and founder of Surya Consulting, Inc. through which I provide various Software Consulting, Architecture, and Teaching services. I have helped several teams meet their development and architecture goals and helped transition them to modern frontend stack!
For information on my consulting services visit: adhithiravichandran.com
To stay connected follow me on Twitter: @AdhithiRavi
Subscribe to my stories on Medium https://adhithiravi.medium.com/subscribe
Become a medium member: https://medium.com/@adhithiravi/membership