Early in my career, I thought being a great developer was almost entirely about technical skill. Write clean code, know your frameworks, ship on time. If you could do that, everything else would work itself out.
It didn’t take long to learn otherwise. I watched technically brilliant projects fall apart because of a communication breakdown between the development team and stakeholders. I saw teams with solid developers produce mediocre results because nobody would speak up when something felt wrong. Over the course of 20+ years, I’ve come to believe that a few specific soft skills separate developers who write code from developers who build lasting software.
I’m not going to catalog every soft skill you could possibly develop. Instead, I want to focus on the four that I’ve seen make the biggest difference in practice: communication, listening, psychological safety, and empathy.
Communication Is About Writing, Not Just Talking
When developers think about communication skills, they usually picture standup meetings or explaining a technical concept to a product manager. Those matter, but in my experience, the communication skill that has the most day-to-day impact is writing.
Pull request descriptions. Design documents. Slack messages. Bug reports. Most developer communication happens in text. And the quality of that writing directly affects how well a team functions. A vague PR description wastes the reviewer’s time. A one-line bug report (“it’s broken”) generates three rounds of follow-up questions. A clear design doc with context, tradeoffs, and a recommendation can align a team in a single read.
I’ve made a habit of asking myself before I hit send: does this message give the reader enough context to act without asking me a follow-up question? That one check has saved more time than any productivity tool I’ve used.
The other half of communication that gets overlooked is giving and receiving feedback. I wrote about the mechanics of this in my code review post. The short version: be specific, focus on the code not the person, and explain why something matters, not just what’s wrong. Feedback is a skill you can practice and get better at.
Listening Is Harder Than It Sounds
Active listening is one of those phrases that sounds obvious until you try to actually do it in a meeting where you disagree with someone. Your brain is already composing your response before they’ve finished their sentence. I catch myself doing this more often than I’d like to admit.
In my experience, the developers and leaders who are most effective in collaborative settings are the ones who listen to understand before they respond. That means asking clarifying questions instead of jumping to solutions. It means repeating back what you heard to make sure you got it right. It means being comfortable with a pause before you answer.
This is especially important in cross-functional work. When a product manager describes a customer problem, a developer’s instinct is to jump to the technical solution. But if you haven’t fully understood the problem, your solution might miss the point entirely. I’ve shipped features that technically met the spec but didn’t solve the customer’s actual need, and the gap was almost always because I didn’t listen carefully enough at the requirements stage.
Psychological Safety Is the Foundation
Google’s Project Aristotle research found that psychological safety was the single strongest predictor of high-performing teams. Not talent. Not experience. Not process. Whether team members felt safe to take risks, ask questions, and admit mistakes without fear of embarrassment or punishment.
I’ve seen this play out firsthand. On teams where people felt safe to say “I don’t understand this” or “I think we’re making a mistake,” problems got caught early and solutions came faster. On teams where that safety was absent, people stayed quiet, bugs shipped to production, and postmortems turned into blame sessions.
As a leader, I think building this safety is part of the job. It starts with how you respond when someone brings you bad news. If your first reaction is frustration, people learn very quickly to stop bringing you bad news. If your first reaction is “thank you for flagging this, let’s figure it out,” you get a team that surfaces problems while they’re still small.
This connects to something I’ve written about before: blameless framing. When something goes wrong, the question should be “what happened and what do we learn?” not “whose fault is this?” That framing isn’t just kinder. It produces better outcomes because people share information honestly instead of protecting themselves.
Empathy Shapes What You Build
Empathy in software development is usually framed as “understand your users.” That’s true, but I think it’s broader than that. Empathy applies to how you work with your teammates, how you write documentation, how you design error messages, and how you handle disagreements in code reviews.
When I write code that someone else will maintain, empathy is what makes me add the comment explaining why I made a non-obvious choice, or name the variable clearly enough that no one needs to trace through the function to understand what it does. When I review someone’s pull request, empathy is what reminds me that there’s a person behind the code who put effort into it.
For user-facing work, empathy means going beyond the spec. It means asking “what happens when the user makes a mistake here?” and designing for that case. It means sitting in on a customer support call occasionally to hear how real people actually use what you built. In my experience, developers who spend even a small amount of time observing users write meaningfully better software.
Why This Matters More Now
With AI handling more routine coding tasks, the skills that differentiate strong developers are shifting. Writing a for-loop is no longer a competitive advantage. Communicating clearly, listening well, creating environments where people feel safe to do their best work, and building with empathy for users and teammates? Those are harder to automate, and they matter more than ever.
I don’t think soft skills are a nice-to-have that sits next to your technical skills. I think they’re the multiplier that determines how effective your technical skills actually are. A developer with strong technical ability and poor communication creates bottlenecks. A developer with solid (not exceptional) technical skills and strong soft skills makes everyone around them more effective.
If you want to invest in your soft skills, start with one. Pick the area where you’ve gotten the most feedback, or where you notice the most friction. Practice it deliberately for a month. I’d bet you’ll see the impact before the month is over.
Resources
- Project Aristotle: What Google Learned From Its Quest to Build the Perfect Team — Google’s research on psychological safety and team performance
- The Fearless Organization by Amy Edmondson — the definitive book on psychological safety
- Emotional Intelligence by Daniel Goleman — foundational reading on EQ for professionals
- What is a Code Review? — my earlier post on feedback and review practices
