How do I politely make sure superiors actually understand the written communication I give?

Question

Maybe this is not the place to ask. Please point me to the correct site if that's the case.

This happens often: I have a slack conversation with my manager and my PM, and at the end of the conversation I like to do a summary. Example:

OK for release on 20 we need to:

• write script to handle (common name for feature X)
• write script to handle (common name for feature Y)
  ...

Is everyone OK with this ?

Both my manager and the PM acknowledge this summary. After 5 minutes, in the same slack channel my manager starts discussing with the PM:

PM, we need to manually handle (another common name for feature Y). Can the support team manually change the data?

Both (common name for feature Y) and (another common name for feature Y) are used interchangeable both by me and them so that shouldn't be an issue.

How do I ensure that they don't just skim over the summary but actually read and understand what I've written?

(Bear in mind that one of them is my superior and he was extremely annoyed when I pointed out that we just discussed that and there is no need for manually handling it.)

Edit: The example above has people looking in the wrong direction, so I will give another that just happen.

End of May we had a consolidation release, in which my team did some cleanup and several optimizations. One of the changes involved consolidating 3 microservices into a single one (they were practically identical with only a few lines of code difference - very hard to maintain the common code). The change was presented every where, several emails and slack conversations.

Apparently that wasn't enough, yesterday the PM saw that those old micro services were not running and started them up, creating a world of trouble. All of them had a comment stating "backup, do not start" visible in the cloud interface used start them up.

Answer 1

They are not reading your notes since they don't feel it's valuable use of their time (or they are simply lazy).

You have a bunch of options.

1. Let it go. If it only happens once or twice a day, who cares. Just answer "we can handle Y with a script" and be done with it
2. Try to gently nudge them to see the benefit of reading the notes. Answer "we can handle Y with a script, see meeting notes (insert link)" If that happens often enough they may notice and figure out that reading the notes is actually useful.
3. Talk to your boss about it but Carefully! Do not blame or judge or ask them directly to read the notes. Explain why do you write the notes, what you need to get out of this and what the problem is. The problem MUST be stated in terms of business impact and detriment to a business goal NOT in terms of a behavior or desired outcome or "I don't like it". If you can't state the problem objectively as a negative business impact, just let it go.

Answer 2

are used interchangeable both by me and them so that shouldn't be an issue.

Maybe this is zooming in too much, but I have found it to quite often be an issue. Usually it just wastes half an hour of a meeting, but the most extreme example was where the business analyst had two different workflows as he envisioned two slightly different processes and only one existed as the devs assumed that they were the same thing, just messily documented. This misunderstanding continued for several weeks.

I don't have a good answer for your title question, at least not one I am confident in, but make sure that your manager also considers the terms interchangeable. As I have had plenty of conversations and meetings where one person was using terms interchangeably and others thought they were two separate things.

Answer 3

Why not interject in the conversation, "Does script y^1/y^2 not accomplish y^2?", where y^1 and y^2 are the two common names.

Answer 4

Miscommunication happens for many reasons. Perhaps most notably in your case with your superiors, a task that consumes your life for several days might only be one small blip on their busy radar.

They also are coming at the problem with a different context. For example, I have chased problems that to me have one underlying cause, but to PM are 5 separate symptoms being complained about by 5 separate customers. I have to take care in those cases to communicate that fixing it for one should fix it for all.

I have also chased problems that to me are 5 distinct things, but to PM are just "the <microservice> startup issue." In those cases, I take extra care to communicate that fixing one thing doesn't fix everything.

You can't really avoid miscommunication altogether, just try to minimize it, and keep working to bump it back on course. I would respond to your example something like:

I thought we had agreed to handle that with a script. Are there problems I should be aware of that a script wouldn't address?

The purpose of the question is to give their ego an out, by allowing for the possibility that there is other information you aren't aware of. Sometimes even there is.

Also evaluate where you are communicating. At my workplace, a chat conversation isn't taken nearly as "officially" as a Jira comment. When an agreement is made in chat, I try to always copy it to the relevant Jira, and then note in the chat that I have done so.