Very poor communication by most of my colleagues

Question

I work full time as a senior software engineer as a contractor for a 10 person tech company which is remote-only. All communication is text-only with the exception of twice-a-week audio meetings.

Some of the issues I have noticed with communication are:

1. People will just PM me some random logs with a "?", no details added. I obviously don't want to waste an hour trying to figure out what they mean by analysing the logs. When I ask them follow-up questions, they stop replying.

2. People will just ask me a question with a one line statement with no background context added. I have tried answering with very little info. This person didn't clarify or thank me. Later during a meeting, he didn't point fingers but he complained that he is struggling with the codebase.

3. Junior developers will ask me questions. When I answer them, they never reply and tell me if it worked or not. Sometimes, I waste a lot of time finding a solution and then they are like "oh, the first solution already worked, I don't need help anymore".

4. If you ask someone something, sometimes they don't reply and leave you on read forever.

5. Please or thank you or even hi are words no one ever uses.

I can live without thank you or greetings. I am a contractor and more interested in being productive and collecting my invoices. But it does affect my productivity. What should I do?

Answer 1

As a contractor you are always a bit on the outs. You will lose any HR type disagreements with a fulltime employee. It is the nature of the work. So you have to be careful here.

Since it is not your responsibility to train or make others productive (only that you are productive), the path is clear here. For numbers 1, 2 and 3 I would reply with a "what have you tried?" or "can you "clarify your issue?". Those kinds of follow up questions are reasonable and something I would expect from a person that I was seeking help from.

Think about the times you need help, what do you do? You might provide the log file, and any background information with the issue you are having. This is the right way to handle an information request. What you are experiencing is asocial behavior, not harmful but not social.

Once they do not respond the responsibility becomes theirs not yours. And if your company saves text chat logs, you have documentation that you did what you were supposed to do.

IMHO staying out of all the HR crap is a massive benefit of being a contractor. Being a productive contractor often helps you survive layoffs and downsizing. Managers tend to like the work being done without the drama.

If a coworker does ask for an information request that will prove to be a lengthy investigation, ask your manager for guidance about how he would like you to spend your time.

Answer 2

As a contractor, you're more than likely being treated as a disposable resource and a bit of an outsider. People also can be resentful that you're being paid more than a regular employee (even when you're not).

It's perfectly reasonable for you to ask for more information when being asked for information.

1. People will just PM me some random logs with a "?". No details added. I obviously don't want to waste 1 hour trying to figure out what they mean by analysing the logs. When I ask them follow-up questions, they stop replying.

In these cases, just ask for the additional information/context that you need to investigate further. If no information is forthcoming, assume that the query isn't all that important and just carry on with your work.

2. People will just ask me question with 1-line statement with no background context added. I tried to answer with very little info. This person didn't clarify or thanked me. Later during meeting, he didn't point fingers but he complained that he is struggling with codebase.

Same as above. If there's any come-back on your calls, just point out that additional information will result in appropriate help.

3. Junior developers will ask me questions. When I answer them, they never reply and tell me if it worked or not. Sometime, I waste lot of time finding solution and then there are like "oh, the first solution already worked, I don't need help anymore".

Be as helpful as you reasonably can be with the new developers. They sometimes don't know any different, so hopefully leading by example will rub off on them and they'll learn how to communicate and team-work as a result of your interactions. It might not pan out that way of course, but it's a start.

4. If you ask someone something, sometime they don't reply and leave you on read forever.

If non-response is affecting your work, then follow up after a day or so and tell the respondent (or more accurately, non-respondent) that this open question is holding up the project. At least then you've got something in writing and you're showing you're not really willing to sit by and not be answered to.

5. Please or thank you or even hi are words no one ever uses.

This shouldn't stop you from saying Hi/Please/Thankyou of course.

Answer 3

All communication is text-only with the exception of twice-a-week audio meetings.

The main problem seems to be that your coworkers don't know how to communicate properly in writing (or they don't bother). One of their main way of not communicating properly is that they just stop replying.

But you have twice-a-week audio meetings!

Here is a suggestion.

Keep a file or folder in your computer in which you copy-paste all these unfinished demands for help. That includes everything covered by bullets 1-4 of your list.

When the next audio meeting comes, make a point of going through all the unfinished demands one by one.

Don't do this in a confrontational way. Frame it as if you are truly trying to help. Which you are.

Pros

• This will force your coworkers to either clarify the issue, or explicitly tell you that they have already found a solution. They won't be able to just stop answering, since this is a real-time audio meeting.
• If a coworker really needs your help but really lacks the skills to communicate with you in writing, you will be able to help that coworker much more easily this way.
• If a coworker doesn't want you to bring up their demands during the audio meeting, they will naturally learn that when you ask them for clarification in PM discussions, "stop replying" is not a good strategy.
• You will be a lot less stressed/distracted by these written communication issues, since you know that they will get resolved at the next meeting.
• You will look like a reliable team-player that really cares about what everyone is working on and what issues everyone is facing.

Cons

• There is a risk your coworkers will think the meetings always drag longer because of you.

Answer 4

It is not what a lot of software engineers (myself included) like to hear, but you but you need it to improve your team's social dynamic so they see each other more as people and less like Chinese Rooms. This is especially important as you are all remote.

Push for daily standups and retrospectives - Standups can be shorter and possibly replace the twice a week audio calls. But frequent shorter communication is better. Apart from more frequent occasions to raise issues, it also gives more interaction time between the team. I'm aware its not necessarily your job to sort out the meetings, but as its affecting your team's productivity its worth raising it as a suggestion to the team lead.

Reply the cryptic messages with a call - Its much easier to get to the bottom of a problem verbally. It also has the affect of appearing responsive and helpful while discouraging raising trivial issues with you. Calls do mean you have less written records if you are concerned about your productivity being used against you then write a short summary in chat after the call

Turn your camera on in the audio calls - it helps build a connection, even if it means you need to brush your hair in the morning.

Most Software Engineers tend to be dismissive of team building, but you don't need big team bonding events to improve the social dynamic, just being more present and visible is usually enough

Answer 5

Each of your five points:

---

1. People will just PM me some random logs with a "?". No details added.

Respond in kind.
Reply to "?" with your own "??" and forget about it.
(Consider cc'ing, NOT bcc'ing, your manager to make them aware of demands on your time.)
If the asker responds with sufficient details, deal with that issue appropriately.

Either Oscar Wilde or Victor Hugo (both literary giants) sent a telegram to his editor with only "?".
The editor (au fait with clear written communication) telegrammed the response "!".

---

2. People will just ask me question with 1-line statement with no background context added.

Reply asking for the missing pieces. Don't waste time assuming you know what is being asked.
If the asker ghosts you, forget about it.
If the asker provides additional, but still insufficient detail, then reply asking for further elaboration that YOU would need to answer.
If the asker provides the context you need, do your best to provide an answer.

Often, the asker, being forced to compose an ask-worthy question will find their own solution.
See the second paragraph of this SE answer.
Maybe you will be notified, maybe you won't. Don't lose sleep over it, either way.

---

3. Junior developers will ask me questions. When I answer them, they never reply and tell me if it worked or not.

You did your best, and the issue went away. End of story.
We were all once "junior" somethings. Accept it and get on with things.
Maturity is attained, not imposed.

If you are unsure about your interpretation of the question and/or applicability of the answer you provided, then it's up to you to follow-up inquiring about the problem/solution. None of us knows everything there is to know about a complex system.

---

4. If you ask someone something, sometime they don't reply and leave you on read forever.

There are any number of plausible reasons for this behaviour, including:
- Cat walked across keyboard, deleting your message before it was read,
- Death in the family; on spontaneous "grief leave",
- You asked for "the launch codes" that are above your security clearance,
- Askee is insecure about their own ignorance, and has "put their fingers in their ears, chanting "La-la-la-la can't hear you...",
- Askee considers you a threat and is reluctant to aid in your ascendancy,
- "Etcetera, etcetera, etcetera..." (Yul Brynner in "The King and I").

You can only control your own behaviour.
Accept this and do what you can to resolve your situation by other means, if possible.
"Life wasn't meant to be easy."--- Malcolm Fraser (former Aussie PM)

---

5. "Please" or "thank you" or even "hi" are words no one ever uses.

Welcome to the "social media" generation.
"No one" composes, writes and posts letters anymore. Times change.
Be grateful if Capitalisation and punctuation are used to make the message legible and decipherable.

---

You could always ask your manager to issue a "style guide" to ALL involved (avoiding finger-pointing or naming names). SO/SE has their own Help Center including "How to ask a good question" and "How to write a good answer".

It's not your job to compel your colleagues to perform to your expectations.
It's the manager's job to optimise the productivity of their staff.

---

Survival rule: Don't feel you have to take ownership of someone else's task(s). Be helpful when you can to the extent that you and your manager are comfortable with. You will encounter those who are willing to have you perform their work (esp. the difficult or tedious bits), take undeserved credit for reaching milestones, and single you out as the person responsible when the train leaves the tracks. ("B-b-but, CodePanda told me that's how it's done, or at least part of it!!") Be wary.

---

Maxim:

One can revise, rewrite and even reject bad code.
One cannot do any of those things with co-workers.

Paraphrasing the Dali Llama: "You go through this life to learn to be the best you can be. It's not your responsibility to try to transform those around you. Tend your own garden."

---

And, to conclude this sermon, the Serenity Prayer:

“God grant me the serenity to accept the things I can not change,
the courage to change the things I can
and the wisdom to know the difference.”
---Reinhold Niebur

Answer 6

I am faculty at a research university. A lot of your frustration reminds me of teaching during COVID, when most of my peer-to-peer interactions with students were through Slack and email.

It certainly does not sound like this "fully remote" company has figured out, or even tried to figure out, how to establish appropriate work culture among their remote team (all the more successful fully-remote companies I work with spend considerable time and money on team building, to periodically remind their staff that they are actually a team, not just a bunch of individuals in front of a nameless Slack screen). However, this isn't likely to be something that you as a contractor can fix. The only thing you can do is work with the environment you are given (or look for a different appointment).

The good news is that, at least in my experience, being more explicit about what you expect or hope for can already go a long way:

People will just PM me some random logs with a "?". No details added. I obviously don't want to waste 1 hour trying to figure out what they mean by analysing the logs. When I ask them follow-up questions, they stop replying.

Normally, when people stop replying, it means that their problem is solved. Ask them after a while if they still struggle with that. If they say no, or if they don't answer, consider the issue resolved.

People will just ask me question with 1-line statement with no background context added.

Ask for clarifications. If no clarifications are forthcoming, then see the previous answer.

I tried to answer with very little info. This person didn't clarify or thanked me. Later during meeting, he didn't point fingers but he complained that he is struggling with codebase.

Unless your job is explicitly to help this person with this codebase, this does not sound like a you-problem. Don't make other people's problems yours (unless they are, of course).

Junior developers will ask me questions. When I answer them, they never reply and tell me if it worked or not. Sometime, I waste lot of time finding solution and then there are like "oh, the first solution already worked, I don't need help anymore".

Take a page out of standard support staff cookbooks and always end your answers with a polite "please let me know if your issue is resolved or if you need additional help". If no response is forthcoming, see the first item.

If you ask someone something, sometime they don't reply and leave you on read forever.

Send a reminder. Send another reminder. After that, if it's a blocking issue, escalate to your manager.

(also, don't take it as a personal insult every time somebody "leaves you on read" - people are busy, and sometimes people forget ... it happens even in a well-functioning team)

Please or thank you or even hi are words no one ever uses.

Well, that certainly sucks, but as you say it's not really a blocking issue. Try to see it more as a cultural thing, indeed in some teams (even fairly functional ones) chat-based communication is very to-the-point. I completely understand if you find this impolite (I would do), but maybe it's something you can learn to live with.

Overall, one idea I would strongly suggest is to do more one-on-one face-to-face meetings (for example, via Zoom or Teams). For example, if people send you a strange log without too much additional info, rather than asking for clarifications you can offer to just jump into a Zoom call with them, look at the issue together, and discuss follow-up questions directly. My experience is that working online, synchronously on an issue is often not only more effective than purely asynchronous communication, it also leads to future asynchronous communications becoming much more targeted.