Let’s face it—being a developer isn’t just about writing flawless code. It’s about collaboration. But here’s the harsh truth: most developers suck at communicating with non-developers.
What happens when you’re trying to explain something to designers, QA testers, project managers, or marketing professionals? How many times have you seen blank stares or heard the dreaded, “I don’t get it”?
It's not entirely their fault, nor yours, but you can make some efforts to make the communication clear.
In today's article, explore some principles for communicating with non-developers.
Personal Story
In 2020, I worked at my first startup. In the beginning, the team was made up entirely of developers, all working hard to create the MVP.
Two months before the product launch, our first non-technical teammate joined: a marketer.
In a startup, understanding the product is crucial. You might find yourself involved in areas that don’t directly relate to your job.
One day you’re coding, and the next you’re learning about marketing strategies because the founders want your input. That’s why working in a startup is so rewarding—you get to learn a lot.
Our marketer felt the same way. As she got more familiar with the product, she started making suggestions. But when it came time to implement some complex features, she asked me the toughest question:
Ari: "Why?"
Me: "Our WebSocket engine can’t handle that many requests. It’s complicated."
Her confusion was clear. That’s when I realized I needed to explain things in a simpler, clearer way. Thankfully, a more experienced developer stepped in with a better response:
Him: "We have a messaging system that sends notifications to consumers, developers, and riders. Right now, it’s not stable enough to add more recipients. But we could improve things by sending push notifications and listing orders directly in the app, instead of waiting for notifications to show up. What do you think?"
I loved that answer because it gave me a blueprint for how to communicate with non-technical people:
- Keep the language simple.
- Forget the technical details; focus on the requirements.
- Be patient and open to collaboration.
Another colleague of mine—a very technical person—learned a similar lesson. He was the classic “geeky” developer shown in movies and TV shows, always buried in code. In his first few months with us, he had to adjust one major habit: speaking in technical jargon to the manager.
He was a mobile developer, rewriting our app from React Native to Flutter. One day, when he was behind on an implementation, the manager asked why.
Instead of giving a simple, abstract explanation, he dove into details about classes, proxies, and components. As a backend engineer with no knowledge of Flutter architecture, even I was confused. So, you can imagine how lost the manager was.
Luckily, another team member stepped in to save the day. He explained the situation without going too deep into technicalities:
Coworker: "Flutter works differently from what we’ve used before. We assumed a part of the implementation would be the same, but there’s no support for it, so we have to write our own solution. That’s why it’s taking time. We can have it ready by [new date]. Does that sound okay?"
He kept things simple, avoided unnecessary technical details, and shifted the focus to the requirements. He also asked for feedback, which opened the door to collaboration. This made the conversation smoother and more productive.
The Takeaway
Being simple and abstract is key when communicating with non-developers. They don’t need to know the technical complexities behind every issue.
Sharing too much technical detail can make the problem seem more complicated than it is, which might create unnecessary anxiety.
Simplicity is crucial—start with an abstract explanation, and if they ask for more details, you can go deeper.
Redirect the conversation to the requirements and offer solutions or timelines when possible. This helps keep the focus on what matters most to non-technical teammates.
Finally, always invite input. Asking for their thoughts encourages discussion and fosters better collaboration.
At the end of the day, it's not about proving technical expertise—it’s about ensuring that the team can work together to achieve the same goal.
Share your experience in the comments below, ask any questions you have, and don’t forget to share this article with your network if you found it helpful.
If you enjoyed this article and want more insights like this, subscribe to my newsletter for weekly tips, tutorials, and stories delivered straight to your inbox!
Top comments (25)
Epic Attitude:
🤣 those are legendary answers, stealing that 🤣🤣
Epic😂
This is a really good reminder, I feel like every developer should have this in their onboarding plan. It's important to know how much technical detail to include, depending on the context. When talking with managers and those outside your team, it may be easier to focus less on technicalities and more on requirements. If you're pairing on a feature ticket with another dev, including more detail is usually better. Thanks Mangabo!
Yes, you are right Gabrielle. I think it should be the first thing to communicate to every developer joining a new team.
It makes collaboration easier. Thanks for reading!
I would say it's all about anticipating what information the other person actually wants and needs; in some sense, it really is just the basics of being considerate in conversation. I often find myself in conversations trying to almost probe how much information the other person wants; some will have a "don't care, just tell me what this means for me" attitude, while others will be much more interested and just curious about stuff to the extent that they can understand the technicalities.
Trying to tell a complete non-programmer about classes and objects kind of sounds like a general problem with communication skills, honestly.
Great article! Now I know how to talk to my friends about my project without them zoning out.
haha, thanks Nate
This is a good article to help us bridge the gap. I really like to help them visualize the technical stuff into something they can relate with, like talking about buildings. Buildings need strong foundations, walls, utilities, amenities, windows. Don't even mention anything technical. If there's a bug causing issues, you can say 'imagine we're building an extension on your house, the foundations need to be solid and the builders just found an unexpected sink hole whilst digging, it's opened up into a mineshaft beneath your house and the entire thing needs to be filled with a specialist material that has to be imported from spain. I'm currently sourcing a supplier, please give me some more time to build your lovely extension'. And theyre like 'oh I totally get it now, what a pain in the ass'. Fully relatable struggle. They'll be on your side. Windows could be application features that haven't got the right glass in, bugs could be drain blockages. I find people really love it when you give them something they can relate with. Then it gives them an opportunity to ask for more details which you can then appropriately drip feed.
Exaxtly
thanks for sharing your experience
Thanks K!
you are welcome Adrian!
I was laughing a bit when reading this, so relatable
glad you liked it :)
man you just saved my whole startup team ,even the explanation is simple ,God bless you brother ,🤣🤣🤞
haha thank you man
God bless you too
Great advice
Thank you Bernardo
Awesome
thank you
Some comments may only be visible to logged-in visitors. Sign in to view all comments.