Developers are known to have an ego, be rude, anti-social, or lack people skills. They often think themselves smart because they can code. Personally, I’ve always believed that anyone can code; being a good developer is more about knowing how to use a search engine and ask the right questions.
This might be changing a bit in the age of AI-assisted coding, but the point remains: developers aren’t smart just because they know how to code. The sooner a dev acknowledges that non-technical teammates are also intelligent and deserving of respect, the further they’ll go in their career.
The focus of this post is on the non-technical roles developers interact with most often — QA, Product Managers, and Designers.
This is the second post in my series Being A Great Developer Is More Than Just Code Output. You can find the first post about Code Reviews here.
Let Go Of Your Ego
Part of the job of QAs, PMs, and Designers is to review your work: checking for bugs, verifying requirements, and ensuring that designs match expectations. Just like with receiving code reviews, you are not your code. You’re human. You’ll make mistakes, overlook details, and that’s okay.
Making mistakes doesn’t make you a bad developer. These roles exist to support you so that issues don’t reach production and affect customers. It’s not you vs. them, you’re on the same team, working toward the same goal.
I’ve often seen this ego-driven defensiveness, especially from junior developers (my younger self included). It’s a natural reaction to feel protective of your work when it’s being “criticized.” But reframing that feedback as collaboration — not confrontation — changes everything.
QA is your friend. They’re probably overworked and underpaid. Be kind.
Give Respect To Earn Respect
I’m a firm believer that no one is owed respect for their title or position; respect is earned through how you treat others. As a developer, you have to show up and give respect to non-coding teammates.
I’ve been in many rooms, both virtual and in-person, where people dismiss the work of QA, PMs, or Designers. That kind of attitude poisons collaboration. Each person brings expertise in their field just like you do in yours. Ego is the enemy of effective communication.
Once you let go of your ego, it becomes much easier to recognize and respect the knowledge others bring to the table.
Bring Everyone Along
In my previous post, I talked about how giving code reviews kindly and thoughtfully can help others learn and “pay dividends” over time. The same idea applies here.
Building a strong relationship with non-technical teammates by communicating openly, explaining clearly, and listening respectfully, benefits everyone in the long run.
Let’s focus on relationships with Product Managers as an example.
Throughout my career, I’ve seen two extremes:
The dismissive dev, who’s short and overly technical, uses jargon to avoid explaining things. This creates distrust, leads to overpromising, bad requirements, and a lot of wasted time.
The over-explainer, often a senior developer, who dives too deep into implementation details and loses the PM’s engagement. Even with good intentions, it can overwhelm the conversation or slow decision-making.
The sweet spot is finding the right level of technical depth. Explain enough so they understand the trade-offs and constraints, but skip unnecessary intricacies.
For example, our team once walked a PM through how a new microservice integrated with our monolith, we avoided buzzwords like “JWT tokens” and instead focused on how data flowed between systems. That session gave the PM enough context to write better stories, plan more accurate timelines, and help the team divide work efficiently.
As a developer, keeping a mindset of teaching and including others, no matter their background, builds trust, understanding, and efficiency over time.
Be A Leader, Regardless of Seniority
You don’t need a formal title to act like a leader. Leadership starts with how you treat people and how you help them grow.
Treating others with respect, bringing them along, and letting go of your ego are all key leadership traits. Another piece of that puzzle is fostering unity within the team — companionship instead of division.
Put these principles into practice, and you’ll naturally become someone others look to for guidance.
Closing Thoughts
A great engineer doesn’t shine by writing flawless code, but by how they collaborate with others, especially with non-technical teammates.
A healthy, respectful team dynamic not only leads to better results, it makes the day-to-day far more enjoyable. As developers, it’s on us to help foster that kind of environment, one where everyone feels heard, valued, and supported.
If this post resonated with you, or made you reflect on your own team dynamics, I’d love to hear your thoughts. How do you approach collaboration with non-dev roles? What’s worked (or not) for your team?
Next up in the series: “Being a great developer is more than just code output — Mentorship.”
Top comments (0)