Ask HN: Impossible client? Impossible playing field?

Maybe you're talking with nincompoops.

But maybe -- and perhaps more likely -- you're just a terrible communicator.

Perhaps you have genuinely poor written communication skills, and are incapable of holding a conversation without the proper social cues that non-programmers or other coworkers need to feel like you're not exerting your ego.

Communication skills, social skills, soft skills, they are all skills. They're not things that necessarily come naturally to people, and they're things you can practice, and things you can get better at.

I can't think of one good reason to have a casual conversation with anyone and mention GitHub. The only situation is if I'm a GitHub salesperson, or we're having a very non-casual conversation comparing tools.

Those aren't normal conversations. GitHub is not a tool that normal people use. Suggesting it to someone who is not a professional developer demonstrates a complete lack of understanding of your audience, of their skill set, of their engagement level, etc.

By definition, being a developer takes you out of "normal," so you're not really well-suited to judge how other people are receiving you. This is why you feel like it takes "large expenditures of energy on my part" to talk with them. When, strictly speaking, no-one has to talk with you. Talking is entirely about the other person.

Growing up, I did speech contests, which teach you how to present and how to deliver an argument and how to articulate your ideas well in a short span. Something like Toastmasters would help you practice that today.

That doesn't help you social situations, or in professional relationship building like business requires.

A friend of mine has a coworker who is socially rude. The coworker constantly interrupts, and their voice gets higher and higher pitched and they talk faster and faster when they think you're not "getting it." The problem is, all the senior developers "get it," he's just so enamored with his idea that he's not seeing the practical issues. The coworker is really looking for agreement and praise, not discussion and critique; his statements are leading, and his questions are rhetorical.

My friend finally sat this coworker down and explained how he needed to learn how to act like a normal human being having a normal human conversation. My friend now physically intervenes in conversations and points out every instance of verbal malfeasance, and the coworker is learning to control himself and convey his ideas reasonably, to think before he responds, and to actually consider someone else's perspective for once.

This friend, years ago, would stand over my shoulder and edit my emails with me.

My friend doesn't scale, but maybe there's someone you trust -- not a programmer, a normal person -- who can do things like edit your emails for you -- that's what editors are for -- and who can shadow you in conversations and talk with you about them afterwards.

Your suggestion to nerdfiles of Toastmasters for practice is great, I hadn't heard of it.

A book I really liked, which I hope has helped me with social interactions is Dale Carnegie's How to Win Friends and Influence People:

http://en.wikipedia.org/wiki/How_to_Win_Friends_and_Influenc...

I also agree with your point that mentioning Github to a client (probably a non-developer - that's why he's hiring you :) ) was a bad idea.

I think it's telling about the audience here at HN that no-one, in a set of threads about communication skills, called out that my second and third sentences were positively and unnecessarily brutal.

Some commenters may say, well, we see the overall point and agree with it, those two details could be overlooked.

But, the whole point here about empathizing with the client, is that those are the two details that matter.

I could have structured this argument a little differently and been much more positive (a compliment sandwich, they call it) and lost none of the impact.

You're right in that your second sentence was unnecesarily harsh.

However, the third one didn't strike me as so brutal, but I also agree that the beginning could have been worded better.

This reminds me of several discussions on how many people with some characteristics of aspergers/autism are bad communicators because they're worried about being right and not about the other people's feelings - and believe that saying what they consider to be the truth doesn't offend.

(I'm searching for some interesting articles on the subject, but I didn't save the links and now can't find them).

I have very bad communication skills myself, that's why I found Carnegie's points about other people's feelings so important (others might find it obvious).

Edit: I also think that most people in Hacker News are more inured to criticism, or able to take it better, and so might be harsher themselves - or not think it wrong when someone else is harsh like in your case.

You and your client are two people separated by a common language.

I followed your link to Github. This is the first item:

   "Improved scheduling with jQuery-based time/date-picker.
   Removed secon"

Well not exactly, I skipped over:

  "Merge pull request #31 from ASoft-se/bugfix_get_assets"

Plus:

  "Clone in Windows"

And:

  "Branch: master" etc.

If I'm your client, do you really think I want to deal with that? If I'm your client do I even care about that level of detail?

There are some sausage factories which are interesting, architecture is generally one for which people love seeing the process of creation. Most aren't, as your experience using VIM in public attests.

Your client cares about a few simple things: when it will be done, how much it will cost, and what it will do. If your email explains those details it will be successful.

The fact that your client saved trying to understand your solution for the weekend indicates meaningful effort on their part, but it's not surprising that they are baffled by Github. It's not for lay people.

Good luck.

As mentioned by vitovito your problem is most likely effective communication.

Take this post for example, there is very little structure, the main points are clouded by seques that don't lead anywhere, here is how I might have written it instead:

"Hi everyone,

I have been encountering a problem with several of my clients, both past and current. It seems they become intimidated whenever I start discussing anything vaguely technical e.g. Version control ala GitHub.

Have any of you come across a similar problem in your line of work?"

It might be worth taking a class or at least picking up a book on communication, presentation and debating which should cover many of the problems.

On a separate issue you posted an excerpt from an email. It seems t be that the client would not be requesting information on version control for a website (although that may be the case) - in my experience this is probably a query regarding content management in which a CMS would seemingly be a better fitting solution - this should be taken with caution as I do not know anything about this client and so could be completely off course.

As others are pointing out, I think your issue is being able to communicate effectively. But then, you might ask what is effective communication especially in your context? Clearly, your client is not as tech. savvy as you might want him to be. So instead of mentioning Github directly for example, you need to think about the end goal that you want to achieve. In your example, I believe you wnat your client to agree to use Github for tracking the code changes, communication etc. But instead of saying that directly, you could say "Hey as you mentioned that the site needs periodic updates, I propose using a tool that will reduce the time and error to put a fix and update your site regularly. This tool is available online and can be accessed both by you and me anywhere through internet. We can do it without this tool but it will increase the time to make changes to the site and ultimately cost you more"

Now you have given the "what" to the client and not the "how". The "what" is thte importance of using the tool (github) but you don't want to say that directly. The client will see that you are giving them an option to reduce their risk/time to update the site which is the end goal, not github. Github is just a medium that u decide for the client.

The next question from the client could then be "Ok so what would it take to get this tool up and running. how much? how long? " But now, you are already half way through.

My first instinct is, when a client doesn't know what Github or something like that is, just use it and teach them later if you must. For issues like this that have relatively limited downside, better to ask forgiveness than permission and just get on with it.

Regarding his response, that usually means call him and explain it in a conversation. Hackers tend to be email-oriented b/c it's asynchronous, but many business people tend to be phone-oriented.

Short terse emails like that where they don't elaborate on why they don't understand or ask any followup questions tend to be a strong signal that they're not email people. So just schedule a call and explain instead.

Anytime you have communications problems just do the following. Tell them "Hey $name, I'm really focused on getting this project done the way you want it. But I seem to have misunderstood some past points. Could you refresh my understanding of the goals we have to work towards? Thanks!"

They will either:

- Ask you what your doubts/issues are.

- Make up their minds as to what the next step is.

* Or fire you. :) Either way, you dont want to work with people who you cannot communicate with.

"Either way, you dont want to work with people who you cannot communicate with."

Don't agree with this at all. There will always be non-technicians who you have to communicate with. If you can't express what it is you need to communicate in non-technical language it is your problem, not theirs.

i would rightly fire someone who refused to at least try to make an effort to see it from my point of view, and continue.

What I meant is that he should not work in places where communication is not important. Meaning companies where there is a culture of them versus us. Of course its important to be able to communicate to non-technical people. It is a required skill. So, can I have my job back? :)

Agreed, but regardless of who's at fault with the lack of communication you still won't WANT to work with them. The concept being that you should want to do your work and be happy, so fix your communication problems regardless of who's fault they are.

First mail:

I can still work with any site content or typographical issues until we meet next (which may be after I heal over the weekend). So I should be healed up before next week.

We can collaborate on the minor issues of the site using [link to issues page for repo] or we can collaborate through e-mail. This way we can have a digital paper trail.

The link to github is also available on the bottom footer of your site. I use github to manage my development of your site, so it may be beneficial to become familiar with its issue tracking system: https://github.com/blog/831-issues-2-0-the-next-generation

Github's issue tracking system has become much celebrated, and issue tracking itself is a very important part of developing sites.

Mentioning anything like github or modern tools, on average, puts me in a position where I am either shocking or apparently showboating in a conversation. Everything is testosterone, and my mild speech impediments make it next to impossible to converse with people without large expenditures of energy on my part.

I'm honestly at wits end, as is obvious by the organization of this post.

It's not schizophrenia, but over the past year, it has become markedly clear that I am the only person I actually can talk to... Maybe I'm just in the wrong crowd. Or maybe the crowd is too small?

How has your life changed over the past year? In reading some of your comments and replies, you seem kind of defensive. I know it's kind of natural when you're getting picked apart by your peers, especially in this environment (a generally respectful crowd). However, I would consider that some of the communication failures with your clients (whether your fault or theirs doesn't matter) might be caused by insecurity. I've known a lot of programmers in the past who were naturally insecure people and this manifested itself in conversation. Where they would say "Yes, I'll set up a cloud based solution with redundant storage and a jquery front end" (and feel a bit of satisfaction about sounding smart) I would just say "Yeah, I'll get it done and send you a login". After a year of working, everyone came to me internally with issues instead of the guy who's been here for 8 years.

Anyhow, don't get down on yourself. It seems like you're in a frustrating situation in general and you tried to air out one grievance to get some relief. Unfortunately it appears to have frustrated you more. Just realize that a lot of people here are trying to help. Also, no one here can fix your client so naturally they're going to concentrate on the only thing they can help fix: you. You might have to go out of your way to accommodate your client, but that's why you get paid right? If it isn't worth the money then stop taking jobs with non-technical clients.

Or, like many people, you are less naturally good at communication, and you need to actively improve this ability.

How do I track issues then? I sent the link to the issues page.

What is all this sexy and intuitive UI for if I cannot even mention it? Github repos look just like file folders in most GUI OSes.

This is a good example of what I meant when I wrote, "talking is entirely about the other person."

"How do I track issues" is almost irrelevant, because it's not about you.

It's about the client.

What is the easiest, most comprehensible way for the client, whoever they are, whatever their level of schooling completed, wherever they live, to tell you what they need to tell you, whatever that may be?

Making them comprehend an issue tracker (which is a term only programmers use, normal people don't think of themselves as having "issues" which they need to "track"), which regardless of the GUI that GitHub built, is still constructed atop a system designed by someone who writes Unix kernels for fun, is not that way.

Maybe that way is, they call you on the phone and explain it to you for every issue. Maybe that takes up too much of your time, so they call your secretary and you call them back once a week and do a big round-up.

Your job as a consultant is to figure that out and provide it. It's not to write code. That is secondary to being able to relate to someone's business problems.

Then I should scratch the CMS, github, and only contact him by phone for typographical and content issues.

I see now. Thank you. With luck, these experiences will be very much transferrable to other projects.

I've already recommended it above, but I'm going to reiterate the suggestion of Dale Carnegie's How To Win Friends and Influence People.

It's even available online :)

http://erudition.mohit.tripod.com/_Influence_People.pdf

I really, really do not wish to come off this aggressively, but are we following the reasoning: mentioning github > probably a bad writer/should re-assess abilities to communicate?

Really?

I don't think "mentioning Github" is the only piece people are using when deciding to question your communication skills. The word "microcontroller", except in certain extremely specialized situations, should probably not be used with a client. I understand it's a hard pill to swallow. I mean, you're both speaking English. Why does it seem like you're not speaking the same language?

In a way, you're not speaking the same language. Try assuming your clients have no concept of not just programming, but any of the process of building an application or solution to a problem that uses technology. Don't discuss details. They are probably paying you so that they don't have to worry about the details.

By way of example: I have the reverse problem with my wife. She is a nurse. When telling me about her day, she used to fly through a great deal of technical details using an amazing number of acronyms and abbreviations that I found not just unintuitive, but completely incomprehensible. I genuinely care about how her day was, but I found myself exclaiming in exasperation, "I have a clue what any of that means!" She now explains only what is necessary to get the point across, and defines acronyms as she goes along, if necessary. That works, but, in your situation, I'd abstract my communication at least one more level than that.

Think about it from the client's perspective - using Github issues might be your preferred way of tracking the changes he requests, but it is unlikely his preferred tool. He just wants to email you the changes he wants and have them made - the implementation is not his concern.

As soon as the client feels like he doesn't understand what you are saying, you stop becoming a problem-solver and start becoming a problem. In addition to whatever responsibilities he has on his end, now he needs to try to figure out what you are saying. The key to a happy client is removing problems from their plate.

Here's a different way to communicate the same things as your original email:

    $CLIENT, you mentioned that you wanted a few changes 
    to the content of the site. If the changes are easy
    to describe, you can just email them to me and I will
    take care of it. Otherwise let's sit down/have a 
    phone call about the changes.

    I've also done some research into the digital 
    signage that we discussed. I found an option that 
    will cost $30-$40 per sign, is that within your 
    budget? I can present all the options I've found 
    at our next meeting.

Notice that I tried to avoid any deep technical details (e.g. after you email me the changes, I will add an item to the bug tracker and do feature-branching to implement the changes then deploy to the staging server). My version is not perfect either, but I think it would be better received.

I read your version, and I get an entirely different gist than what I got from reading nerdfile's for part 1. I thought he was talking to the customer about using version control. In your version I get issue tracking. I've had both conversations (issue tracking & version control) before with non-technical people.

An easy thing nerdfiles could have done was to attach the email in question. In that situation, there's no need for the client to dig through their emails to find something they may or may not have deleted, may have ignored, or had end up in their junk folder. Then you can trade out "If you did not receive it, please let me know" with "I've attached it for your convenience".