This article will cover a very important topic in engineering, especially in teams that are working on projects remotely: communication.
You might be thinking “Well, of course communication is important. Everybody knows that.”. Do we actually know that?
Do we really know how much it can affect the efficiency of separate teams? How much it can affect the success of a project? How much it can impact our personal careers?
Async communication is a given when you are working on a project involving more than one team. It should have quality, clarity, politeness, but it should be more than that. The communication that you are doing every day in your projects has the power to either motivate other people or do the exact opposite.
When you are communicating with a remote team member or client you should always keep in mind that what you are writing should be clear.
You may be reporting about a complex bug or problem and the recipient may only see the message a lot later. Maybe he was absent, maybe he went on his break, maybe he went to the doctor. Hours may pass in occasional situations. So one thing to keep in mind is: write well what you want to say. Be clear about it. Try to write something that can’t be misinterpreted.
Imagine that you are reporting a problem with an api. Be descriptive. Specify the url, the http verb, specify headers, query params, body. Describe the context of the error if it makes sense and how to reproduce it, specify the response from the server and if you have an idea about what it could be, tell them your hints, maybe it will help the recipient figure out the problem faster.
This way, anybody could pick this up at any time and understand what is going on, what is wrong, what should be expected and hopefully what to do next.
This topic is a bit tricky. It’s a subjective concept, and it changes a lot from personality to personality. Still, there are several things you can do to be polite in your communications.
People have their own tasks to do, they may be working on something difficult, they may be in the middle of a hard thinking line and still, they may stop what they are doing in order to reply to you.
So the next time that someone answers you really quickly after you send something, take the time to add a “thank you”, at the end of your message.
Let me give you an example (P1 as person 1 and P2 as person 2):
P1: I have a problem in api xyz. I’m sending everything it needs, and it’s giving a 500 error. This is blocking me. (Sent 4pm)
P2: Can you tell me what the response was? Any more details? (Sent 4:01pm)
P1: SQLException (foreign key xyz is missing) (Sent 4:02pm)
P2: Figured out the problem! Should be fixed on the next deploy. 5 minutes. (Sent 4:10pm)
P1: ok (Sent 4:14pm)
P2: done! check it out now please. (Sent 4:15pm)
This is the kind of conversation you should absolutely avoid. In here, P1 was not clear on the problem right of the start. He could have sent more information that could have helped P2. And worst of all, P1 by the end of it didn’t appreciate the effort that P2 had on solving his problem really quickly.
This is the kind of conversation that many people have daily. We may find ourselves being P1 sometimes and P2 other times on our jobs. Put yourself in both P1 and P2 shoes, and think a bit about that. These types of conversations over time take their toll on the people involved.
The previous chapter ended on a strong realization: communication has a deep impact on motivation.
The last thing you want is to be working on something and completely lack motivation. By the same logic, the last thing that any project manager or client wants is to have a team that is lacking motivation. From the personal side you don’t want this obviously because it has the power to impact your personal life. Not only your professional one. From the management and client sides you definitely don’t want this because several things are going to happen:
Given this, how can we motivate people in communication? Just be positive and understanding.
I’ll give another simple example of something very common on software development.
Manager: I need tasks A, B and C done by the end of the morning. We are falling behind schedule, do these tasks quickly.
Team: ok, we’ll try to finish these.
Now, another way to write this:
Manager: Guys, we are close on finishing tasks A, B and C, let’s make a final push to see if we can deliver this until the end of the morning. If you guys need any help just ask me!
Team: Yeah, we’re almost done, we’ll deliver this!
So, what’s the difference here?
In the first situation, the manager only conveyed negative feelings (obligation, the team is slow, tasks are behind schedule). This may seem something not very important, but if you are having these situations sprint after sprint, it affects the morale of the team a lot.
In the second situation, the manager is obviously aware that the team is late on delivering something, but instead of conveying negative feelings he asked the team to make a final effort to deliver them (with this the team gets a feeling of accomplishment when the task is done). He also made it clear that he is part of the team, so if help is needed, he is there to help gladly (conveying a feeling of support to the team, they are not alone).
So, why is the feeling of accomplishment important? Well, because the human brain is kind of hard-wired to respond well to this. There are certain hormones that we release when achieving goals that help us to be more motivated, focused and happy.
It’s really easy to get a lot of these feelings in software development, we just need to promote them. Simple stuff like planning the day and defining that we will do tasks A and B and get it done by the end of the day will trigger this effect on our brain. Continuously doing this with success will no doubt increase our work happiness and effectiveness. Of course that most of these “small wins” can be planned by ourselves, but good project management will also trigger this effect collectively in a team or project, which in turn will also boost teamwork and team confidence.
What I hope with this article is simple: that we stop a bit to think about our daily communications, if we can improve them in order to help ourselves, the teams, the projects and the companies that we work for.
I also hope that this will make you think more about how your communication may be affecting other people, and with this, that we may start communicating more clearly, motivating more people and avoiding misunderstandings.
Try to positively influence those around you, and in turn, they will do the same.
I hope you liked this article and please, submit any feedback you want! 🙂 If you find this article interesting, please share it, because you know — Sharing is caring!
Let me keep you posted on new projects, articles or talks that I do!
