This is the third article in a series where we cover the book Software Engineering at Google by Titus Winters, Tom Manshreck, and Hyrum Wright. 📕 We will go over various aspects of software engineering as a process, including the importance of communication, iteration and continuous learning, well-thought-out documentation, robust testing, and many more.
In this article, we cover communication - an aspect so fundamental, to not only software engineering but working with other people in general, that it often goes unnoticed, doesn't get the attention it deserves, and eventually becomes a bottleneck. Let's dive in!
Communication dictates everything
Communication is truly ubiquitous to all things human. That includes your professional environment. What is interesting is that the way you structure your communication often has second-level effects. According to Conway's Law:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
For engineers to create a properly working system, they must ensure compatibility between different components. The way to do it is with communication - written or verbal - and, as a result, the technical structure will reflect the social boundaries of that environment. 🏞️
Even though it's not really quantifiable, it still is a powerful observation. How you communicate personally, and how the communication looks in your workplace can have second-level effects.
Three pillars of communication
We know the communication is important. The book provides a nice outline of the three key elements of good communication. They call it the three pillars of social skills. 🏛
Humility: You are not the center of the universe, you're open to self-improvement. You should be able to reflect on your weaknesses because your mistakes are clear signals of where you can improve.
Respect: You genuinely care about others you work with. If others feel respected, it tends to bring out the best in them and they reciprocate. Ultimately, you want the people you interact with to feel like they can be their best selves.
Trust: You believe others are competent and will do the right thing. It's related to the other two pillars, as people tend to perform at their best when they are trusted - thus it's useful to make your default mode of operation.
All three of these pillars have one thing in common - it is the focus on the other person. It's been beaten to death, that effective communication is more about listening than talking - and it's really how it works.
Celebrating failure
As we mentioned in the second article, making the iterations as short as possible decreases the risk of unnecessary failure in software engineering. A failure is often a signal to change things - so the faster it appears, the better. Counterintuitively, failure is often very valuable information - and should be treated as such. 👑
That said, not all failure is created equal. If we decide to embrace and celebrate failure, it's worth focusing on the right kind of failure. The founder of Amazon, Jeff Bezos, differentiates between two kinds of failure.
Experimental failure. For a business, it might be developing a new product or service, that ultimately doesn't fit the market needs. In the context of software engineering, it might be picking up a new library, that solves your problem, but causes unexpected issues in other areas of the system. It might be rolling out a valuable feature that ends up being a maintenance burden, costing more than it brought.
Operational failure. For a business, it might be building the hundredth warehouse, but failing to execute this time. In software engineering, it might be repeating a critical error in the same area of the system, or rolling out a new feature but without proper monitoring.
Experimental failure is the right kind of failure and deserves to be celebrated. These failures allow for innovation and provide information. Operational failure results from execution problems - not having the right process or not using available information, like failing to add tests for problems that have been fixed in the past.
The creative nature of software development requires that people take risks and occasionally fail. For people to accept that failure, a healthy team environment must exist. It relies on good communication, which encourages experimentation in areas it's needed, and sticking to established practices where the path to success has been already paved.
Getting things into perspective
If you look at your work as an engineer, probably a meaningful chunk is dedicated to communicating with others. Perhaps it's even the biggest portion of your time spent at work. From participating in meetings, posting updates, and writing documentation, to pairing with other engineers, there's a lot of time spent interacting with others. 👨👩👦👦
Acknowledge the amount of time that you and your team spent on communication and interpersonal conflict. A small investment in understanding personalities and working styles of yourself and others can go a long way toward improving productivity. Take advantage of that, as improving the way your team communicates might reap much larger benefits than improving a few lines in your code.
Conclusion
That's it! You now see that investing time and effort into improving communication can lead to substantial benefits, despite how ephemeral this aspect might feel. Here's a short summary of things we went through:
ubiquitous nature of communication
systems tend to reflect the communication structure of the company that builds them
three pillars of communication: humility, respect, and trust
the importance of allowing and celebrating the right kind of failure
most of what we do at work is communication
Next, we will go over learning and knowledge sharing, which are fundamental to the growth of individuals and entire teams. See you! 👋
If you liked the article or you have a question, feel free to reach out to me on Twitter‚ or add a comment below!
Further reading and references
