"Good communication is the bridge between confusion and clarity" according to Nat Turner. If confusion grips your project on a daily and weekly basis, as I often find for many projects, then it befits the entire team to recognize, accept, and address the root cause: we are not doing a very good job communicating our ideas.
Good communication is the bridge between confusion and clarity
I would even make the case that the majority of the more recognizable smells, anti-patterns, and mistakes are just specific instances of failures to communicate: incomplete requirements, wrong abstractions, ticket deadlocks, and failing processes to name a few.
Defining Communication
The concept of communication is deep, and should rightly be considered a critical skill needed for success in any endeavor, and one that has to actively be honed. With that being said, the fundamental fact of communication is that the ability to express oneself pales in importance to the ability to listen. Being mindful of this listening component is important when understanding how it impacts a software project.
I also highlight an ofter overlooked fact, source code is a form of communication. It is probably the most complex way that people communicate in a regular basis. When writing source code, the author is writing for at least two audiences, humans who will read it to derive specifications and to maintain it, and for compilers that will execute its instructions in the most strict of adherence to grammar and syntax. When evaluating the competency of a prospective software engineer, their ability to speak, write, read, listen, and communicate is going to be a much better predictor of their capacity to read and write source code than something more relatively banal such as calculating time and space complexities of a given algorithm. This is why I repeatedly endorse the merits of linguistic skills over all others, and that the right way of judging code is by clarity, lucidity, and understandability, and not complexity, sophistication, or even elegance. Experienced engineers write code that is easy to understand, not code that is so complex that only experienced engineers could comprehend it.
Outside of code, consider all of the following things and how they are manifestations of communication: unit tests, designs and diagrams, READMEs, meeting notes, agendas, emails, Slack threads, discussions, tickets, comments, code reviews, and on and on... All of these activities are chances to contribute to the success of the team, or to miscommunicate.
Examples of miscommunication and examples
| Miscommunication | Example |
|---|---|
| Ambiguity | A colleague raises a discussion about a bug, but assumes that everyone knows which bug they are talking about, when in fact there are many bugs |
| Wrong Audience | A colleague authors a guide, but its voice drifts from deeply technical to more of a sales pitch, and entirely without a target audience in mind |
| Wrong Information | the wrong date for a deadline is set |
| Concealed Information | A colleague with critical project or corporate knowledge and information fails to disclose or document the knowledge. |
| wrong context | A discussion of pros and cons fail to take into account whether it is in regards to meeting an immediate need, or for long term planning |
| absence of communication | A technical ticket is written with no description, a README or document doesn't exist. |
| unresponsiveness | A colleague 'ghosts' requests, creating a bottleneck for some result |
| assumptions about the audience | A speaker assumes that the audience is highly technical, or knows obscure acronyms. |
| failure to listen | Every effort is made to inform colleagues about a concern, but no action is taken. |
| failure to discuss | Unforeseen challenges arise, instead of raising these new issues and alerting that deadlines may have to be pushed back, nothing is said, and the work silently fails |
With so many ways to fail to communicate, one should never underestimate how much these failures can harm a project.
A Thought Experiment
To further cement this idea, just think back to the last hardship or failure on your current project. Was it caused by bad communication, or could have it been prevented with better conversation? I thought so 😀.
Recommendations
For you and your Career
My first recommendation is to understand the true gravity that miscommunication has on a project. Additionally to this, and my objective of the article, is that I want you, as civilly as possible, to call out miscommunications loudly and often as they create hardships on the project.
Secondly, I highly recommend improving your own communication skills. This topic is beyond the scope of a single blog post, but aside from the obvious recommendations, which one would immediately find after a few minutes of googling such as reading, using a thesaurus, and brushing up on grammar, I would attribute a large amount of failure to a not-so-obvious source: coloring and obstructing information through the prism of one's ego. While it might feel dropping an endorsement of a self-help book in a communication blog, reading The Power of Now has been very instrumental for me to pick up on these errors and how they happen.
In addition, I think that staying up-to-date on the latest industry trends through constantly reading articles like these are a great way to hone this skill, but taking on a writing hobby does wonders as well. I personally think that engineers should hone their writing skills just as much as one's coding skills.
What your Team can do
- Research
There are plenty of resources on the internet that can help your team communicate better. It would not be a waste of time to implement some of the suggestions offered by more authoritative foundations, such as Atlassian.
- Define Ubiquitous Language
I'll let Martin Fowler layout the case for it. Practically speaking, if your project doesn't have some sort of pattern for documenting the specific words that you use throughout the project, an easy win is to write it up and share it with the team.
- Introspection and action
recognize the dynamics of your projects 'office', being especially cognizant of any hybrid or remote colleagues on the team.
- Improve your code review process
This topic is getting a lot more attention lately, and deservedly so. This particular article by Erik Dietrich really distills the vitriol of the practice into words
- Improve your meetings
A lot of communication anti-patterns are on full display at a typical project meeting. Fixing these meetings are a good starting point. Elon Musk has a lot of thoughts on the topic as well that resonate with my experience.
Conclusion
Software engineering is a discipline of communication, and software is built as a team. Great communication skills will serve you greatly as an engineer, and is paramount to becoming a leader in the field. You owe it to you and your team to make sure that the ideas that we share and receive are done correctly.
Top comments (6)
I cannot agree more with the title.
Absolutely.
I would only add pull requests to the list and suggest as a starting point the article How to Use a Code Review to Execute Someone's Soul - DaedTech
The power of now is an interesting pick.
Why was it so beneficial for you?
The power of Now is great for tuning in to the social dynamics that occur on a team, and unfortunately, I observe that communication gets distorted as individuals prioritize maintaining a specific identity for themselves or for the project, processes, or for their belief system instead of recognizing the realities of the project for what they are.
I like that author, having read Developer Hegemony, and he hit the nail on the head with that article you shared. I'll add it to the article. I had mentioned 'code review' in that list, which I find to be pretty synonymous with pull request; is there some subtle difference you think should be called out?
ah no absolutely not, it's the same thing, I had overlooked it.
If I was a consultant - in the developer hegemony sense - going to fix communication in teams, the first thing I would look is the way pull requests are submitted and commented and resolved and merged. That tells you an awful lot about the dynamics of a team.
Everything you mentioned is true now as it was true 25 years ago.
Shouldn't we have learned Agile practices by now? If teams are still having these issues, they simply need a Senior Scrum Master to lead the way.
Jira kind of works, but Azure Devops is 20 years advanced.
There's no substitute for a good Devops system and a great scrum master.
95% of our project hardship results from non-devs asking me for detailed effort estimation at a point where not yet all necessary information is available.