Keep lines of communication to a minimum
I’ve seen over the last three years as a developer on my current team that I’ve become the go-to person for questions, comments, and support for my team. At first, I liked to be known as the person who knew the answer, but I soon realized I was repeating myself, which led to additional context switching and time consuming.
I recognized that I was building tacit knowledge by discussing solutions with individual team members or product managers. I’ve realized that I need to take these conversations to more public forums to help build a more connected and efficient engineering team.
Private messages keep communication from spreading across a team, slowing knowledge transfer. If teammates are not in sync, misalignment is guaranteed to occur, which can lead to bugs, incidents, and downtime.
This is a great infographic on the importance of proper communication. Daniel Priestley shows how direct communication can lead to unnecessary complexity. When any of these lines are broken, the context is lost. Direct messages have their time to be private, but there is a need to understand that if the information is relevant or even useful to other members, it must be shared. When receiving a direct message, politely ask these questions to be redirected to a specified channel, which the team should have established.
Public discussions keep the conversation going in search history because we won’t always be on the team forever. Future developers will be able to understand why something was done or have a deeper context for a bug or feature.
Consistent team knowledge is not the only benefit to open channel communication; It also allows for greater collaboration between engineers. The person you are asking may not have the best solution. We all come from different backgrounds and have different knowledge sets to piggyback ideas or even develop one solution from the point of view of another.
Sometimes we want a quick response or are worried about asking a stupid question. I am more guilty of this and remind myself to follow my principle. I didn’t recognize that my questions could have a big impact on spreading that knowledge to my entire team. It can be intimidating to throw a question into a dull channel of 100 people for fear of asking silly questions and admitting you don’t know anything, but as long as we were diligent in researching our question beforehand, your team should have Happy to help .
In the book “Practical Programmers”, one of the chapters is on repetition and applying the DRY (Don’t Repeat Yourself) principle. The book explains that the DRY principle is more than just code; It is about duplication of knowledge.
“Probably the hardest type of duplication to detect and handle between different developers on a project.”
The quote above refers to what the authors call interdeveloper duplication. When teams don’t communicate, repetition is inevitable. The book references a US government audit of its computer systems and discovered 10,000 programs, each of which used its own Social Security number verification. This is a good example of communication breakdown where knowledge is not passed between developers not only on a team basis but also on an organizational level. The same principle applies to your team.
After a few years in my company, I was promoted to Senior Engineer. I can attribute some of this to following the open communication rule. This leads to higher visibility helping stakeholders show impact and value. Taking the conversation to public channels benefits the team and can help advance your career as you are shown to be a collaborator and a leader.
Finally, and to me, the most important is discoverability. I already mentioned that when we have a question, we should do our due diligence to make sure the answer is not already mentioned. Assuming that Teams has a modern messaging system (Slack, Teams, etc.), we should be able to search through discussions to find answers to the questions asked before. This will save team time waiting for feedback so that we can stay efficient and come back to execute our tasks.
These are all reasons why it is so important to make our private messages public. If everyone follows this rule, we can reduce those exponential lines of communication to a manageable level. Knowledge can be transmitted even when we go to greener pastures.