Communication really is a technical skill
Most engineering job descriptions draw a hard boundary between the set of competencies referred to as technical skills versus those known as communication skills. The former tend to denote expertise squarely associated with the design and implementation of software, leaving the latter to imply the skills necessary to circulate information throughout that process.
Communication skills allow an individual to understand and be understood. They combine self-awareness, empathy, active listening, speaking and observing into a cocktail of abilities that grease the wheels of every interaction, but often go undetected. Dissociating communication and technical skills, while seemingly innocuous and even pragmatic, can create a harmful dichotomy, one that stunts corners of the industry.
Communication Is a Technical Skill
This is a false dichotomy because communication is a technical skill. The ability to articulate complex ideas is a hallmark of deep understanding. Technical skills, without the accompanying ability to form coherent descriptions of what purpose they serve, are just calisthenics without orientation.
Yet this separation gives decision-makers a convenient binary upon which to base judgments, resulting in quick mental shortcuts and coarse-grained categorizations applied to complex problems. This ultimately prevents a more thoughtful approach to hiring, promotion, and performance evaluation decisions.
The distinction blurs in practice, given most software engineering roles overwhelmingly depend on the movement of ideas and the justification of decisions. The coexistence of these interdependent skills makes their decoupling feel artificial, especially for anyone well-acquainted with the day-to-day reality of shipping code with any non-trivial level of complexity or scale.
While separating definitions can help enforce nuance and bring clarity to role requirements, this particular division remains stark. It insinuates a broader gap between the two than is genuinely representative of the work. Worse yet, this dichotomy tends to inflict a social and economic hierarchy that undervalues contributions, inhibiting the softer side of the skill spectrum, and punishes those who communicate well with the bias of being read as “less technical.”
Placing the Burden of Communication on Unpaid Emotional Labor
When conversations regarding unpaid emotional labor entered mainstream consciousness a few years ago, they quickly took on several industry-specific expressions. In tech, and specifically within the engineering discipline, much of the discourse focused on women shouldering a disproportionately large burden of non-technical work relative to male peers, which inevitably subtracted time, attention, and energy from opportunities more technical in nature.
Another manifestation of unpaid emotional labor results in women being shuttled off to “people-oriented” positions, or frequently being commended not for their code or technical leadership, but instead for their empathy, project management, collaborative spirit, and smooth navigation of difficult and tenuous social situations. In other words, they are commended for having to deal with the debris of leftover chaos they usually didn’t create, nor had very much control over.
The topic of gendered emotional labor deserves a more rigorous analysis than what a hurried blog post can do justice to, and there are several cultural and systemic reasons communication skills are de-emphasized as a core engineering competency. Yet I can’t help but wonder if the soul-sapping phenomena of unpaid emotional labor would be as severe if competent communication was not some chore left for certain socially predisposed groups to do, but instead acknowledged as an equally necessary and important part of the software development lifecycle.
If the aggregate communication skills of technical teams improved — making empathy, active listening, and clarity as necessary as technical work — perhaps the gaps currently filled by the invisible work of unpaid emotional labor would start to close.
Why Communication Skills Are Especially Important in Technical Disciplines
While communication skills are generally useful, they become especially important in STEM fields and more specifically in software engineering disciplines for the following reasons:
1. Lexical double-booking
As Jordan Ellenberg shows in “How Not to Be Wrong: The Power of Mathematical Thinking,” one incredible source of confusion arises from words having a different meaning in English than in a domain-specific context. The underpinnings of software can be traced, sometimes less directly, to fields in mathematics and computer science. The jargon that emerges from these worlds doesn’t always mirror commonly used English vernacular.
For example, to any typical Anglophone, the word significance alludes to something being essential or substantial. However, in statistics, significance refers to the rejection of the null hypothesis and, more specifically, to the p-value being some non-zero value. In the context of clinical trials, a drug’s effect may be statistically significant, in that it is non-zero, and still have no detectable consequence. But the way this significance gets marketed and reported to consumers who may be unaware of this difference can distort the impact of the drug, leading to erroneous conclusions and predatory advertising.
Another example of this sort of linguistic confusion involves the words parallel and concurrent. While synonymous in English, these words hold distinct, albeit related, definitions in programming. A parallel program is one in which several hardware units (multiple processor cores) are employed to perform a computation faster than is possible with a single machine. By comparison, a concurrent program executes the computation on a single processor but is structured in such a way that tasks within the program are split across multiple threads of control. Concurrency lets computations sharing some dependency occur asynchronously, interleaving the results.
Similarly, Merriam-Webster doesn’t necessarily define an object as an instance of a class, nor will a group be defined as elements that share the mathematical property that any pair of things within a pair can be combined into a third entity.
While the use of these terms is usually implicitly clear within the context where they’re invoked, important details can still get lost in translation when industry experts fail to check their assumptions or ensure everyone has a shared understanding of what terms mean.
2. Programming is about humans
The design of abstractions, libraries, and languages doesn’t depend on technical correctness and performance alone, but also as they relate to the native intuition of humans. This necessitates keen curiosity around the diverse ways information may be interpreted.
No better quote comes to mind than the following by Donald Knuth, where he speaks of programs not as a form of communication between the author and the machine, but between the author and another human who will read the code:
“Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.” — Donald Knuth, Literate Programming
3. Problem-solving versus acrobatics
In a stodgy-looking book published in 1983 titled “High Output Management,” Andy Grove describes a phenomenon he calls activity over output, referring to what happens when a lot of busy-work accompanies no real outcome. This classically represents the theme underlying fruitless yak-shaves, code golf, or infinite pursuits focused on reshaping peripheral edges of programs that distract from goals that have higher priority and impact.
Unfortunately, in most cases, dense, incomprehensible jargon tends to be conflated with technical aptitude. In September 2018, I attended ICFP. Among the most memorable talks was one given by Eugenia Cheng on the power of abstraction. She discussed the difference between pedantry and precision.
Pedantry is what she refers to as the noise — the opaque, ineffective nerd-porn dialogue that obscures meaning by muddying it with jargon. Not only can this result in gatekeeping, but it also allows incompetence to hide behind unnecessarily intellectualized terminology. Precision, by contrast, was what Dr. Cheng referred to as the signal — the bits of work that are expressed clearly and without loss of detail.
. Loss of nuance
Just as adding unnecessary complexity prevents meaningful communication, so does leaning too heavily on the other end of the spectrum: inaccurate over-simplification.
When good communication is conflated with dumbing it down, it keeps the status quo intact, perpetuating the stereotype that individuals who choose not to partake in verbal pedantry lack intelligence or deep technical aptitude. This couldn’t be further from the truth. Sadly, just as complex and meaningless messages are often mistaken as good communication, so are simple and meaningless ones.
This form of dumbed-down poor communication is best exemplified with what I call the Thought Leader Proverbs. These refer to the brain-dead aphorisms that flood the tech industry: “Move fast and break things,” “Bring your authentic self to work.” Thought Leader Proverbs reduce people and problems to one-dimensional figures, tropes, and flattened caricatures that are easy to digest but offer no real insight. In reality, the industry has outgrown these cultish slogans.
As our attention spans approach the infinitesimal spaces between tweets, our vocabularies can sometimes exceed our depth. Terms such as “white privilege” or “microaggressions” used to live within the walled gardens of hyper-academic discourse. Their use was often accompanied by the nuance that emerges from years of studying social science fields. The internet has circulated these terms into colloquial use. While this is, on balance, a good thing and provides more individuals with vocabulary to describe social phenomena that historically went nameless, these terms are also grossly misunderstood. The same thing happens when the complexity is not cultural but technical.
Last year, an article profiling Jennifer Tejada, CEO of PagerDuty, discussed how she largely credited her success to the fresh perspective brought by her atypical non-technical marketing background. The article applauded her ability to dumb down technical ideas to get to the root of problems. While the message’s sentiment was in support of clarity, the conflation of good communication with dumbing it down does an enormous disservice to the intellectual craft required to communicate complex ideas well. Being clear is not about being dumb, but, as Eugenia Cheng said, about identifying a problem with the precision and clarity that is appropriate for the context.
This applies to the design of abstractions. Poor abstractions dumb down complexity and reduce precision. Good abstractions make things more precise by creating context-appropriate information and interfaces.
“Being abstract is something profoundly different from being vague … The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.” — Edsger W. Dijkstra
Anyone who’s been berated by compilation or runtime error messages is familiar with the precision a machine demands as compared with the more forgiving constraints of natural language. Being the interface between human and machine, the subtle edges of technical work involve striking a balance: paying vigilant attention to detail without losing the core purpose these details serve.
The rise of distributed work and open source is shrinking our world. A greater diversity of thoughts are exchanged across geographic and cultural boundaries. While this enables a greater flow of more varied ideas than was ever possible in the history of this planet, it also invites greater possibilities for misinterpretation. Problem-solving in collaboration with those who have vastly different life experiences and native languages introduces challenges. Working with people who grossly violate all your base assumptions demands a heightened level of empathy, understanding, and coherence.
I’ve belabored the point that communication skills are important. While this sentiment is recognized across the industry at a superficial level, it’s all lip service until our culture catches up and truly values them. We still don’t have great ways to understand, measure, or train the amorphous blend of competencies that pool into what we consider good communication. Worse yet, we remain far from giving them the same level of prestige bestowed upon so-called technical skills. Perhaps dismantling the false dichotomy that dissociates the two is a start.