I have seen a few people unwilling to admit that they don't know...when they're supposed to know. The easiest way out they come up with is 'we will discuss this offline'.

I dunno, most of the time they don’t want to know how I’m going to do it just if I can and when it will be completed by.

I’ve written up action plans, flow charts, lengthy posts. Most go unread apart from myself. So I use this just for myself, if the client wants to look at them they can but by default these days such thins are written for me and the other techies to read not the client.

I had a “explain by default” setting for a while, turns out most didn’t want it explained and I was just wasting both their time and mine. Most of the time they would humour me and let me ramble on (which I do), some would let me know to stfu and just get it done. If they want a deep down explanation I’ll always be willing to give it, it’s just I don’t force it down anyone’s neck by default.

Now for answering “how did you fix it” with “MAGIC!!!” I agree but you should answer with one or two sentences about what was broken and how you fixed it and allow them / invite them to follow up if they would like a more detailed explanation.

I have spent many of these calls effectively just reading what I wrote in the email in the first place. Complete waste of my time.

In my experience it's equally impossible to have a conversation with a human that has a 1st grade level set of communication skills. You write out a detailed account of your problem and then get some copy/paste response back that has nothing to do with your complaint, and suggests that the person did not even bother to skim your complaint, let alone try and comprehend it.

Next time, hopefully they'll make it less clear so that you have to translate the company-specific jargon and feel better that it's spontaneous and careless. </sarcasm>

Yes, and not just because of cross cultural issues, as some of the sibling comments suggest.

I've seen people who don't address questions clearly, sometimes cannot explain their train of thought or reasons for making certain decisions (which may or may not be cargo culting at times), or have especially pronounced challenges in regards to async communication as well - not electing to use a spell checker and usually having typos (both in their messages and code, unfortunately), communicating in cut off short sentences without providing the proper details, or always asking for a call.

I suspect that communicating effectively is a skill like any other and many simply choose not to make an effort to advance it. Alternatively, some may not be comfortable with writing in any capacity (e.g. dyslexia), or alternatively, explaining themselves verbally (e.g. anxiety).

In regards to my latter points, I actually made this site to hopefully give some tips on async communication: https://quick-answers.kronis.dev/

(some of the already existing sites seemed to ridicule these people, which I do not want to do, but rather offer tips)

That said, I am also not perfect and have made the occasional communication blunders myself. That's why nowadays I try to re-read what I'm about to post, or consider how I word things at least a few times before hitting submit. Even in communication that takes place in-person, I try to introduce people to the points I want to make bit by bit, giving them whatever context may be necessary.

As for engaging with others, all you can do is encourage them to share more information as it's necessary, not get sidetracked and be very patient yourself.

What part?

I explain the difficulty we have in designing something and you jump at my throat without even seeing what we do.

This is the opposite of what I want. Stop condescending and just tell me what actually went wrong.

This is a pet peeve of mine. I'm astonished by the entitlement of superiors asking blind questions like “When will it finish?” Well, the finishing time doesn't exist in a vacuum, so if you had told me why you were asking, I could have answered properly. Rest of the dialog goes like this:

- It will finish in 10 days.

- But we need it at the end of this week for such and such reason.

- (Thinking “Why don't you fucking tell me that first.”) OK, we can prioritize it then. No problem.

Based on my experience regularly communicating technical information to non-technical people, the above suggestion works out very poorly. Each technical detail is a hurdle for the listener, causing misunderstanding, frustration, feelings of inadequacy, and doubt about your competence as an advisor and communicator. Generally, they respond like most people do when confronted with something unpleasant; they tune out your message. My advice is to include the minimum possible technical details and to express them in the clearest possible non-technical language.

Until you get the person who questions everything, draining all your time. Then they become reliant on you, and stop thinking for themselves.

Few production incidents are enough to change this mentality. I'd rather write more verbose but "obvious" code than "clever one liners". I feel sorry for anyone who has to understand someone's DSL on the fly when there's an outage and your business is burning through X$ per minute of downtime.

(On the other hand, you probably want to structure your production changes in the way that they are easy to roll back without understanding everything, but that's other conversation. Either way, the thought that someone may want to chase me after work because my code broke and they can't understand it is enough for me to stop being clever).

The problem comes in when people think they do know 'what' it is, and they're just... adamant that you 'computer people' don't 'get it'.

I can't speak to all my clients - some are great - but have had some in the past that just insisted I was being obstinate or obtuse or difficult by asking clarifying questions. Then they'll take hours/days obsessing over shades of blue for a screen, then... the morning of 'feature launch' they'll question why there are no notification emails for feature X, when... that morning is the first time those words have ever been spoken.

But... fortunately, I've not had project work like that in a while :)

It is a matter of culture too.

I'll take the example of the desk clerks you have to face as a citizen or customer in administrations and companies.

When I lived in a country of Northern Europe, they would often say "I am not sure, wait a minute and let me check in that book" or "I don't know, I will ask/check and call/mail you right away". And they did it and it was fine. A tiny delay and everything is solved for good. You come out from there with a smile and they have learned something for the next time they meet the case.

Now that I am back in my Southern European country, the guys (well, it's 99% women) in the same position will never admit they don't know or they aren't sure of something. They will assert whatever weird/outdated/wrong assumption comes through their mind with definite certainty. Even if you gathered information beforehand and tell them that the rule says otherwise. They feel that checking or asking for help would undermine their authority or make them look incompetent (as if anyone still had any hope about that...). And they will only call the higher up when, after 2 months and the 3rd visit for nothing except getting contradictory information and requirements, you start yelling and they feel that they are less than 30 seconds away from getting punched in their face. Then the higher up solves the problem (which should never have become a problem in first place) in 2 minutes. But they will keep on 'working' like this for 40 years, they'll never recognise that their work and service would be much more efficient if they just said "I don't know" instead of inventing wrong rules.

I'm not sure what you're trying to show here, because just because you can write a positive reply to that here on Hacker News does not in any way change someone's actual trepidations with expressing that to their actual manager.

Plus the entire subtext of that reply is just "I don't want to acknowledge the possibility that I have made any mistakes, and so I am going to reduce your problems down to cliches."

Manager: Why did you delete the production database in the middle of a work-day, no less?

DBA: My decision was based on all sorts of things you can quantify, and then all sorts of gut feeling. I have no idea how I do that. Do not ask me to explain my decision, or you are forcing me to make up a story.

Manager: But, you crashed our client's entire business for a whole day!

DBA: I can't explain how I work.

(Somehow, I don't see that flying.)

This. I have PMs who will ask me over and over until I give a number and I've learned to stand my ground. Because if I don't, I end up being responsible for the estimate I've given (as I should).

Now I make it clear that I will not give a number until I know more. Just a few weeks ago I was asked to give an estimate of how long it would take to do an integration with something I've never used before. I said, "I need 1-3 days to learn the product enough to give an estimate". What I get back is "can't you just give WAG". But this time around I said "You have two choices, 1. you give me time to learn what I need and then I'll give an estimate or, 2. Find someone who already knows the product to give you an estimate"

This is unbelievably presumptuous, narcissistic and smacks of technological elitism. You don't know whether or not the client can understand -- all you know is you're unwilling to explain it to him.

If you don't want to get along with clients, if you're willing to take the risk of alienating them, take this article's advice and tell your customers, "You can't do that, and you also can't understand why -- trust me."

If you do want to get along with your clients as well as grow your business, try this instead: "Well, our system can't do that at the moment, but I appreciate your making this suggestion for future improvements."

Maybe it's a polite lie -- so what? You've empowered the client, made him feel as though you care about his needs. You've avoided opening an emotional exit door the client my well choose to walk through.

I think the problem is that he is simply ignorant of what people actually have to do when creating complex technical things. I think he honestly thinks that he can go do a couple of client meetings, get some paperwork signed for some custom work and there's vending machine in the back that spits out custom software. The thousands of hours of mind numbing things like, looking at trace logs, or defining a controlled vocabulary so that your team and the customer's team can even communicate on the same level, are absolutely not within his sphere of understanding. In those matters he's as incompetent as I am in his arena. The difference is that I know that and don't disparage him when he says things like "executing this NDA really took a huge amount of effort." I have no idea if executing an NDA involves anymore than 5 minutes of actual work and lots of thumb twiddling or if it's an active, engaged process one can spend hundreds of hours on. I know that he thinks that when he does a 30 minute deal closing meeting, that he did all the work to make it happen and should get all the credit. Never mind the last 6 months by our engineering team working nights and weekends to fulfill a custom customer requirement.

> He's given you a specific case that he thinks is a big deal. Why won't you address it?

I'm not quite sure I follow. The way I see it, I have relatively few ways to address it:

1) Tell him to go F off, which I'm not sure does anybody any good.

2) Do the "let's trade jobs for a day" thing. But the only things that he would be able to do, because mine is a job that requires lots of domain knowledge in nearly every task, are the most meanial and time consuming ones. I'm not sure it'll provide the right kind of impression if I give him a task like "here's a list of 20,000 numbers, find all the ones with a non-numeric character in it".

3) Reorg this part of the company so interactions are limited. This might be the only direction that prevents undue internal conflict and keeps us in our respective lanes.

4) Ignore him and hope he learns to respect other people's work. In my experience this doesn't happen since this kind of behavior is largely ego driven.

5) Openly confront him (different from #1). This is the direction I'm presently going, but it's annoying and time consuming. I don't particularly feel the need to justify or explain the details of my job to him (especially when he won't understand the details anyway), senior mgmt already holds my work in high regard and that's who I have to answer to ultimately. The other departments in the company also work well with me and respect me. However, I'm rapidly moving towards #1 or #6.

6) Quit. But as a senior manager in my company, and the only person with domain experience with our customer base plus the technical training to be able to handle several different roles at once, I know that it would sink the company (which as a shareholder does me no personal good, and would put a number of people out of work who I'm responsible for). I think that would be irresponsible unless I knew there was a reasonable replacement to fill in for me.

> This isn't about you. It's about him.

It sure is, a small company like ours doesn't have the time or resources to ego stroke an employee.

> BTW - If he thinks that something can be done better, it doesn't matter if said thing is technical and he's not. Again, stop questioning his competence.

I'm not sure I follow. People are competent in their own areas and incompetent outside of that. I think he's quite competent in his as far as I can tell. He's not competent in mine. He's not offering suggestions for improvement -- which I'm always open to, from anybody regardless of field. He's openly questioning why a complex 6 week project he handled the contracting for takes 6 weeks of active, hands-on work, and not 45 minutes, a hand shake and a signature so I can then move on to help him with another sales pitch. It's stupid and unreasonable. For goodness sakes, he's been with the company for a few years now and to my knowledge has never even installed the software!