Communication, Education, and Engineering
I've been thinking a lot recently about communication in the context of an engineering organization, both because of our company having gone all remote due to the COVID-19 pandemic and because of some recent examples I have seen of poor communication being actively harmful to the engineering organization and culture.
I've been reading Team Topologies, and one of its main points is that the team, not the individual, is the value-creating unit in a productive engineering organization, and that approaching business and technical decisions in a team-oriented way is the best path to ensure high software quality over time. I have been a firm proponent of this view for a long time, and it's nice to see it presented in such a clear, concise way.
Given that a team, by definition, is made up of multiple people, it follows that communication is a necessary skill for any given individual on the team. For an engineering organization of any significant size, this is compounded by the fact that teams are inevitably going to have to work together and depend upon the products of each others' work, requiring effective communication both intra- and inter- team.
The vast majority of necessary communication within an engineering organization falls into one of two categories: learning or education. Learning communication includes requests for information (both internal and external to the team or organization), shared exploration of an unknown problem space, and much of the small talk needed to get to know and trust our coworkers. Educational communication includes providing information, sharing discoveries, and those parts of small talk that let our colleagues get to know us. Given that virtually all necessary communication falls into these two categories, it is essential that team members be not only good learning communicators, able to effectively request information and guide shared exploration, but also good educational communicators, able to effectively convey new and complex information to a variety of audiences (team members, stakeholders, executives, etc.).
Despite this, there is often not a clear definition provided in an engineering organization of what it means to communicate well. We don't have a rubric by which we can measure effective communication, and perhaps as a result, in our interviews, we don't actively select for good communication skills, we don't require writing samples to ensure an applicant's written communication is as good as their verbal communication, and we don't assess an applicant's ability to educate their peers. Then, once we've hired someone, we don't constantly evaluate their communication performance in order to help them improve. As a result, we leave to chance what is one of the most fundamental qualities of an effective team and organization. Perhaps you have been lucky and haven't seen it in person, but the degree to which one consistently poor communicator can hobble a team's performance is significant.
While communication skills are crucial at all levels, they become exponentially more important as an employee's rank becomes more senior. Hiring or promoting someone to a senior level explicitly labels that person as exemplary, as someone to whom junior employees should look to for professional and technical leadership. It should therefore be expected that leaders in an organization spend more time communicating, that their communication is held to a higher standard, and that the overall balance of their communication shifts towards the educational side. By spending time communicating and teaching, engineering leaders enable significantly faster growth and better performance of their peers, while improving visibility into complex technical issues at the organizational level through effective representation of the team's work and progress. For a team-oriented organization, this is the force multiplier that engineering leaders provide and how they justify their higher salaries.
There is generally no place in a team-oriented engineering organization for lone wolves, rockstars, divas, or however else you might label someone who is an excellent technical performer, but who cannot work effectively on a team. There might of course be exceptions for individuals who are exceptionally talented and who are already distinguished leaders in their field, but these individuals are so rare that they aren't worth considering as part of the normal course of operations. 99.999% of "rockstar developers" are not Linus Torvalds; they are just slightly better than average developers with poor communication skills, who will in subtle and not-so-subtle ways create deep pools of toxicity when an organization attempts to integrate them into a team. This toxicity is rather like nuclear waste. The longer it remains, the more pronounced its effects become, and the resultant irradiation remains for a long time even after the offending individual is removed.
But what does effective learning and educational communication look like? This article will attempt to enumerate some principles for effective communication, with the goal being to provide a basis for which an individual or an organization might evaluate the effectiveness of their communication, and to provide a chance to get onto paper the communication ideals that I personally aim for in my own career.
General Principles of All Communication
Within a team-oriented organization, it is critical that all communication adhere to certain standards. Without these, communication can fail to serve its purpose as a bridge and a conduit of information, and instead become a wedge and a source of obfuscation. The following principles apply to all communication, regardless of whether it is written or spoken, official or unofficial, synchronous or asynchronous.
Be Respectful
All communication MUST be respectful. Full stop. There is absolutely no place in an effective team for condescension, rudeness, or aggression.
Respectful communication is communication that assumes good faith, is charitable to others, and which follows the golden rule. We'll discuss each of these components individually in a bit more detail.
Assume Good Faith
In an effective organization, every individual is working for the good of the whole. We must therefore assume that their communication is in good faith. When they ask questions, we must assume they are making honest attempts to learn, and we must respond as educators, doing our best to provide answers.
We must also come from a position of good faith. We should aim to accomplish either learning or education in all of our communication, and must never pollute that purpose with sneaky attempts to show someone up or to prove we are clever.
Be Charitable
It is critical to recognize that people are coming to any given nexus of communication from vastly different backgrounds, not only in a longer-term sense in terms of their personal and professional backgrounds but also in a shorter-term sense in terms of what they have been thinking about or working on recently.
For example, when someone asks a question that has already been answered, asks a question we feel they should already know the answer to, or makes a point that shows a lack of understanding, it is essential that we consider the underlying reasons with charity. Perhaps they have had a very busy day and only skimmed the discussion. Maybe they're doing fifteen things and once and got something confused. They might just still be learning. Regardless, we should use this as an opportunity to ensure that we have have done a sufficient job of educating. Could we have presented the idea more clearly? Is there some confusing indirection or obfuscation that we didn't notice because we were so deep in the problem? Is there documentation that we can point to to clear things up?
One of the most valuable lessons that I learned when I was teaching college classes was that the vast majority of the time a student's failure to understand something was not because of anything intrinsic to the student, but because I was not explaining the topic in a way that made sense to them. We must assume that our coworkers are what they so often are: smart, busy people who just want to help the team make something they can be proud of.
Follow the Golden Rule
In communication, as in most things, we should follow the golden rule, "Do unto others as you would have them do unto you." Treat others with the same respect that you would want for yourself. Assume they are smart and capable people. Assume they are not being willfully mean or vindictive. Always give them the benefit of the doubt.
Be Direct
I meant what I said and I said what I meant.
— Dr. Seuss, Horton Hatches the Egg
If we cannot honestly say, like the elephant in the Dr. Seuss classic, that we said exactly what we meant, and that we meant what we said, than we cannot say that we were communicating effectively.
Reading between the lines should never be a necessary part of business communication. If some work requires changes, we must say so. If something is not excellent, it does no one any good to say that it is. We should always seek out and emphasize what is praiseworthy in our colleagues' work, but we also must not avoid critique because we are afraid of hurting feelings.
Of course, being direct cannot exist in isolation, without also applying the rest of these principles, especially being respectful. One cannot justify rudeness, impatience, or condescension by hiding behind the veil of directness.
Be Clear
It is all very well for you to write simply and the simpler the better. But do not start to think so damned simply. Know how complicated it is and then state it simply.
— Ernest Hemingway
We work in a complicated industry making complicated things. We must therefore aim to speak and write clearly, and always with our audience in mind. Use jargon when speaking or writing for a technical audience, but leave it out when communicating to the broader organization. Strive to keep sentences and language as simple as possible.
This principle is especially important in technical and project planning. Using overly complicated language or not taking the time to find a way to describe something in a simple way can cause real consequences down the line. If reviewers fail to fully grasp a topic because of grandiose language or overly complicated descriptions, they may also fail to see critical issues in the design. Someone implementing a technical plan later on may fall afoul of the same problem and encode that poor understanding into the system itself. In this way, poor communication can become technical debt.
Be Honest
Being honest is somewhat correlated to being direct, but applies more broadly. An effective team is one in which every team member is comfortable being honest. It is therefore critical that we strive to be honest, and perhaps even more importantly, that we create an environment where we expect and encourage honesty.
Failures to live up to this principle show up all over an engineering organization. An environment in which a team is uncomfortable being honest about estimates due to strict timeline expectations will lead to unnecessary padding and descoping of features. A team with a poor manager will be hesitant to say anything in skip-levels if there are concerns about politics being more important than honesty. An individual on a team will be hesitant to share that they are having problems with a task and ask for help if their team does not communicate honestly and respectfully.
Putting Good Communication into Practice
We must ensure that we are applying these principles in our own communication and that we are clearly communicating and enforcing them as expectations in our organizations, if we expect to be effective. What follows is a by no means complete list of ways that we as individuals and leaders can make that happen.
Communicate the Importance of Communication
It should be 100% clear to all employees that communication is a core value and competency of a company. Communication principles should be covered in onboarding and should be readily accessible from company and project documentation. The importance of communication should be emphasized frequently in training, presentations, and evaluations.
Always Be Editing
In writing, you must kill all your darlings.
— William Faulkner (possibly apocryphal)
Written communication should almost never be submitted without at least one round of editing (with perhaps the exception of instant messaging). Whether submitting comments on someone's code, writing documentation, or preparing a technical document, write it, read it, and then read it again, keeping the principles of effective communication in mind and ruthlessly editing so that your writing adheres to them.
Faulkner's quote above applies directly to the editing process. When we write, we may often become emotionally attached to our own writing, perhaps savoring a particularly clever sentence or an amusing idiom. However strong that attachment may be, we must recognize that in business our writing exists not to make us feel good about ourselves, but to communicate something important. If we must kill our darlings in service of better communication, so be it.
Recognize the Importance of Education
If I had to quantify my time, I would guess that I spend approximately 60% of my working hours in communication, with most of that being educational communication. Does this mean I do less hands-on coding? Of course! But there is no doubt that the time I spend making suggestions on others' code, shedding light on legacy decisions, and writing about upcoming projects allows my team to do more and do it faster than would otherwise be possible. I am just one set of hands on the keyboard, and a day of my work cannot come close to the output I can provide by accelerating or unblocking the entire team. Because I have the knowledge and context to do that, it would be a waste of resources for me to spend all my time coding.
It is critical that a team-oriented organization recognizes and facilitates this kind of educational communication. Formalize pairing sessions and knowledge transfer between senior and junior members of the team. Regardless of organizational level, ensure that team members who have more context on any particular area of the domain share that knowledge with the rest of the team. Put engineering leaders on documentation tasks, and ensure that the value of documentation is firmly communicated in engineering principles. Encourage frequent and informal presentations such as "lunch and learns" or intra-team demos that allow people to share knowledge in a way that is not threatening and doesn't require a lot of activation energy.
Invest in Educational Artifacts
Code documentation, code comments, team process and procedure documentation, technical planning documents, architecture decision records, and company-wide documentation all have something in common: they are educational artifacts, products of someone's labor whose purpose is to offload the educational burden and allow it to be asynchronous. They ensure that understanding is encoded in a common place, reducing bus factor, and they free up the time that otherwise would have been spent educating each new employee on the content of the artifact.
These educational artifacts are critical to the success of an organization, and they must receive the same care as functional artifacts, such as releases of product code. We should take care that all of our principles of communication are applied when writing and reviewing educational artifacts, and that we make discovery of these artifacts as smooth and streamlined as possible. We should also ensure that creating educational artifacts is low-friction, whether that be through providing a freely editable wiki, allowing engineers to write documentation alongside code, or whatever else works for the team.
Hire for Effective Communication
I know that cover letters have largely fallen out of style, but I think they can provide great value as a writing sample. If not requiring a cover letter, require some other writing sample as part of the interview process. Evaluate it in terms of the organization's communication principles and whether it does an effective job of educating the interviewer.
In addition to assessing written communication skill, we MUST do a better job as an industry of digging into an applicant's learning and educational communication during the interview process. Perhaps instead of algorithms on a whiteboard, we could assess learning communication skills by assigning a task with minimal information that requires asking questions of the interviewer in order to determine the full requirements and appropriate path forward. Similarly, perhaps instead of solely asking questions of the interviewee, we could have them teach us something, perhaps a presentation on some technology they find interesting or an architecture they would propose to solve a problem. This idea is shamelessly stolen from the process of applying to be a college instructor, where you will often be asked to give a lecture as part of the interview process. For this latter challenge, we should of course let them know beforehand what they will be discussing. After all, having to both figure something out and present it simultaneously is rather unrealistic (and many people's worst nightmare). We cannot teach what we do not already know.
Expect Failure, and Be Willing to Forgive
Of course, no one is perfect, and part of treating ourselves and others with respect is accepting the fact that we will all sometimes fall short of our ideals.
Much like blameless retrospectives for technical failures, managers should meet with employees and look back on cases where they failed to communicate in a productive way. We should strive to find the root of the failure. For example, someone losing their temper is often a sign that they are feeling a lot of pressure or are overworked. We should strive to address these root causes, while also expecting that individuals be willing to recognize, own up to, and atone for their failures. Whenever we fail to communicate respectfully and potentially hurt our relationships with others, we must be willing to put forth the extra effort required to heal that wound, generally by admitting that we failed, apologizing, and trying to do better going forward.
Remove Toxic Individuals
While we all fail to live up to our ideals sometimes, we must not tolerate individuals who consistently fail to do so and show no signs of remorse or desire to improve. Keeping poor communicators around, particularly in positions of leadership, can create deep and long-lasting wounds in teams and organizations. We must therefore be willing to address problems as soon as we see them, and if we cannot fix the problem by working with the individual, we must quickly remove them from the organization. Ultimately, this decision must be guided by the principle of preventing harm to the rest of the team and the organization.
Conclusions
Hopefully it is clear that communication is fundamental to the success of any organization, particularly any organization where the fundamental units of value are teams. Within an engineering organization, most if not all necessary communication is either learning or educational communication. Engineering leaders particularly must be expected to be excellent educators as well as excellent programmers, and there is no room in most team-oriented organizations for lone wolf, rockstar developers.
Good communication is respectful, direct, clear, and honest. We should strive to hold ourselves and others to these ideals of good communication in every context, whether spoken or written, persistent or transient. Consistent application of good communication helps teams maximize trust, understanding, and knowledge transfer, ultimately making them more effective units within the broader organization.
As individuals and as organizations, we can and must take concrete steps to make good communication a core value. We must ruthlessly evaluate our own communication to ensure that we are living up to our own ideals. We must ensure that our hiring process looks not only at technical ability, but also at learning and educational communication. We must ensure that the educational role of our engineers is encouraged and respected. We must ensure that our educational artifacts receive the same care as our functional ones. Finally, we must be kind and generous in allowing for the times that we fail to live up to our expectations. However, when it becomes clear that a member of a team cannot communicate effectively, we must remove them quickly to avoid damaging the team.
If you enjoyed (or didn't enjoy) this article, please feel free to email me at msplanchard at gmail dot com for clarification, edits, discussion, etc.