“In the SE profession, technical work is always embedded in a network of communications” (Carter et. al, 2011).
Software Engineers need communication skills.
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 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 code commenting is quicker to parse. But we are human, after all, and we humans – most of us, anyway – are social creatures. And as social creatures, we try to use human language to communicate appropriately and effectively across a variety of contexts, in response to a variety of exigencies or situations.
With poor communication skills come consequences.
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.
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. Over time, this has negative consequences for both that novice engineer and shipping code.
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 their poor communication with artful communication by asking, “Can you explain that in simpler terms? I’m not fully tracking.” Her request 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.
There's a path toward developing 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 up: the rhetorical situation and rhetorical analysis
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 will feel well-equipped to help your SEs improve their communication skills, and consequently unlock their potential as engineers.