Your Software Engineers Do Need Communication Skills

“In the SE profession, technical work is always embedded in a network of communications” (Carter et al., 2011).

I recently spent hours upon hours talking with my company’s engineering leaders as part of an upskilling needs analysis. My goal was to understand which knowledge and skills our Software Engineers (SEs) needed to learn in order to execute on our company’s technical goals in 2023 and beyond.

During one of these conversations, one leader voiced the need for our SEs to develop better communication skills. A less-experienced engineering manager responded that he didn’t think so, actually. His engineers didn’t need to spend their valuable time learning how to communicate, he said. What his engineers needed was to focus on the important work of building things with code, of doing pure engineering work; engineering managers and product owners should be left to do the work of communicating. (The easy work of communicating, I felt he was implying.)

I had to play devil’s advocate, here. I’ve frequently felt exasperated by the shoddy communication skills displayed by my SE peers – managers and individual contributors alike. And so I asked this engineering manager:

Do your engineers not communicate with others as part of their jobs every day? Do they not regularly engage in code reviews, and do they not sometimes vex and alienate each other with poorly worded code review comments?

Are they not often asked to explain technical concepts, issues and delays to non-technical audiences, and do they not frequently leave these non-technical audiences confused, deflated or offended?

And these are just a couple of examples. I’ve experienced these communication “misses” many, many times before. Sometimes they’re merely aggravating, as in the case of a former teammate who consistently failed to recognize when everybody else on the call was ready – and in fact, had been ready for some time – to move on from non-work talk that was eating into precious time for planning.

Sometimes, though, these communication gaffes are downright exasperating. For example, I once had a colleague who refused to use conventional linguistic devices to hedge the intent of his code review comments.

A savvy communicator might leave a comment like:

Have you considered using a decorator here? This is Python best practice in this particular context. Let me know if you want me to write up a snippet to demonstrate how we might do that. (We also could make this constant a config variable, but that’s beyond the scope of this PR, so don’t worry about that if you’re wanting to get this through the pipeline.)

My colleague instead prefixed his (already exceedingly concise) comments with capitalized labels in order to mark his intent. In place of the above example, he might write something like:

CHANGE: Use a decorator here.
SUGGESTION: Move this var to the config file.

You might argue that this is a relatively innocuous example, and certainly, the latter method of commenting on code is quicker to parse. But we are human, after all, and we humans – most of us, anyway – are social creatures. As social creatures, we use human language to communicate appropriately and effectively across a variety of contexts, in response to a variety of exigencies or situations. Our failure to communicate appropriately and effectively in the SE domain can have consequences inimical to our ultimate goal of creating and shipping useful, reliable software.

Consequences of poor communication skills

Consider the above example code comments as if they were written for the audience of an entry-level software developer. Communication to this novice developer must do more than simply tell her what to do with the code. It must explain, instruct, guide, encourage, and above all, convey some amount of empathy around the very hard task of learning all the things one must know to move beyond the novice level. The way that code comments are worded has the potential to both encourage this novice coder, and to deflate her. Tactless comments have the power to discourage new SEs from asking questions, taking risks, and even showing their work to others.

Crude communication skills can also create discord between senior team members. I observed experienced SEs, for example, respond in frustration to the aforementioned engineer who opted out of using the established conventions of written English to collaboratively provide feedback. One senior SE delivering such blunt directives to another is a recipe for conflict. (And resolving conflict, of course, requires artful communication skills, and thus can we find ourselves in infinite loops of conflict.)

Sometimes, shoddy communication results in the kinds of massive misunderstandings that delay product deliveries, stress out product and engineering teams, piss off customers, and ultimately cost the company money. One of the best product owners I’ve ever worked with consistently refuses to accept SEs’ opaque, overly technical explanations for why a delivery deadline is under threat. She counters poor communication with artful communication by asking, “Can you explain that in simpler terms? I’m not fully tracking that.” This typically results in explanations that actually make clear to everyone why a delay is warranted, as well as allow others to troubleshoot and propose solutions to get the deliverable back on track.

Addressing poor communication skills

I imagine that you, the reader, are nodding your head here, lips pursed. You might even be shuddering at the times that you were the perpetrator of costly miscommunications. I know I’ve been that person on more than a few occasions.

Sometimes, poor communication happens intentionally. Sometimes SEs communicate with the intent of pissing off a teammate or confusing a product owner. These people need edification of a different sort.

But many software professionals do want to become more effective communicators. The question then becomes how do we accomplish this?

Countless written and video tutorials exist, many with uninvitingly vague titles like The Pillars of Effective Communication and Interpersonal Communication. But these general communication courses frequently peddle in trite axioms devoid of context or real-world examples.

Or, they provide advice and strategies that provoke eye rolls. Tell an SE that if only she focuses on her presence, mental state, and physical self-awareness, she’ll be able to write effective Requests for Comment (RFCs), and she will roll her eyes at you. And rightly so.

So, then, how do we enable our SEs to be better communicators? I believe that the best way is to appeal to their analytic, compositional mindsets – those same mindsets that enable them to write and analyze code. And I believe that the best way to appeal to those analytic, compositional mindsets is to teach them how to analyze the composition of communicative artifacts. We should teach SEs about rhetorical situations, and the elements of rhetorical situations that interact to produce communicative artifacts: author, intended audience, text, purpose, and context.

Through teaching SEs about those elements that comprise communication – as well as how to analyze the situations that warrant communication – we can help them understand how to effectively respond to the specific, recurring situations they frequently encounter as SE professionals that require them to communicate. We can teach them how to be better communicators.

Next Steps for the Engineering Leader

I hope that this convinces you of the need for SEs to be master communicators, and that there is a path forward here through teaching about rhetorical situations.

In the second part of this three-part series, I’ll describe in great detail the concept of rhetorical situations and each of the elements that comprise it. We’ll look at multiple examples of texts (communicative artifacts) that are commonly produced in the SE domain.

In the third part, we’ll use this knowledge to engage in rhetorical analysis, examining texts for their rhetorical effectiveness.

My hope is that after moving through this series, you as an engineering leader feel well-equipped to help your SEs improve their communication skills – and possibly even your own!

Analyzing Software Engineering Texts for Rhetorical Situations & Effectiveness

Why should we care about rhetorical situations? Because understanding a text’s rhetorical situation allows us to analyze its rhetorical effectiveness. As Carter et al. (2011) point out: “The effectiveness of each communication depends on its success in responding to the particular situation in which it occurs.”

We can conduct something called a rhetorical analysis in order to assess that speech or writing’s rhetorical effectiveness.

Take the following for example:

Okay, now that we’ve described this text’s rhetorical situation, we can begin to make evaluations as to its effectiveness (or, ineffectiveness). Here, we’re essentially asking: Did the author achieve her purpose with her intended audience? Why or why not?

Creating Software Engineering Texts with The Rhetorical Situation in Mind

Once we become adept at understanding and analyzing texts for rhetorical effectiveness, we can begin creating our own texts that much more effectively achieve our intended purposes with our intended audiences.

Conclusion

Some believe that all communication is persuasion, and when we approach the consumption and creation of textual artifacts through the lens of rhetorical situations, this doesn’t take much stretch of the imagination to support.

References