Communication

You can read all the text there is about communication and I won’t repeat that. It's a vast topic. This post and similar others in the series are scoped down for engineers. Talking about how to do verbal and written communication is important but when to do what is more important in our industry. Body language is a huge part of communication but usually, in our profession, over-optimizing body language won’t pay the best dividends.

Communication culture, as with all cultures, is driven top-down in an organization. How your CEO communicates is going to impact how the engineers communicate. A good manager can shield you from an ill-spoken executive but only to a certain degree. In most small startups this is less of an issue than in companies with big hierarchies. Things are certainly improving as we move farther from the industrial age.

The best way to communicate in our profession is to minimize the number of times you communicate. Programming and thinking need focus. Most programmers are not productive when distracted too often. Distractions could be your mobile, your peer, your manager, slack notifications, or customer support. I believe asynchronous communication is something that can save us.

Thanks to COVID, the emphasis, and benefits of async communication are highlighted far better than ever. I do believe it should be the norm even in an office environment. We should default to asynchronous communication for work-related matters. Shipping features need focused effort from individuals.

One thing almost all good engineers hate is meetings. You can’t become a good engineer by hating meetings but you can’t be a good engineer if you don’t hate them. I haven’t seen one good engineer who likes meetings. Most meetings are a waste of time.

You do not need to meet about the design review.

You do not need to meet for code review.

You do not need to meet for hashing out specs.

You also, most of the time, do not need to meet when some disaster happens.

You do not need to meet for a retrospective.

The first idea is usually not the best one and meetings are run on first ideas. People throw the first ideas that come to their head and other people start responding to those ideas with the first idea that lands in their head. Epic time wasters.

Fruitful meetings are the ones not about work. They help team building. They drive culture, and mentorship and glue the team better. Do 1-1s. Stop doing stand-up meetings, retrospective meetings, and sprint planning meetings. Stop doing scrum at all. That idea is dated.

All of it can be done asynchronously over text. Do it in Slack, Twist, Teams, Basecamp, GitHub, JIRA, Notion, Google Drive, or whatever tools you use.

However, this has to be enforced by the managers. If you are a lowly engineer who is stuck in a culture of scrum or meetings, be patient and have a bias for async. Lead by example. This is harder for someone in a big company to enforce because many managers in those companies have the least skin in the game. The only way they can make themselves appear relevant is to make their calendar look like they are the president of a universal government.

In smaller companies, the communication channels are short which is great but the constant nudges of a “dynamic” work environment in a startup are a serious productivity killer. There are very few companies that do asynchronous communication really well. I believe it can be a savior for engineering teams worldwide and will shape a lot of how knowledge workers in creative fields work. Try to communicate asynchronously wherever you can and talk about it with your peers. Get rid of as many meetings as you can. It is certainly doable and companies like GitLab, Automattic, Basecamp, and Doist are great examples that this is scalable as well. Here's a good introductory read on async-first by Doist.

Asynchronous communication can be done in speaking but usually, it emphasizes written over verbal communication. As someone puts it, “writing is a superior form of thinking”. When you write, you do it slowly, you give your thoughts time to organize, cut the fluff and say something valuable. This goes beyond software engineering. If you are trying to think about a certain topic, try to write about it. Writing will give your thoughts such clarity that Is hard to achieve otherwise.

I have posted this before but here it is for the sake of completion. When talking, especially asynchronously, always give proper context about what you are talking about and the entire background to minimize back and forth. This is more important for non-western/high-context cultures to understand. For goodness’s sake, do not send a  message which doesn’t explain your intent, without proper context. Here is how some conversations go:

• Colleague [10:00 AM]: “hello”
• You [10:05 AM]: “Hi, what’s up?”
• Colleague [10:11 AM]: “do you have a minute?”
• You [10:12 AM]: “yup?”
• Colleague [10:12 AM]: “please review my PR”
• You [10:16 AM]: “Link please”
• Colleague [10:25 AM]: “https://github.com/orga/pull/127”

You will always find such a conversationalist in most organizations. Do not, under any circumstances, be that guy/girl. This conversation spanning 25 minutes has cost the company ~approximately $100 for no good reason. Ideally, you shouldn’t have to text someone for a review but this could have been a single message.

"Hey, can you review https://github.com/orga/pull/127? would only take a minute."

Send each message as the person on the receiving end will only reply to you once in 24 hours. Value your and others’ time.

Be a good writer and you will become a good human being and certainly a superior professional. Try to be concise, read and re-read what you write, improve and then press that send button. A lot of times, during writing you will see your issues resolving themselves. It will force you to research and rethink. It’s an alternative to rubber duck debugging but for complex and multivariate problems.

Transparency is key. If you need retrospectives or wait for one to talk about ongoing issues, that is a problem of culture. Communicate what needs to be communicated as and when needed. I am not saying you shouldn’t reflect back and think about areas of improvement. I am saying you don’t need to meet for that. Do it all the time, do it on your own schedule, in the washroom, or whatever suits you. When you have a point worthy of sharing with the whole team, bring it forthright when it makes the most sense. Not necessarily exactly two weeks from now and not necessarily today.

We develop a lot of processes, scrum for example, to make the system more tolerant. Tolerant to low performers. I think we should warn low performers and if they continue their course, fire them.

Hire slow, fire fast.

We shouldn’t convolute our processes to make the life of the entire organization a living hell just for the sake of making the system tolerant of bad behavior. When we increase too many processes, we kill the spirit of the people of the company. Companies die when that happens or are overthrown by competition. They are at mercy of Lindy’s law at that point. More on hiring and firing in a later blog post.

Encourage an open and direct communication culture. Be respectful and open to ideas but communicate clearly and directly. Don't let your fears dictate how you communicate. Develop financial independence early on. Make a 6 months runway so you are not too worried about getting fired. Do whatever you can to get out of that fear zone of getting fired. Build a network. This will improve your communication game. You will be less fearful.

Once you operate out of the zone of fear, you operate with freedom. At that point, if you turn out to be an a**hole you will have no option but to fix yourself or face the music. Your inner a**hole might stay suppressed if you operate in a fear zone. If it comes out when you are 40 years old it wouldn’t be funny anymore. So be open and direct early on in life. If you are not doing that, work on your “why”. It could be some sort of fear. Work on it. It is not an introvert vs extrovert problem. Don’t use that excuse to get away with it. Introspect to find out, read psychology, go to a therapist or speak what you think and feel more clearly and learn from the feedback and reactions you get. You will either fix someone else or fix yourself. The longer you delay this, the more injustice you do to yourself and/or other people. Communicating directly and openly does not mean blabbering. This is important for extroverts to take note of.

Fortunately, if you don’t turn out to be an a**hole, you will be tremendously helpful and level up your engineering/professional game.

Write.

This post is from a series of related posts about software engineering. It is part of an attempt to write a book in public. I seek your feedback. Raise your opinion. Share with people who can benefit from it. Contribute in the comments section, on social media, over a cup of coffee, or however you prefer. This will help me and the community tremendously.