How to become excellent in communication skills ?

The main thing I know about having good communication skills in office is that good communication means easily able to explain what one wants to convey and easily able to understand what the other person is saying without assuming anything. By doing this one would have decently good communication skills. How to become excellent in communication skills?  What does having excellent communication skills mean ? Thanks

Monica Shiralkar wrote: What does having excellent communication skills mean?

I think, you already answered your question in the beginning of your question. Yes, good communication means to convey your message to everyone in simple language.

Monica Shiralkar wrote: How to become excellent in communication skills?

Good communication can be improved, when you listen & read a lot to different people at different forums.

Sometimes, I have seen people to choose a role model, to become like him/her. It has helped them.

Thanks

Monica,

the start of good communication skills is to know how to listen.  many people listen to answer, but when they do they tend to have a preset thought in their mind--don't listen to answer.  instead, listen to what is being said, all that is being said.  pay particular attention to each of the points they they are trying to make.  once they have highlighted what they need, then form a thought, but only if you have enough information to do so.  part of being a good communicator is to know when you need to ask for more information, before you can really understand and help.

Les

I would suggest good communication skills are more about knowing when communication is needed rather than any particular style. The ability to clearly and succinctly describe a problem means nothing if you choose not to.

Other than that it has been my observation that good communicators can adapt their style to any given audience. In a technical role such as ours it isn't always easy talking about something with non technologists in a language both parties understand. It can be a challenge.

Thanks.

Tim Cooke wrote:I would suggest good communication skills are more about knowing when communication is needed rather than any particular style.

I think the means being silent at some times during communication instead of continuously speaking and instead speak when required.

Tim Cooke wrote:
Other than that it has been my observation that good communicators can adapt their style to any given audience.

That's an important point to understand and learn to adapt, and will come with experience.

Tim Cooke wrote:The ability to clearly and succinctly describe a problem means nothing if you choose not to.
.

I did not understand this part. Could you please tell what it means ?

Tim Cooke wrote:it isn't always easy talking about something with non technologists in a language both parties understand. It can be a challenge.

Any recommended way on communicating with non technologists.? I think scrum master and product owner may also comes under non technologists.

Monica Shiralkar wrote:. . . I think the means being silent at some times . . . .

I don't think that is what Tim meant.

Thanks

Les Morgan wrote:
the start of good communication skills is to know how to listen.  many people listen to answer, but when they do they tend to have a preset thought in their mind--don't listen to answer.  instead, listen to what is being said, all that is being said.  

One problem I experience with this during meetings is that when I have to speak something and I wait for other person to speak and while I listen, by the time he stops speaking, I sometimes forget what I was about to speak.

Any recommended way for this ?

Les Morgan wrote: part of being a good communicator is to know when you need to ask for more information

And while doing that one has to ask pointed questions instead of any open ended questions.

Pointed questions and, at times, tenacious following questions to get the unclear illuminated has to be done.  I used to work with someone that was in charge of some data servers fore our project.  When ever he was asked a question he did the following: "Well, umm..." and he would talk and say nothing for over half an hour.  Nobody would ever follow up, they didn't want to and only 2 "well, umm" answers would fit into an hour long meeting. He never answered a question, he just talked.

My fix was: I would only ask him, "yes" or "no" questions.  The first time I did, he protested, and I told him: that is a yes or no question. Answer yes or no, then if you wast to follow with more, do so. Our manager took up his cause said we needed to respect his way of answering, but the director butted in and said: I want to here the yes or no and then commentary, like Les asked for.  It was the first time in 10 years of working with him anyone ever had a real answer to a question.

In any case, be tenaciou in getting to your understanding, everyone else will respect you for it.

Les

Les Morgan wrote:Pointed questions and, at times, tenacious following questions to get the unclear illuminated has to be done.  I used to work with someone that was in charge of some data servers fore our project.  When ever he was asked a question he did the following: "Well, umm..." and he would talk and say nothing for over half an hour.  Nobody would ever follow up, they didn't want to and only 2 "well, umm" answers would fit into an hour long meeting. He never answered a question, he just talked.

My fix was: I would only ask him, "yes" or "no" questions.  The first time I did, he protested, and I told him: that is a yes or no question. Answer yes or no, then if you wast to follow with more, do so. Our manager took up his cause said we needed to respect his way of answering, but the director butted in and said: I want to here the yes or no and then commentary, like Les asked for.  It was the first time in 10 years of working with him anyone ever had a real answer to a question

That's funny and I understand how much a pain it would have been to extract the required information from him.

To making him do so in this way, was he in a position below you in designation. If no, then it makes it even more difficult.

In any case, be tenaciou in getting to your understanding, everyone else will respect you for it.

Does that mean assertive behaviour to get the required understanding.

Monica,

we were in the came job classification/seniority level, though i made more than 10K more than he did.  he was in a different group than i was: i was in the program development group and he was in the database group.  what he did or didn't do directly affected my group and specifically my projects.  i don't know what he had over his boss, but he basically ignored her, and she stood up for him in everything.

i worked directly with the Deputy Director, and at one time, the Deputy Director called me into his office and asked: "Is it time we got rid of PersonX?"  unfortunately the thing that the Deputy Director wanted to get rid of him over, and there were tons of other things he should have been fired for, was not an incompetency, not directly any way, but a fairly standard practice for his line of work.

yes, assertive behavior is always best--but not aggressive.  stand firm in your line of questioning until your question is answered, but be respectful.  i guarantee that if you need more information there are others in the room that also need enlightenment, but are too timid to actually ask.  being able to give direct questions to get information overlooked will be appreciated by other, and you will build the respect you desire in the workplace.  Managers take note of those that can speed to the heart of the problem and get the nitty-gritty, but important, details brought to light in ways you and others can understand.

i would give one other point:  do not use trade specific jargon in meetings that have people there that are not from your specific skill set.  i will give you this example that actually happed to me:

i was a senior programmer and working as a consultant, leading a team of other consultants, different company, and reporting to a "technical lead".  the technical lead was not a programmer, nor really from any technology skillset.  she was a human resource manager with specific experience with the real world process we were automating.  we went into a face to face meeting and talked for an hour and a half working out development details on the project.

the project was brought to the alpha phase and the actual deliverables looked good along with the processing, but out timeline and what was being done in the rollout was night and day different than what i understood.  we went into a very serious face to face where i expected to be fired.  after about 10 minutes of talking, she looked at me and said--our terms that we are using mean different things to each of us.  i looked at her and said: it is apparent that they do, and so we started defining terms that she normally used which she was enlightened to find out meant totally different things to classically trained technology people.  i'm degreed in Computer Science.  we went away from the discussion both amazed at how different the terms were for each of us, and we endeavored from that time on to use plain English to describe what we wanted.

Les

Thanks

Les Morgan wrote:

yes, assertive behavior is always best--but not aggressive.  stand firm in your line of questioning until your question is answered, but be respectful.

If the other person is not directly giving that information than he is being unprofessional and you do not respect such behavior. And may have to ask again and again until he gives that requested information. So what does "be respectful" mean when you can't respect such professional behaviour and what does not be aggressive mean when you may have to ask him again and again politely until he gives  ?

Monica Shiralkar wrote:. . . you do not respect such behavior. . . .

No, but you continue to show respect to the person in question.

. . . what does not be aggressive mean when you may have to ask him again and again politely . . .

It means asking again and again politely. If eventually you give up, you may be obliged to say you failed to get the information required. If you get the information required and don't understand it, then you should ask for clarification.
This particular problem is less about your own communication skills than about somebody else's.

Campbell Ritchie wrote:.No, but you continue to show respect to the person in question..

I still did not get this. We respect a person whose behavior is good for the team and if someone's behaviour is not good, then how do we respect him/her?

This particular problem is less about your own communication skills than about somebody else's.

And from our side, from what I understood all we have have to take care is that while doing so we are polite, firm, assertive and not be aggressive.  What could be the example of being aggressive here which we should avoid ?

Monica Shiralkar wrote:

Tim Cooke wrote:The ability to clearly and succinctly describe a problem means nothing if you choose not to.
.

I did not understand this part. Could you please tell what it means ?

I'm talking about the decision you may make about when you need to speak up about something. I was suggesting that even though you may be excellent at explaining yourself and having a constructive conversation with somebody, that means nothing if you choose to say nothing when it would be better to say something.

As an example you may be having difficulty with something you're working on that has the potential to cause a project to run late and you may choose to keep that to yourself instead of letting your project manager know. Even though if you had let your project manager know that conversation would be impeccably executed. I would consider that poor communication skills.

Monica Shiralkar wrote:. . . What could be the example of being aggressive . . .

Do you mean this sort of thing, following?

“What sort of idiot are you? You knew about the problem two weeks ago and you didn't tell anybody. And when we finally extracted a bit of information from you, you spent a good half‑hour waffling and not telling us anything. And stop trying to change the subject. I need to know about XYZ.”

Campbell Ritchie wrote:

“What sort of idiot are you? You knew about the problem two weeks ago and you didn't tell anybody. And when we finally extracted a bit of information from you, you spent a good half‑hour waffling and not telling us anything. And stop trying to change the subject. I need to know about XYZ.”

Thanks.  instead of that is the below the right way ?

"Could you please let me know ABC about XYZ as after that I need to do DEF and update to boss? Actually, I was waiting for it last week "

Monica Shiralkar wrote:. . . is the below the right way ? . . .

Opinions will vary, but I think no. That is much too wishy‑washy. It does vary from country to country and culture to culture; a more direct approach is much more acceptable in North America.

Campbell Ritchie wrote:

Monica Shiralkar wrote:. . . is the below the right way ? . . .

Opinions will vary, but I think no. That is much too wishy‑washy. It does vary from country to country and culture to culture; a more direct approach is much more acceptable in North America.

Like you said it's not the right way. Could you please tell what would be the right way. Like you said it depends on culture to culture. You can give the example for North America.

Monica Shiralkar wrote:. . . You can give the example for North America.

No, I can't. I'm not in North America.
Something like, “Come in and sit down. [...] Why didn't you tell us there was a problem earlier? We need to know about that sort of thing if we are to achieve XYZ.”
Only intervene if the answer is evasive or unclear. If unclear, maybe, “Yes, but that isn't clear; please explain in so even I can understand it.”
Only move off the informal mode if things don't become clear. Look for videojug, a now‑defunct website with all sorts of advice including how to berate somebody at work. All its videos were transferred to YouTube. Videojug took a typically British approach to things.

If you are going to communicate at all, you need to decide what needs to be told, and tell it. A long time ago, I was taught there are three stages to telling something (this was for evidence in court):-

Stand up.

Speak up.

Shut up.

That was to encourage us to be brief and straightforward.
If you get something wrong, the sooner you acknowledge that and apologise the better.

Campbell Ritchie wrote:
Something like, “Come in and sit down. [...] Why didn't you tell us there was a problem earlier? We need to know about that sort of thing if we are to achieve XYZ.

Thanks. And this has to be in a polite way that we have to take care of.

Campbell Ritchie wrote:[
If unclear, maybe, “Yes, but that isn't clear; please explain in so even I can understand it.”.

Is it better if instead of saying "but that isnt clear; please explain it so even I can understand", one says like "this much part ABC, I understood. The part which I don't not understand is DEF.Please explain this to me." to try to make the question more pointed and specific instead of open ended?

Campbell Ritchie wrote:[
Only move off the informal mode if things don't become clear.

I think by moving off the informal mode if required, it means things like sending email keeping boss in CC.

Look for videojug, a now‑defunct website with all sorts of advice including how to berate somebody at work. All its videos were transferred to YouTube. Videojug took a typically British approach to things.

I googled for this but it led me to fashion recipes website:


https://youtu.be/WzEM_ooOWhA


Could you please give the one you are referring to ?

If you are going to communicate at all, you need to decide what needs to be told, and tell it. A long time ago, I was taught there are three stages to telling something (this was for evidence in court):-
Stand up.
Speak up.
Shut up.
That was to encourage us to be brief and straightforward.

Thanks. Got the point. To be brief and straightforward.Instead of saying 10 things and point not coming out properly.

This videojug link (if it works) hasn't got fashion in, nor recpies. You will probably find more in the same category on the right of the window.

Thanks

Les Morgan wrote:
the start of good communication skills is to know how to listen.  many people listen to answer, but when they do they tend to have a preset thought in their mind--don't listen to answer.

This is also what Stephen Covey teaches through habbit 5 of his best selling book "7 habbits of highly effective people". This chapter says "Seek first to understand, then to be understood".

Applies everywhere in life and also seems to apply to IT Industry.

Campbell Ritchie wrote:No, but you continue to show respect to the person in question.

. . .

But level of respect depends on how good or bad the behaviour of the employee is in the team. If the behaviour is good, employee will get respect. If the behaviour is bad, how to still respect him/her ?

Actually, the answer is:

you don't.  they may be a total screwup, but, none the less, you are, hopefully, in a professional environment, everyone knows that person is a screwup, but disrespecting them in conversation will only diminish yourself in the eyes of others.  address the person, the screwup, how you would like to be address... at the very least, emotionlessly.  do not torment them, nor try to show them up.  if they are party of the problem, do no, and i repeat, do not point it out.  instead continue with your inquiries into what is meant and needed.  when you are satisfied with what you think you know, then rehears that understanding back to the group... and ask if that is correct.  if not, then continue to seek understanding.  if it is right, then say: "thank you".  because you have 15 people in the room, and you took 5 minutes to get your answers, you just burned 75 minutes of project time, not just the 5 minutes of your own.

if you follow the things commented in this group.  you will come to be respected for your ability to get to an understanding, but also earmarked as "a good management risk" when the time comes.  you're fellow employees will be more apt to give you fuller details and treat you better too.

Les

Monica Shiralkar wrote:

Campbell Ritchie wrote:No, but you continue to show respect to the person in question.

. . .

But level of respect depends on how good or bad the behaviour of the employee is in the team. If the behaviour is good, employee will get respect. If the behaviour is bad, how to still respect him/her ?

Monica Shiralkar wrote:. . . . If the behaviour is good, employee will get respect. . . .

You have misunderstood me; you need to respect the person, and criticise the behaviour.

This is probably the most difficult thing you'll ever face, aside from a hostile person in the meeting coming after you, but that is another story altogether.

The method i have found the best to approach this kind of "dodge" is:

listen intently to what they say, make notes on information they actually give you, then present the group what you have understood from the diatribe that was spouted. if it was totally not related, and i've had that, then give a summary of what they said, and state: thank you for your answer, but i really need to know... and then restate you actual query from before.  Sometimes it works well to "interject" a hypothesis of what you think at least part of the answer may be... by saying: what do you think about the idea of doing A, B, C and then we can reach D?

if that is not the way, they have to state it then, or they must go on the record as agreeing with you.

continue doing that until all the avenues you need covered have been.

Some may say that is leading them down the path...  to that i say, yes, you are right.  i have found that in the absence of a solution from others, then get them to approve my solution.  it moves you down the road, and everyone is on record as to accepting your solution.  if it turns out that it does not work, then fix the part that does not work, but do so with the same kind of direction with the interested parties as i've described.  once they are on the record as agreeing, there is a phase 2 or extension of the contract to fix what was "misunderstood" because it was misunderstood by all and not you generating a solution outside the box--or without authorization.

Les

Monica Shiralkar wrote:
If the other person is not directly giving that information than he is being unprofessional and you do not respect such behavior. And may have to ask again and again until he gives that requested information. So what does "be respectful" mean when you can't respect such professional behaviour and what does not be aggressive mean when you may have to ask him again and again politely until he gives  ?

Campbell Ritchie wrote:You have misunderstood me; you need to respect the person, and criticise the behaviour.

Understood. Thanks.

Les Morgan wrote:.. at the very least, emotionlessly.  do not torment them, nor try to show them up.  if they are party of the problem, do no, and i repeat, do not point it out.  instead continue with your inquiries into what is meant and needed.

Thanks. Noted this important advice. I will follow.

Since the other person may find it unpleasant that he/she is being asked for this information again and in frustration may instead bring it up that the problem is from my side? In worst case If that happens then will I have to bring things up or still say something like "I don't know anything else, I am just focusing on getting our work done that's all." ?

by the time i bring it to their attention, i have already verified it's not my stuff causing the problem... so be aware that they probably will try to shift the blame back onto you.  what i do is i tell them this:

"i have already verified my paths of execution, and have proven each functions as designed to do so.  if you would like you can come and inspect them also."  in 30+ years of programming, i have never, not even once, had anyone want to show me their dazzling maintenance ability by coming and taking on the task of looking at my code.  then i will add: "if you wish i can come trouble shoot the code in question if you are too busy to do so."  and i am sure to add that in front of their manager, and my manager if possible.  at that point the ball is solidly in their court and you have shown good faith that your stuff works, and you are willing to assist in helping solve the problem.  if they resist, it may come to the point of your manager asking their manager for the code for you to debug.  i have done that.  you don't make any friends that way, but people quit trying to block your requests.

i work on this premise: everything i do is open and available for all to see--therefore, everything they do should be available to me, if they are not willing to fix it themselves, i will fix it for them.  my bosses know this, and it does go that far at time, because my bosses know i can fix the other guys stuff, and the other guys know it too... they don't try blocking me, because they know i'll look and find it myself if i need to.

Monica Shiralkar wrote:
Since the other person may find it unpleasant that he/she is being asked for this information again and in frustration may instead bring it up that the problem is from my side? In worst case If that happens then will I have to bring things up or still say something like "I don't know anything else, I am just focusing on getting our work done that's all." ?

Monica,
i offer this as an example of how that may work:

back in the days of dinosaurs, VB3, we did a huge project and the development staff had huge problems executing any stored procedure, it was just molasses slow!  under SQL Server 7.x, we brought that to the attention of MS and they said: "Obviously it's something you're doing wrong."  i do not claim to know everything, nor anything to an authority level, but we had climbed inside and out of that code, searched the white papers from MS and check every resource we could find, and just burned 800 USD on them telling us: you're doing something wrong.  The code executed, but it was just incredibly slow.

so here is what we did:  We got a LAN analyzer and turned on the packet sniffer.  we captured the full execution path and interaction between SQL 7 and the requesting workstation.  we cleaned all the superfluous packets out, and then sent the full execution stream to MS, giving them our narrative on what we thought was happening.

a 4rd tier engineer, SQL server designer, called us back a few days later, and told us: "i would not have believed it, if i had not seen it."

what was happening was that our developers had DBO rights in the DB.  MS would refresh the stored proc when it was going to be accessed when it was parameterized.  since they had DBO rights, the request was done and the proc would recompile before execution--that was horrendously slow!!!  we tried it on non developer accounts and the compile would then fail because it came from a non amin account, and then be sent to the interpreter for execution.  the interpreter would then tokenize the code and execute it.  the request to compile and fail, then hand off and handling by the interpreter was 4x faster than the straight compile it was designed to do.  what we had fond was a serious design flaw in MS handshaking and compiler design.  the answer we got unofficially from the engineer was: that is a REAL problem!  what the MS answer to the help ticket, officially, was--application works to specs.  to fix the problem they needed to redo the handshaking in Windows itself, and optimize their complier so it was at least as fast as their interpreter, that was not going to happen any time soon.  

they did kick that exact problem around for years, but i think it is still--product works to specification.

Les

Les Morgan wrote:by the time i bring it to their attention, i have already verified it's not my stuff causing the problem... so be aware that they probably will try to shift the blame back onto you.  what i do is i tell them this:

"i have already verified my paths of execution, and have proven each functions as designed to do so.  if you would like you can come and inspect them also."  in 30+ years of programming, i have never, not even once, had anyone want to show me their dazzling maintenance ability by coming and taking on the task of looking at my code.  then i will add: "if you wish i can come trouble shoot the code in question if you are too busy to do so."  and i am sure to add that in front of their manager, and my manager if possible.  at that point the ball is solidly in their court and you have shown good faith that your stuff works, and you are willing to assist in helping solve the problem.  if they resist, it may come to the point of your manager asking their manager for the code for you to debug.  i have done that.  you don't make any friends that way, but people quit trying to block your requests.

i work on this premise: everything i do is open and available for all to see--therefore, everything they do should be available to me, if they are not willing to fix it themselves, i will fix it for them.  my bosses know this, and it does go that far at time, because my bosses know i can fix the other guys stuff, and the other guys know it too... they don't try blocking me, because they know i'll look and find it myself if i need to.

Thanks. Sounds like a good approach which requires high level of confidence.

Monica Shiralkar,

thank you.  after 30+ years in the industry creating or fixing the problems that nobody else wants, i am supremely confident that what i want is going to be the way it is going to happen, but on the other hand, i still try to listen with newbie ears and listen with fresh eyes to all that is presented.  that supreme confidence come with supreme responsibility.

just because everyone is used to you finding the correct path, and knowing the direction to go, does not mean the very foundations of confidence cannot be shaken free in the sight of others, if you pick the wrong solution or give a bone head answer.

being professional means--always on, always respectful, and always give your best.

Les

Les Morgan wrote:

being professional means--always on, always respectful, and always give your best.

Les

What does "always on" mean?

Always on means when you are at work you are ready to work: no hang over, rested, ready to do whatever needs be done.

Les Morgan wrote:Always on means when you are at work you are ready to work: no hang over, rested, ready to do whatever needs be done.

That is delusional. Sometimes they just have to settle for I'm there and limping along.

I took out a garage door one morning because I wasn't feeling my best and didn't pay attention to the speed that the door was opening at when I backed out. I doubt I did much better at work that day.

Of course, the real joke is that by my own measurements, I'm actually only performing at full speed for about 6 hours per work day. The rest of the time, I'm too mentally exhausted to do more than respond to routine requests. A long afternoon nap would allow me another 2-3 hours in the evening, but I'm not staying over at work for that.

In short, I'm not a machine, and even machines are best operated in accordance with their design constraints.

Les Morgan wrote:. . . ready to work . . . rested, ready . . .

A good employer will know that doesn't permit overworking the staff. Unfortunately not all employers count as “good”.

Les Morgan wrote:Always on means when you are at work you are ready to work: no hang over, rested, ready to do whatever needs be done.

Yes, that's the first thing about professionalism.