When Words Don’t Come Easily
Dev Leader Weekly 95
TL; DR:
Not everyone is outspoken
When Words Don’t Come Easily
Supporting Different Communication Styles in Software Engineering
We don’t talk enough about how engineers communicate differently, and more importantly, we don’t talk about what that means for how teams function day to day.
Some developers speak confidently in meetings. They think out loud, jump into live debates, and steer conversations on the fly.
Others? They go quiet in real-time settings. They need space to process, time to digest, and structure to formulate their thoughts.
Does one of those sound more or less like you?
It’s not about seniority. It’s not about capability. It’s communication style -- and how teams accommodate (or fail to accommodate) those differences matters more than most people realize.
In this issue, we’ll break down what happens when communication styles clash in meetings, how to better support engineers who might find that they excel in writing but struggle in verbal exchanges, and what actionable steps leaders and teammates can take to make collaboration more effective for everyone.
You can watch the Code Commute vlog entry on this topic from earlier in the week:
Communication is a Skill But Also a Style
We spend a lot of time in tech talking about code quality, system design, and velocity. But so much of our day-to-day work comes down to one thing: effective collaboration.
And collaboration doesn’t just happen. It requires communication.
Some engineers are energized by live discussion:
Whiteboards
Brainstorms
Open-ended meetings.
Others thrive in writing:
Thoughtful comments
Carefully edited documents
Asynchronous back-and-forth.
Both styles bring value. But when one is disproportionately rewarded or accommodated, teams start to lose out.
And here's what often gets overlooked:
Developers who don’t “think out loud” may seem disengaged in meetings
Junior engineers may hesitate to challenge ideas without time to prepare
People with high written clarity often feel rushed or drowned out in fast-paced discussions
Valuable contributions are delayed -- or never shared at all
It’s not about who’s louder or quicker. It’s about creating enough structure to include different types of thinkers in the process.
The High Cost of “Just Jump On a Call”
Here’s how this often plays out in practice.
You’ve been invited to a 30-minute meeting. The title says “Design Sync” and the body of the invite is blank. You join, and someone starts presenting a new system, diagrams and all -- but you’ve never seen it before.
You’re supposed to respond on the fly, share feedback, ask questions, and help unblock the design. You don’t even know what problem it's solving yet.
This isn’t even hypothetical. It’s how many engineers are expected to operate. And it’s completely broken for anyone who:
Needs to process details independently first
Feels overwhelmed when data is presented live with no prep
Prefers written over verbal communication
These engineers aren’t underperforming. They’re unsupported.
Why This Matters for Engineering Teams
You might be thinking, “Well, this is just how the industry works -- people should adapt.”
But the cost of ignoring communication style diversity shows up in subtle ways:
Silent meetings where only a few voices dominate
Underutilized talent from teammates who prefer writing or async collaboration
Slower decision making because not everyone had the chance to process and weigh in
Frustration from engineers who feel overlooked or unheard
As a manager, you’re not just responsible for shipping code. You’re responsible for making sure your team can contribute effectively.
As a senior engineer, your impact will be held back if you're unable to get others effectively rallying behind your work. If they can't collaborate effectively with you, it's going to feel like friction.
You wouldn’t design systems that only scale under perfect conditions. Don’t design communication processes that only work for the fastest talkers.
Actionable Tips: How to Support Written-First Communicators
You don’t need a personality test or a formal framework to recognize who on your team prefers writing over real-time conversation. Just watch how they engage.
And then -- make it easier for them to thrive.
1. Always state the goal of the meeting
If you can’t explain why the meeting is happening, you’re not ready to have it. Put the objective in the calendar invite. Not a vague label -- a real, useful description:
✅ “Finalize decision on DB sharding strategy”
❌ “Sync on storage”
This helps everyone, but especially people who need to mentally prepare to contribute.
2. Send material in advance
If there’s data, a design doc, a decision framework -- anything that will be discussed -- send it before the meeting.
Even 24 hours notice is enough to give people time to form opinions, ask sharper questions, and avoid wasting time in the actual meeting.
Don’t just hope people will “skim it live.” That’s a sure way to exclude those who need time to reflect.
3. Carve out async space for feedback
Not every contribution needs to happen in the room.
Add a comment section to design docs. Leave Slack/Teams/Whatever threads open after a discussion. Let people follow up -- and treat that feedback with the same respect you give live discussion.
“If it wasn’t said in the meeting, it doesn’t count” is a terrible rule.
4. Default to fewer, better-structured meetings
A meeting with no agenda is a red flag. Seriously.
I encourage anyone to push back on getting a meeting invite with no agenda or clear goal.
And not everything needs to be a meeting. If a document can do the job better, let it. If a chat can do the job better, let it.
Written discussions allow more people to participate -- and at their own pace.
If you must meet, make the most of it:
Set context at the start
Leave time for reflection
Take notes and share outcomes
5. Follow up with quieter participants
Some engineers have incredible ideas they just can’t articulate quickly in front of others.
That doesn’t mean they lack value -- it means they need space.
Try this:
“Hey, I noticed you were quiet in the meeting -- anything come to mind after the fact that you want to share?”
This signals that their voice matters. It also builds trust -- and makes them more likely to speak up next time.
Bonus: How Individuals Can Advocate for Themselves
If you're someone who struggles in live discussions, you don’t have to just accept that.
Here’s how you can make your needs known without being difficult:
Ask for context before meetings:
“Would it be possible to review the doc before we meet so I can give better input?”Offer follow-ups in writing:
“I didn’t have time to fully form my thoughts in the call -- mind if I send a few notes after I process?”Request clarity when it’s missing:
“Can we align on the meeting goal so I know how best to prepare?”
You’re not being high maintenance. You’re trying to do better work.
Design for Range, Not Uniformity
High-functioning teams don’t just optimize for the loudest voice or the fastest thinker. They create space for diverse strengths to shine.
If someone processes verbally -- great. Give them airtime.
If someone processes in writing -- great. Give them time.
You don’t have to force everyone into the same mold.
But you do need to create a system that lets everyone contribute at their best.
That’s how you build a stronger team.
Final Thought
Some of the most valuable technical thinkers I’ve worked with weren’t the first to speak up. They weren’t the ones who dominated meetings. They were the ones who sent a doc after the fact that reframed the whole problem. They were the ones who followed up on an email thread with their different perspectives.
If you’re leading a team or a project, build systems that surface that value -- don’t bury it.
And if you’re someone who communicates better in writing? You're not falling behind. You're just operating differently.
Keep speaking up -- even if it takes a few extra minutes to type it out.
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