At the end of 2022, I spent hours upon hours chatting with my company’s engineering leaders as part of a technical upskilling needs analysis. My goal was to understand which skills our software engineers needed in order to execute on our company’s strategic technical objectives in 2023 and beyond.

During one of these conversations, a leader voiced the need for our engineers to develop better communication skills. Another leader disagreed with this view, stressing that what the engineers needed to focus on was the important work of writing code.

I had to play devil’s advocate, here. Engineers communicate with others as part of their jobs every day, whether that be through leaving code review comments, giving standup readouts, explaining technical concepts to non-technical audiences, communicating delivery delays, giving product demos, and the list goes on.

As in any profession, they’re not always good at it. The detrimental effects of ineffective communication in the software engineering domain have been publicly opined (and undoubtedly experienced by the reader). Therefore, finding a solution and explaining how effective communication works in a way that engineers can understand and appreciate is the way forward.

The solution: Build rhetorical awareness

Part of the challenge in communicating effectively is that it’s just not that easy. There exists a false belief that good communicators are born that way, that it’s effortless for them, that it just comes naturally. But effective communicators know better than anyone that crafting superb communication is hard work, that it entails complex cognitive processes and sophisticated analytic skills.

The good news is that software engineers deploy these complex cognitive processes and sophisticated analytic skills on a daily basis as part of their software work. I think we need to upskill software engineers in effective communication in a way that appeals to these analytic, compositional mindsets.

And there’s more good news here: We can draw from the literal millennia of discussion, theorization, and research around rhetoric and composition to teach engineers how to create effective communicative artifacts. Really, we should be teaching software engineers about rhetorical situations to help them understand how to effectively communicate in the specific, recurring situations they encounter.

SIDEBAR

Rhetoric can refer to language that is designed to have a persuasive or impressive effect on an audience, and it can also refer to the art of effective or persuasive speaking or writing.

What is a rhetorical situation?

For software engineers, we can utilize the rhetorical situation as a framework for strategically crafting communication so that it is effective with the intended audience. Lloyd Bitzer, a renowned American rhetorician and professor who taught from the 1960s-90s, is credited with introducing the concept of rhetorical situations in his 1968 essay “The Rhetorical Situation.” In introductory composition classrooms, the concept is typically described as “the situation in which communication occurs”, and is made up of five distinct elements. 

Let’s define and analyze each, and then look at ways engineers can think about these components when they’re communicating at work.

The text

When we refer to texts, we’re not talking about a text message sent on a phone. Text is a term used to refer to any communicative artifact. A novel is a text. A resume is a text, as is a presidential address. Sculptures, graffiti, and songs are all texts.

A text has particular features – like the style and tone of the language, or the format and length and organization, and even the place of publication – that distinguish it from other types of texts. In fact, we have an English word to categorize texts by these shared features – genre – which describes forms of communication created in accordance with socially agreed-upon conventions.

Software engineers regularly produce written and spoken texts in a variety of genres:

• Ticket descriptions
• Ticket comments
• Stand-up readouts
• Code commit messages
• Pull request descriptions
• Code review comments
• Sprint demos
• Customer demos
• Project updates
• Technical documentation
• Release notes

There are many genres that software engineers use to communicate, and when engineers fail to learn or abide by the socially agreed-upon conventions that define a genre, the result can be a breakdown in communication.

The author

The author is the person or people creating the text. Every text has an author or set of authors, and the attributes, background knowledge, biases, etc., of the author have an effect on the text.

Certain kinds of authors aren’t expected to produce certain kinds of texts. For example, a CTO at a large company is unlikely to author a code commit message, and an entry-level developer is unlikely to write a request for comments (RFC).

The intended audience

This is the audience that the author attempts to communicate with via the text. When an author constructs a text, they should have a very particular audience in mind, and the attributes, background knowledge, biases, etc., of that intended audience should influence the qualities of the text.

A principal or staff engineer should, for example, carefully consider the background knowledge and potential emotional vulnerability of the junior engineer when crafting code review comments on that engineer’s pull request.

The purpose

A text’s purpose is the thing the author is trying to achieve with the intended audience through the text. It is what drives the creation of the text. Authors typically start with a purpose, before they’ve made any other decisions about the text, including even the genre, and this purpose is oftentimes externally dictated.

For example, a principal engineer who has been asked to train other engineers on the use of a new service – the purpose – needs to ask themselves, “What is the most effective genre I can use to achieve this purpose with my intended audience?”

The context

Context encompasses the demands and environmental factors surrounding the text. That is, anything happening during the creation of the text that has some impact on it, whether that impact is on the author, the intended audience, the purpose, or the text itself.

Context generally informs purpose. For example, an engineer is unlikely to be asked to provide leadership with a daily progress update unless their work is at risk or has unusually high visibility.

How can engineers use rhetorical situations to their favor? 

Four of these five components – author, purpose, intended audience, and context – interact heavily with each other to influence and determine what shape that fifth component – the text – takes.

We need to teach engineers to apply their analytic skills to pinpoint the purpose, context, and intended audience. With this information, they will then be able to choose a genre and set of textual features that will help them most effectively achieve their purpose with that intended audience, within the constraints of the context.

To illustrate this, imagine your application is down for the count, unable to be used by customers. Typically, a small group will assemble in a war room to search for the problem. In that war room, the purpose of all communication (in this case, likely mostly verbal) is to summarize relevant and potential information that might highlight the issue causing the outage. The intended audience is every other person in that room, who are all likely deeply technical. This verbal communication – the texts, of which there will be many during troubleshooting – needs to be crafted very intentionally by the speaker – the author – to contribute to achieving the purpose in what is probably a stress- and pressure-infused context. If there’s a single person in this war room who is distracting from the main purpose by highlighting irrelevant “issues” in the codebase, cracking jokes, or trying to engage in small talk, it becomes much more challenging for everyone in the room to focus on finding the issue for the outage.

Now, imagine that the issue has been found, it’s been fixed, and it’s time to communicate to the wider organization what happened. Typically, a single person who was in that war room will be tasked with creating a write-up – the text – that explains the situation in detail, including the root cause for an audience that extends beyond those who were in that war room. This audience will comprise a mix of technical- and non-technical people, and thus the text – typically a post-mortem – will need to be crafted carefully to be accessible to that widely-defined audience. It should follow the genre conventions of a pre-mortem, for example, with great care taken around brevity and clarity.

Next steps for leaders

In my current position, I’ve led workshops for software engineers that introduce them to the rhetorical situation and encourage them to consider all of their communication in terms of interactions between author, audience, purpose, and context that ultimately determine what shape their communication – the text – should take to facilitate their successful communication. 

You can see the lightbulbs going off for them as they begin thinking about effective communication in these terms, so I recommend simply introducing your engineers to the concept, and guiding them in analyzing examples of instances of both effective and ineffective communication.