Writen by Matheus Michels, Frontend Developer, in 02/19/2021
4 minutes of reading
Communication and Software Development
According to PMI, 56% of a project's budget is put at risk by inefficient communications. Are you wondering why this is so important?
Some time ago, in college, I heard that the main cause of projects failing is communication failure (or lack of it). According to PMI, an international project management institution, 56% of a project’s budget is put at risk by inefficient communications. However common the theme is, there are still, in many companies, teams with difficulties in this area.
Why is it so important?
- For productivity. A team that communicates well has greater synergy and, consequently, solves problems faster and produces more.
- By generating value for the product. With a good relationship in the team, there’s more participation and greater contributions from members.
- By reducing conflicts. A synergistic team tends to have fewer disagreements and reworks.
- For scalability. If a small team has difficulty communicating, it’s unlikely to grow.
In fact, developers have long been known to be more introverted/shy people. This is not necessarily a problem, each person is unique and has his own characteristics. But depending on the situation (if it leads to lack of communication, for example), it can hinder the development and progress of processes in a team.
This makes several companies look for professionals who already know how to express well (in addition to other soft skills), often overlapping experiences with certain technologies. This assessment is usually made at the beginning of a selection process, based on a conversation with someone from HR.
On the other hand, there are companies that ignore this aspect, and the interaction with customers and end-users is done by PO’s and analysts. In this case, often those who code don’t know the customer (or how that code will generate any value) and don’t bring opinions frequently, because the tasks arrive through tickets and finish when QA’s approve them.
Weeks ago, browsing on YouTube and watching some programming channels, I came across a video about “assertive communication”. I didn’t know the term until then, and I went to read more about it.
a form of behavior characterized by a confident declaration or affirmation of a statement without need of proof; this affirms the person’s rights or point of view without either aggressively threatening the rights of another (assuming a position of dominance) or submissively permitting another to ignore or deny one’s rights or point of view.
Being assertive is about finding solutions that connect your desires to others’ desires and seeking mutual satisfaction where conflicts exist. It’s about knowing how to say “yes” and “no” when necessary. It’s about building true relationships and promoting the self-confidence of those involved.
I leave here an interesting talk about how to speak for yourself. I believe it has really good insights and then you can be a more assertive person.
Now, let’s get into some tips that can help you get better results every day at your work, whether writing messages or transmitting your ideas in a video conference.
Update your team about the progress of your tasks. Don’t wait for the product owner to come and question you about it. This is part of managing expectations and strongly helps to improve the project’s estimates. Many teams use daily meetings for that, but there is no reason to wait a whole day to synchronize and raise your problems when you can do it all the time via message, right?
Don’t play “chinese whispers” with your colleagues. Be objective and transparent when expressing your ideas, give context and bring them to public channels (avoid private chats), so all interested are involved.
Don’t keep your problems to yourself. Stipulate a timebox not too long to try to resolve them, and passing it, ask for help from your colleagues. You aren’t lesser than others for asking someone’s help.
Avoid technical language when talking with non-technical people. Use common language that makes sense to you and others. Always try to facilitate the understanding of your propositions.
Constantly evaluate the usefulness of meetings. You’ve probably heard the jargon “I survived another meeting that should’ve been an email” … this problem is quite experienced. Over time and the growth of the team, it’s very probably that their number will increase. Therefore, it’s important to evaluate the motivations for the existence of each one regularly. Eliminate meetings that could be a chat/email, try to have meetings with well-defined scopes, and be prepared for them.
Learn to listen. Listen first to understand, not to answer. Try listening to your colleagues’ ideas a few times, then make your considerations.
“Wise men speak because they have something to say; Fools because they have to say something.“_ – Plato
Don’t be ashamed/afraid to give an opinion. No doubt saying it is easier than doing it, but it will only sound natural as you get used to it. Demonstrating curiosity and having your own opinions are also part of the sense of ownership.
Document meetings outputs. Not everyone will always be able to participate, and what has been agreed upon may simply be lost over time. Write what was discussed, and allow the entire team to consult. In addition, at the end of them, check what was defined with the team, in order to validate if the points noted are correct or if there was any noise.
Finally, try to work in companies that have a psychological safety environment and stimulate your communication skills, either through talks, 1: 1’s, involving you in meetings with clients, … or in other ways. Ask for feedback from your colleagues. No one is better than them to tell what you are doing well and what could be improved.
Remember that building a healthy relationship is the foundation for a successful project, and then you’ll not get results like this:
Those are my 20 cents for the subject. I hope it contributes in some way to your career, and if you have another tip to add, please leave your comment below.
Original post: Communication and Software Development