Leadership communication becomes increasingly important as developers move beyond writing code and begin leading people, projects, and technical decisions. Being the smartest person in the room does not automatically make you the most effective leader. In fact, technical expertise can sometimes work against a team when the people with the strongest opinions dominate the conversation while everyone else quietly checks out.
In this episode of Develpreneur, Rob Broadhead and Michael Meloche talk with leadership communication coach Salvatore Manzi about what happens when developers and technical experts move beyond writing code and begin leading people. The conversation focuses on learning how to make sure people understand one another, contribute their ideas, and work together instead of simply talking past each other.
About Salvatore Manzi
Salvatore Manzi is a leadership communication coach whose work sits at the intersection of leadership, communication, and collaboration. He works with teams and analytical professionals to improve how they communicate so they can collaborate more effectively and move their ideas forward.
Salvatore is also the author of Clear and Compelling: Communication Strategies for Big Thinkers. During the Develpreneur interview, he explained that the book draws on twenty years of communication strategies and is aimed particularly at analytical, technology, and data-driven professionals with bold ideas.
His work fits closely with the theme of this season of Develpreneur: building a career beyond the code. Technical knowledge can help you develop the idea, but leadership communication helps you explain it, build support for it, and bring other people along with you.
Social: Facebook / YouTube / Instagram / LinkedIn
Website: Salvatore Manzi’s Website
Leadership Communication Starts With Understanding
Technical professionals are trained to process information quickly. Someone explains a problem; our brains immediately start analyzing it. This happens even before the other person has finished speaking; we may already be constructing a solution.
That speed can be useful when solving technical problems. It can also create problems when working with people.
Salvatore recommends starting disagreements with shared understanding. Before offering your own response, rephrase what you believe the other person said and confirm that you understood it correctly. The purpose is not to repeat their words back to them. It is to demonstrate that you understood the idea behind those words before adding your own perspective.
For developers, this can initially feel inefficient. If everyone in the room understands the technology, why repeat something that was just said? Salvatore argues that this small investment in leadership communication can prevent much larger problems later. Rephrasing establishes a common starting point, particularly when people are working together for the first time or discussing an important decision.
A simple way to develop the habit is to practice it once each day. Find one conversation where, instead of immediately responding, you rephrase what you heard and ask whether you understood correctly. Over time, that intentional pause becomes part of how you communicate.
Get Your Voice Into the Meeting Early
The opposite communication problem happens when someone has something useful to contribute but waits too long to speak.
This is common on technical teams. When one or two people are viewed as the experts, everyone else may wait for them to speak first. Once those people begin driving the conversation, it becomes increasingly difficult for quieter team members to enter it.
Salvatore recommends getting your voice into the meeting within the first five minutes. You do not need to make a profound statement or immediately solve the problem. Ask a question, acknowledge someone else’s contribution, or invite another person into the discussion. The goal is simply to become an active participant instead of a passive observer.
That advice applies especially well to developers who prefer to process information before speaking. Waiting until you have the perfect answer can mean never entering the conversation at all.
Leadership can make that problem easier or harder.
Leadership Communication Means Creating Space for Everyone
A leader’s responsibility is not simply to provide the best answer. Effective leadership communication also means creating an environment where the team can produce better answers together.
Salvatore suggests several practical techniques for getting more people involved. One is a quick round-the-room check-in where everyone provides something that is going well and something that could be going better. The important part is establishing limits, such as one sentence for each answer, so the exercise does not turn into a series of monologues.
Another technique is the 10-second rule. Ask the team a question, but tell everyone that nobody should answer for ten seconds.
That short silence gives analytical team members time to process the question. Instead of rewarding whoever can speak fastest, the meeting gives everyone a chance to formulate a useful response.
These techniques are simple, but that is part of their value. Improving team communication does not necessarily require a new platform, complicated process, or another meeting. Sometimes it requires changing the way an existing conversation is structured.
Stop Putting People on the Spot
There is also a significant difference between inviting someone into a conversation and suddenly calling on them.
Anyone who remembers being unexpectedly called on in school knows the feeling. Instead of thinking about the question, your brain suddenly starts thinking about the fact that everyone is looking at you.
Salvatore demonstrated a better approach during the conversation: give the person advance notice that you are coming to them, tell them the subject you want them to address, briefly move the group’s attention elsewhere, and then return to them.
That small handoff gives the person time to prepare mentally. Instead of creating a performance test, the leader creates an opportunity for the person to contribute.
This is particularly useful for technical teams where some members may need a few moments to organize a complex answer. The goal is not to eliminate spontaneity. It is to stop confusing fast responses with valuable responses.
Breaking Down Technical Silos Through Better Communication
Technical organizations naturally create specialists. One person understands the database. Another understands infrastructure. Someone else knows the business rules, testing process, user interface, or deployment pipeline.
Specialization helps teams solve difficult problems, but it can also create silos.
Salvatore described working with a team whose individual groups functioned effectively but struggled when they came together. They were essentially speaking different languages. During a half-day session, the team worked through what they needed from one another and what they believed they were hearing from each other. They also formed smaller cross-functional groups.
One surprisingly effective part of the exercise was asking people to begin by identifying something they appreciated about another person’s work. That forced team members to think about what their colleagues actually contributed rather than seeing only their own piece of the system.
That lesson matters in software development because it is easy to judge another role by how it affects your own work. Developers can become frustrated with QA. QA can become frustrated with developers. Technical teams can become frustrated with business stakeholders, while business stakeholders wonder why seemingly simple requests take so long.
Good leadership communication helps people understand those different perspectives. Understanding what another person contributes does not eliminate disagreement, but it gives that disagreement context.
What About the Person Who Never Stops Talking?
Creating space for quieter voices introduces another challenge: the person who takes too much of that space.
Most teams have experienced the meeting where someone gets the microphone and never seems to give it back. Salvatore recommends addressing this before it becomes a problem by establishing communication agreements for the team.
Those agreements might include:
- Make sure every voice has an opportunity to contribute.
- Keep individual contributions short.
- Lead with the bottom line.
- Provide additional detail when the group needs it.
Once those expectations are established, a phrase such as “bottom line” can become a shared reminder rather than a personal criticism. Everyone already understands what it means and why the team uses it.
That distinction is important. Good meeting facilitation is not about silencing people. It is about managing the limited amount of attention and time available so the entire team can participate.
Leadership Communication and the Move From Expert to Leader
One of the biggest career transitions for developers is moving from being responsible for your own technical output to helping other people produce results.
The skills that made you a strong developer do not disappear when you become a technical lead, architect, manager, or executive. However, they are no longer enough by themselves.
You have to listen differently. You have to recognize when someone has stopped participating. You have to create room for people who need time to think while keeping stronger personalities from consuming the entire conversation. Most importantly, you have to stop measuring leadership communication by whether you successfully said something and start asking whether the other person actually understood it.
Salvatore’s advice throughout this conversation comes back to small, repeatable behaviors. Rephrase someone’s idea once a day. Speak within the first five minutes of a meeting. Give people ten seconds to think. Prepare someone before handing them the conversation. Establish expectations before someone starts monopolizing the room.
None of those techniques requires a major organizational transformation. They require practice.
That is also what makes them valuable for developers working to build a career beyond the code. Leadership does not suddenly begin when someone gives you a management title. It develops through the way you communicate, listen, facilitate, and help the people around you contribute their best ideas.
Stay Connected: Join the Developreneur Community
👉 Subscribe to Building Better Developers for more conversations on momentum, leadership, and growth. Whether you’re a seasoned developer or just starting, there’s always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let’s continue exploring the exciting world of software development.