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!