The Gap Between Good Developers and Great Ones
Dev Leader Weekly 130
TL; DR:
Communication responsibility lands on you, not your audience
Think from their perspective -- not yours
Metaphors bridge the technical and non-technical gap
No livestream this week, sorry!
The Real Gap Between Good Developers and Great Ones
I’ve come to believe that the biggest gap between good developers and truly great ones isn’t technical skill. It’s communication. Specifically, the ability to communicate technical ideas to people who don’t share your technical context. I talk about this topic a lot across different videos and articles, and there’s a reason for that -- I genuinely think communication is at the heart of most of the problems I see in software engineering. Sure, we’re solving technical challenges every day. But the real blockers? The frustration, the missed deadlines, the misaligned expectations? Those almost always trace back to a failure to communicate effectively.
You can check out my full thoughts on this in the video below:
The Responsibility Is On You
Here’s the uncomfortable truth: when you’re trying to communicate information, the responsibility for doing it effectively falls on you. Not on your audience.
I see this go wrong all the time. Someone’s trying to explain something technical, it’s not landing, and the reaction is “well, maybe they’re just not getting it” or “I don’t know why they can’t understand this.” We look outward for the problem. But when you’re the one trying to share information, how well it lands is your problem to solve.
Now -- to be clear -- this goes both ways in a conversation. If someone is communicating back to you, they have responsibility on their side too. But when you are the one trying to convey an idea? That’s on you. And I think accepting that is genuinely liberating, because it means the outcome is something you can actually influence.
Know Your Goal -- And Theirs
Before you walk into any conversation with a non-technical stakeholder, ask yourself: what am I actually trying to accomplish here? And I don’t mean “explain a technical thing to a non-technical person.” I mean the actual goal. Are you trying to justify why something is going to take longer than expected? Are you communicating why technical debt needs to be addressed? Are you giving a post-incident readout to someone who then has to relay it upward to leadership?
The goal frames everything.
Actionable Tip: Write down the one thing you want your audience to walk away believing or understanding after the conversation. If you can’t state it in a sentence, you probably need to keep refining your thinking before you open your mouth.
Once you know your goal, here’s the secret: stop thinking about it from your own perspective. Flip it around. Think about what your audience cares about. What matters to them in their role? A project manager cares about different things than a UX designer, who cares about different things than a VP of Engineering. Yes, there’s overlap -- hopefully everyone cares about the customer -- but the lens through which they see the world is different. And the more time you spend with people in different roles, the better your intuition gets for what they’re going to gravitate toward and what’s going to lose them.
Levels of Indirection Kill Technical Detail
Let me use an example. Say there was an incident -- a bug in production. Things were mitigated, code fixes went in, your team worked hard on it. You understand the changes inside and out. Now you need to brief your engineering manager, who then has to represent your team to senior leadership.
This is a double-whammy situation. You need to communicate to your manager in a way they’ll understand, and arm them with enough information that they can relay it one more level up, to people even further removed from the technical details.
Here’s what typically goes wrong: engineers walk in and start talking about the specific class that had the duplication, the if statement on line 37, the test project that was accidentally excluded from CI/CD. And the manager nods along, maybe, but now they’re expected to take that information and translate it for a VP or an executive. That doesn’t work. The more levels of indirection involved, the more the specific technical detail actually hurts rather than helps.
So what does your manager actually care about in this scenario? They want to know systematically what’s now in place. They want to understand that you’ve got testing coverage where there were gaps. That you have monitoring and alerting. That you’re leveraging the tools available to you. They don’t need to know exactly how many tests you added -- they need to know that the gap in coverage has been closed.
Actionable Tip: One exception: if there’s a single specific detail that is the “smoking gun” -- the one thing that explains why the incident happened -- it’s okay to bring that in even to a non-technical audience. I’ve been in executive-level post-mortems where the right answer was “we had all the right things in place -- monitors, tests, staged rollout -- but this one alert had the wrong threshold, and that’s why we missed it until traffic built up.” That’s concrete, understandable, and builds confidence. Use the smoking gun detail when it exists.
Metaphors Are Your Secret Weapon
So, how do you actually make your communication land? One of the most effective tools I’ve found is metaphors and comparisons. I don’t have a neurological explanation for why this works so well -- but it does. I think it has something to do with how our brains recognize patterns and anchor new concepts to things we already understand. When you can explain something by mapping it to a frame of reference the other person already has, it clicks in a way that a direct technical explanation just doesn’t.
Here’s an example I worked through. Imagine you’re talking to a UX designer. You need to explain that a design change they want is going to be much more complicated to implement than it looks, because the codebase has a lot of duplication -- many places that would all need to be updated individually.
From their perspective, they’re thinking: just go make the change in those spots. What’s the big deal?
Instead of explaining code duplication, try this: ask them to imagine they’re working in their design tool, but without any shared component library. No reusable buttons, no pre-styled elements -- everything is custom-drawn per screen. Now, imagine I asked them to change every button to have rounded corners. They’d have to click through every single design and make the change by hand -- and might not even be sure they’d found all of them.
That’s what I’m dealing with in the code.
Suddenly, they get it. They can feel why that’s painful. You mapped the technical problem to something they live every day. That’s the power of a good metaphor -- once you find the right one, the conversation shifts entirely.
The tricky part is that building good metaphors takes effort. You need to actually know something about the other person -- their role, their tools, what they care about. The more time you invest in understanding the people you work with, the better your instincts get for what will resonate.
Start With the Framework, Not the Steps
I want to be honest: I could give you a step-by-step checklist for communicating with non-technical stakeholders. But I deliberately didn’t go that route here. I think it’s more valuable to understand why the approach works than to follow a script. If you understand that your goal drives your framing, that thinking from their perspective matters more than your own, and that making ideas tangible through metaphors is incredibly effective -- you can adapt that to any specific situation you find yourself in. You’ll develop your own style, your own instincts, your own go-to examples.
That’s going to be better than any step-by-step I could ever write for you.
If you’ve got a specific communication scenario you’re wrestling with, head over to CodeCommute.com and submit it! I’m happy to work through the specifics. Talking about this generically can only go so far -- the real value is in concrete situations.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!