Ask HN: What are common communication failures and approaches for defusing them? | Hacker News Reader

Ask HN: What are common communication failures and approaches for defusing them?

2 pointsnewsbinator2 comments

I'm putting together a list of common scenarios faced by devs in the workplace, and hopefully some smart patterns for mitigating them.

Can you think of a high-stress communication issue you experienced, and how you managed to make it okay?

Some of us work from offices, most of us work from home (at least right now). Some of us work for companies, some have our own clients.

I'm thinking scenarios like:

* During your first sit-down with your team lead, he/she expresses some concerns.

* Your client runs out of funds mid-project, but you still need to insist that they pay you.

* During code review, a senior dev finds fault with a dozen things you've done, but you're sure it's a difference of style, not a right/wrong approach.

* A customer you have been interacting with goes over your head to your boss's boss.

* The designer has made a pretty design that makes it a huge pain to implement. They refuse to budge on even small changes.

* ???

I'd love to hear some situations you experienced in your career.

Things that could have blown up if you had said the wrong thing, but which you managed to turn around by saying the right thing.

Does anything come to mind?

The most consistent person-to-person communications error I've experienced is the failure to document decisions clearly and concisely in a mutually agreed upon interpretation of the decision. I've been in multiple contentious meetings where everyone (in theory) made their arguments about whatever the issue was and then, after it seems like the air has been cleared and some sort of accommodation or decision has been made, everyone disperses, without a common agreement on both what the issues are/were and the decision(s) that were agreed upon.

It seems horribly bureaucratic, or an attempt to cast blame, but it helps to ensure everyone's on the same page (even if they disagree about whether or not the "right" decision has been made, they share common facts). It helps build continuity in an organization as it grows, and gives historical context to "how did we get here" sorts of questions. If it's pure code you can look back in the revision history, but if it's organizational communications, telling someone to search mailing lists or Slack or whatever is not helpful.

The most helpful documents I've either written or had to consult stated what the problem was, what the key issues were that needed to be resolved, and what the resolution was. For bonus points you include who was involved and what their roles were. For more bonus points you include the specific conditions that should cause the decision to be reviewed (not necessarily reversed or altered, but reviewed).

It's rarely a problem of nefarious intent, while often a problem of mental models that don't match reality.

Seek to expose and challenge your own mental model first and many challenging differences will be difussed.

Reply on news.ycombinator.com