In the search of the path to be a better pro, we often forget that our careers shall not only be built on technical skills.
Calling your attention or not there is a realm of skills inside non-math majors that are strongly connected to what technology folks, and I’m targeting mainly computer science and computer engineer roles but this is quite broader concept
May seem stupid the need to have this kind of discussion, but besides the impact it causes, interact with other peers is harder than it appears to be. Yeah I’m talking about communication.
Unless, of course, you are Robert De Niro, Steve Jobs, Martin Luther King, Nelson Mandela, Dhalai Lama, and …. ok I think you got the idea.
Let’s go further checking communication definition from the dictionary
Communication - noun
- the act or process of communicating; fact of being communicated.
- the imparting or interchange of thoughts, opinions, or information by speech, writing, or signs.
- something imparted, interchanged, or transmitted.
- a document or message imparting news, views, information, etc.
- passage, or an opportunity or means of passage, between places.
means of sending messages, orders, etc., including telephone, telegraph, radio, and television. routes and transportation for moving troops and supplies from a base to an area of operations.
activity by one organism that changes or has the potential to change the behavior of other organisms. transfer of information from one cell or molecule to another, as by chemical or electrical signals.
I like this part from biology: “transfer of information from one cell or molecule to another, as by chemical or electrical signals”. Keep the transfer of information and imagine cells as people and ignore the way them communicate, they just do it because is needed them to.
So right now it does not matter if communication is made through smoke signs, words, voice, internet or any other means, the point is that actually we speak with each other during work but we tend to suck at it, or dislike it or whatever is the reason for our excuse in ruining projects because we forget to: send an email, talk to our co-workers, set up a meeting, make a call, teach someone, hear someone, understand someone.
It is always about how we could have done things in good ways if we payed proper attention in the human share of the job, all those “someones”.
Nah, it can’t be that bad can it be? Well today is our lucky day, let me share you a life experience example.
- The product owner (PO) meets with the client to understand the business rules and come up with software specifications. Lets say that the client wasn’t sure about what he wanted.
- Later you and the PO have a kickoff meeting so you can build the initial list of items needed to create the software and meet the client expectations.
- You assemble the team and have a nice planning to start working in this project, for now all of you seem excited.
- After some time bugs start to arise.
- In the belief that they are going to fix everything on time the team conceal the bugs from you as long as they could.
- You in the other hand, when receiving the bugs notice also thinks the team will make it on time and decide that is best to motivate them than to worry your PO with some small bugs.
- Despite the problems and the lack of checking the results first sprint results with the PO before finishing the sprint with the the product seem finished.
- When the first build is delivered the PO starts to complain about almost everything, bugs, wrong features, visual problems and so on so forth. He check as failure in a bunch of issues.
- The client receive both the first build and a list of excuses and promises from the PO, promises that he is not sure he can keep and that he didn’t check with the team if the time will be good.
I could go on with the list but the idea of this dramatization is to exemplify a not so absurd day-to-day situation, believe me this is not as far from the reality as you may think, and again it’s all about people and communication between them.
Even with all the communication problems inside my history we can target a list of actions to solve or at least lessen those problems and I could give you that list, but I would be talking about a big list of different things and instead of attacking all those things at once I want to show you some items to start small by aiming you at first.
Here they are:
- Learn to really listen, be interested in what others have to say before actually saying anything back.
- Start a blog, don’t need to be about your job.
- Read blogs regularly.
- Be part of a forum community, like reddit, stackexchange, slashdot, etc.
- Go to meetups, but don’t stay quiet in the corner go chat.
- Present a talk in meetups or conferences.
- Lunch with people in your work.
- Create casual chat groups with your co-workers that way you can talk about that nice episode from last sunday as well.
This is a really small list and does not stress all the possibilities, but as I said start small, and starting is something.
If you just have to remember one thing from all that I’m presenting is to listen, through truly listening you can understand others an thus communicate to them better, and that is the hardest part of all.
There is a difference between listening and waiting for your turn to speak. Simon Sinek
Still questioning yourself on why the hell a tech guy should improve communication skills? I believe that in the end the best of us are not the ones that program better than the others but the ones that can understand problems as well as expressing to peers and persuading them with solutions or those crazy ideas or even just on what is/isn’t good for a project.
And you know what? I’m not alone! This Jeff Atwood post post presents a well funded notion on non-tech skills for programmers.
Besides that, after I started caring on how well I communicated with others my work and my social life improved a lot, it is a subjective measure, yet passing from that horror story I told before to a calm and prosperous one is a result of skills carried over by good communication.
There is much more out in the wild and taking care of how we communicate is only the beginning. A good example extracted from the horror history is team communication which is another crucial question in software creation (we shall deal with it in a future post).
As a bonus pay a visit to How to Win Friends and Influence People book page on wikipedia which contains some nice ideas and directions for life in general. Also read Jason Fried’s Give it five minutes amazing post on listening others, as I said that before: listening is the hardest and the most important on communicating better.