CTO Fraction

Diverse team of software developers, including women, discussing project updates with a CTO in a modern office setting, emphasizing clear communication and understanding.

Leadership: Communication With Developers

Leadership and management communication with software developers involves more than just relaying information; it requires empathy, clarity, and a deep understanding of how developers perceive and interpret your messages. As a CTO, VP of Engineering, or a Software Engineering Manager, understanding how to communicate with your development team is quite critical.

In this article, I share personal stories, lessons, scientific evidence, and suggestions for improving your communication with your software engineering team.

 

Understanding Developer Perception in Leadership Communication

One of the key challenges in leadership and management communication with developers is understanding how your messages are perceived. Developers often interpret managerial inquiries and feedback through their own filters, shaped by their experiences, expectations, and the pressures of their work environment. This can lead to misunderstandings and unintended stress.

Studies have shown that perception is influenced by various cognitive biases and prior experiences. For instance, developers might hear a simple status update request as a critique of their efficiency or a signal of dissatisfaction. This phenomenon is known as perceptual filtering, where the brain uses past experiences to interpret current stimuli. In the context of leadership communication, this means that your well-intentioned questions might be perceived as micromanagement or criticism.

 

Personal Story 1: Leadership Communication with Developers

Years ago as the VP of Engineering in a SaaS company, I would regularly review all of our team’s progress and ask questions when something did not make sense to me, or a particular story and/or feature seemed to be taking a long time. My goal was to stay informed, identify blockers early, and help the teams move forward whenever they got stuck. Additionally, having been responsible for 5 separate delivery teams, I often had to coordinate multiple efforts. Knowing when we expected certain efforts to end was knowledge I needed to make the right decisions.

It was not uncommon for me to send an instant message to a software developer and have an informal chat such as this one:

Me >> “Hey Jon, do you know how much work is left on story US287? I am trying to get a rough sense of when you will be done with it, as I need to make some decisions.”

Developer >> “I have figured out all the issues with but am working on one last one. Unless I run into anything unexpected I should be wrapping up by the end of the week.”

Me >> “Cool, thanks. Let me know if you run into any additional issues and end up needing more time to finish”

To me this was a quick and casual conversation. I got the information I needed, and connected with the engineer on my team without taking too much of their time.

What I didn’t know was how my “innocent” question was interpreted inside the head of the engineer. What they often heard was:

  • “Hurry up, you are not moving fast enough.”
  • Or, “You are taking longer on this effort than you should be.”

I only found this out when a senior engineer shared with me at a later point how my questions sounded to an engineer. This was a surprise because my intention was not at all to communicate what they heard. I was sincerely looking for information.

 

Personal Story 2: Management Communication Challenges with Developers

The second story happened at the same company as the previous story. One day I was instant messaging with a Product Manager, who needed to know when a particular infrastructure task would be complete, so that he could make some prioritization decisions.

“Let me reach out to our platform engineer real quick and I will let you know”, was my reply to him.

Then I proceeded to send a chat question to the particular platform engineer, responsible for this specific task. My question was similar in nature to the one I mentioned in the previous story.

Instead of getting an answer with a rough idea of the remaining effort, I received an angry an emotional response, which paraphrased, sounded like this:

“I am doing the best I can right now. There is no need for micromanagement. I don’t know why you are riding my a$$ and putting pressure on me. I am getting really tired of this…” and on and on.

 

What is said is not what is heard: The Science Behind Communication and Perception

Studies have demonstrated that people perceive information through filters shaped by their personal experiences and prior beliefs. This phenomenon is evident in various areas of perception and cognition.

Perceptual Filtering: One notable example is the differing perceptions of the viral “dress” image, where people saw the same dress in different colors based on their life experiences with lighting. Research by Pascal Wallisch found that people’s chronotypes (whether they are night owls or early risers) influenced their perception of the dress colors, illustrating how prior experiences with lighting conditions can filter visual perception​ (Stanford University)​.

Expectation and Perception: Studies from MIT highlight how our brain uses prior experiences to interpret current stimuli. This process, known as Bayesian integration, means that our brains use past experiences to fill in gaps when faced with uncertain information. For example, if an animal or person expects a certain time interval based on prior experiences, their perception and behavior will be biased towards those expectations​ (MIT News)​.

Confirmation Bias: This cognitive bias involves people favoring information that confirms their preexisting beliefs and disregarding evidence that contradicts them. Confirmation bias can lead individuals to interpret ambiguous information in a way that supports their current beliefs, often unconsciously. This bias affects how people gather, interpret, and recall information, reinforcing their existing views regardless of contradictory evidence​ (National Library of Medicine)​.

Are you facing difficulties in effectively communicating with your development?

Many tech company leaders encounter these issues, which can hinder growth and relationships. My Fractional CTO services offer a flexible and cost-effective solution to these problems. I can help with strategic guidance, process optimization, or hands-on support. By leveraging my experience, you can focus on what you do best—leading your company to new heights.

The Rest of the Story

In both of my personal stories above I had a choice to make. Yes, I was very surprised by the feedback.

In the first story, I couldn’t understand why my “innocent” and straightforward question brought anxiety to my team. But then I placed myself in their shoes and was able to understand and see their view point. So i decided to do 2 things:

  1. I addressed the entire engineering department in our next all-hands and explained that: a) I was now aware of how my questions impacted the team. b) I would do better in the future by providing more context of ‘why’ I was asking in the first place and would also explicitly let them know if something needed to move faster.
  2. I changed my language when I needed to know the status of any work and became intentional to communicate why I was asking and reassure them that I was not implying anything about their performance.

 

In the second story, I was in shock to get the response that I received. I could have responded with emotion also. However, it was evident to me that there was more below the surface, and that my question was being widely misinterpreted. Therefore, I asked the platform engineer if we could hop on a quick call, so I could explain. A few minutes later we spoke by phone and I explained the whole story: how the product manager reached out to me, and how this was the reason for my question – it had purely been information seeking to allow someone to make better decisions. I also explained that I had meant nothing implying the performance of the engineer. He quickly turned around and saw how he had overreacted, and then followed with multiple apologies. In that conversation I also learned that this person had come from a very different work environment, where trust was absent and constant pressure was the norm.

 

Bridging the Gap in Leadership & Management Communication

“It doesn’t matter what is being said. What matters is what is being heard?”

A few months ago I was speaking with a counselor who told me: “It doesn’t matter what is being said. What matters is what is being heard?”

I have experienced this in my professional life, in my personal life, and science also demonstrates it. The question is – as leaders and managers, what are we willing to do about it?

Are we going to complain that people don’t get what we are saying, or are we going to accept this as something that happens often and try to do better in our communication?

Here are some actionable steps for leaders and managers to help ensure that what is said is actually what is heard:

Be Clear and Contextualize: Always provide the context behind your questions or requests. Explain the ‘why’—why you need the information, how it fits into the bigger picture, and what decisions it will influence. This helps in reducing misunderstandings and anxiety among team members.

Empathize and Listen Actively: Place yourself in the shoes of your team members. Understand their pressures, workload, and perspective. When you ask questions, do it with empathy. Listen actively to their responses and validate their feelings.

Invite Feedback: Make your team members feel comfortable and safe to express their concerns and misunderstandings without fear of repercussions. Encourage them to ask for clarification whenever needed. Also, encourage them to speak up their mind, and when they give constructive feedback, do not defend but listen.

Model the Behavior: As a leader, your behavior sets the tone for the team. Model the communication practices you want to see in your team. Show transparency, empathy, and clarity in all your interactions.

Adapt Your Style: Recognize that different team members might have different communication preferences. Some might prefer direct messages, while others might need more detailed explanations. Adapt your communication style to fit the needs of your audience.