Coworker posted private chat message in a public group

Question

Background:

I have been working with a coworker on a project these past few weeks. I was responsible for the upstream portion for data engineering (made-up timeline).

At week 3, the coworker raised issue (A) via a private message on slack, insisting that the process did not work as planned. I spent a couple of hours that day to investigate the issue and demonstrate to the coworker that the process did work as planned. Issue (A) was resolved via private messages.

At week 4, I was in the process of testing and implementing the pipeline to production after preliminary tests. I posted the results to the team Jira ticket. Everything seemed OK, outside of one outlier that I had difficulty pinpointing.

The same coworker stated that the outlier would be an issue (B) and the two of us had a conversation about the need to address now or later in the Jira ticket. My assessment was that the cost to figure out the bug was not worth the effort at this time and would be addressed later once the end-product was sourced to a new table. Given the time-cost of the current process (an analyst manually running scripts) I proceeded to push to production knowing the outlier was a factor.

Issue (B), despite not impacting the test environment, did impact the production environment and I had to troubleshoot in a live environment. (In hindsight, the test environment was not a 1:1 with production.) I reached out in a public chat and apologized for any disruptions I may have caused with the deployment after identifying and resolving the issue.

The coworker then decided to take one screenshot from week 3 for issue (A) and posted it in the public chat. Someone reading the post would get the impression that both problems (A and B) were raised in week 3 and I ignored them all. I went against my first urge to post the entire conversation in the chat to one-up the coworker, but now I am at a loss as to what to do next.

---

Another simple way to describe this situation:

My coworker raised a potential issue B, but I decided to postpone a fix. Issue B appeared in production and I fixed it and apologized for the disruptions caused by it. Now my coworker posted an earlier private chat where he had raised an unrelated issue A as if it were related to issue B, giving the false impression that I had ignored the problem.

---

Questions:

Question 1: What can I do, other than raising this problem (citing private conversations out of context), with my manager?

Question 2: Should I try to resolve this issue 1:1 with this coworker?

Question 3: Is it common practice to cite private messages and I have no reason to be upset?

Answer 1

I know it's hard, but my suggestion would be to do nothing.

There's a saying: "Never interrupt your enemy when he is making a mistake". What your co-worker did was childish and unprofessional. Rest assured that your other co-workers know that.

• If you stay silent, people will remember this event as "Bluebird made a mistake, and co-worker publicly shamed him for it by posting a screenshot of a private conversation. Boy, what a jerk!"

• If you take the bait and start to argue, people will remember this as "Bluebird and co-worker had a fight over who-said-what in our public slack channel. Such idiots. Can't they do that in private?"

It's easy to see which choice leaves a better impression of you.

I am aware that your co-worker made the additional mistake of posting about issue Y instead of issue X. That doesn't change how you should react. For non-observant readers, it won't make a difference. For observant readers who notice this, it will reflect badly on him (because he publicly complained about some unrelated issue) and well on you (because you took the high road of not correcting him in public).

Answer 2

Q3: Is it common practice to cite private messages and I have no reason to be upset?

It was not private; it was a work conversation. You shouldn't have had any reasonable expectation of privacy. Never write anything in email or messenger apps that you would not be prepared to see shared more widely.

That said, your colleague's behaviour isn't hugely professional so you could take some small issue with that.

Q2: Should I try to resolve this issue 1:1 with this coworker?

Yes, but only if you can approach the discussion with an open mind and be prepared to conclude that you were in the wrong. Talk to them to see whether they believe they'd agreed to defer this known issue, or whether you unilaterally dismissed their concerns.

In the former case, they shouldn't have shared the messages and you could ask them to apologise in the same team chat. In the latter case, you owe your colleague a (private) apology and should agree a better way to resolve disagreements in future.

Q1: What can I do, other than raising this problem (citing private conversations out of context), with my manager?

I wouldn't start by talking to your manager. Your colleague's behaviour could be viewed as immature; you running straight to the boss to complain would probably seem similar. Once you've spoken to your colleague, it would be professional to update your manager. Concentrate here on what went wrong and what the pair of you will do differently in future.

Answer 3

TLDR: you made a wrong decision, told the decision in a 1:1 chat to your coworker. Now it comes back to bite you and your coworker goes "told you so".

Own it. Yes, pointing fingers at you is not nice, but what point do you want to make? Stand to your decision publicly, explain your reasons why you did what you did, and own the mistake.

For the future: Coworkers won't cover you, why should they? There is no real privacy in a work environment, all your communications can be accessed and read by management, even if this doesn't happen normally. If I was your coworker, I would have handled it in a more polite way, given you a heads up beforehand and disclosed the problem with a little less finger-pointing. But we all are human, maybe your colleague fears he is getting blamed for the mistake.

Everyone misjudges sometimes, and everyone is always smarter after the fact. Stand proud and don't try to hide stuff you did wrong.

Answer 4

coworker raised issue (A) via a private message on slack

Issue (A) was resolved via private messages.

This is the root problem.

Your coworker mistakenly used the chat feature to track an issue, but you followed along. Once you were down that road, there was no other way to reference this issue except citing your conversation. And there was no way to link code/pull requests/commits/successful test runs to the code changes that this issue A entailed.

My suggestion: Learn from this and move forward. Explaining this convoluted story won't shift anyone's opinion. Noone is going to follow everything, and if they do, it's too complicated to change anyone's mind.

In the future, track issues with your issue tracking system Jira.

Answer 5

Just as a forewarning, I will stray quite a bit from the workplace side of this question into the technical aspects of what went wrong here. As a software tester, I have found myself in similar situations in the past.

Both you and your coworker are at fault here, and potentially your company culture as well. This conflict would have been impossible with a proper workflow, but there were three key workflow issues that allowed it to happen.

Issue #1: Your coworker reported a bug in a private channel. This is a huge issue for recordkeeping and traceability. Any bugs should always be recorded directly into the issue tracker by the person who found the problem (with the potential exception of externally-reported bugs). If bugs are always reported in the tracker, there can be no real question of what was reported and when, because these become part of the (company-internal) public record.

Issue #2: As the developer who introduced a potential bug, you made an executive decision not to fix it. This is another huge problem. Humans in general are not good at objectively reviewing things that they have a stake in. A product manager or risk assessment group should have been asked for an opinion before deciding that the issue did not need to be fixed before go-live. These people will be better able to make an objective assessment of risks than someone closer to the project. If you had not made the call to decline a fix, you wouldn't be in this situation.

Issue #3: You are using a continuous delivery pipeline, but your test environment doesn't match the production environment. This will inevitably result in uncaught issues appearing in production. In order to continue using a CD pipeline, fixing this should be the top priority. If your pipeline were working correctly, you would likely not have run into issues in production that weren't found in test.

If any of these issues had not occurred, you would not be in this situation. I have noticed that many developers and testers don't understand the importance of these processes and find them tedious (particularly regarding #1 and #2 above), but they solve important and common problems in development pipelines.

Answer 6

I would suggest two separate messages, both professional in tone. Try to take the perspective of "the health of the system" rather than take it personally.

1. A response in the public chat which states that the conversation related to another issue, which was fixed during development, and did not impact production. Link the issue. The mixup is not unreasonable, nor is it unreasonable to think issue A indicated quality process problems, now manifested in issue B. "Hi, that issue was fixed in development, as tracked in (link), and was never in a production environment. I understand it was worth double-checking given the incident."
2. A quick talk with the colleague saying you felt a bit blindsided by posting one-to-one messages in the public chat, without further context, when it was previously concluded with an extensive discussion. Preferably face to face, but at least away from the low context environment of text chat (phone, video, etc). Acknowledge they were right on issue B. Also ask if there were specific reasons they felt it needed to be urgently and publicly posted without that context. Ask if there are better ways to test for that class of issues the future.

Do note that one-to-one chat at work, about work issues, is not the same as purely personal chat outside work, or more political chat at work. So don't expect the same privacy etiquette to apply.

Answer 7

Q1: What can I do, other than raising this problem (citing private conversations out of context), with my manager?

I think your best option here would be to do nothing. Your coworker is/was pissed that you didn't listen to them or heed their warnings, you got egg on your face and the coworker (rightly or wrongly—it can be debated) served you a big fat slice of humble pie.

Q2: Should I try to resolve this issue 1:1 with this coworker?

The only conversation you should be having with your coworker starts with "I'm sorry I didn't address your concerns when you raised them to me"—regardless of your justification or reasoning at the time.

Q3: Is it common practice to cite private messages and I have no reason to be upset?

Yes and no.

It's generally considered poor form to do so, but as above - on a work platform, the basic expectation should be that you have no privacy and that all conversations are company property.

There has been occasions where it has been necessary to post snippets of private conversations in a public chat.

This instance is borderline—but if I take the other employee's side for a moment—he gave you fair warning and was dismissed and then you come into the public chat saying 'Oh, I'm sorry I caused an issue'—and he's sitting there thinking 'There wouldn't have been an issue if you'd just listened to me' and so he posted the screenshot.

Was there an element of 'told you so' from his side? Absolutely! Did he want a little vicarious vindication for being right? Damn straight! Was it a little rude of him to do so? I would say 'a little bit'.

I think the better lesson from this experience is to not be so quick to dismiss your Co-Workers. Perhaps they know something you don't.

Also test is never production.

Answer 8

The other answers are all correct: You took a calculated risk, that the issue your coworker pointed out to you would be an issue, but not a big issue, in production. You lost that bet. Now it's time for you to own it.

What you failed to do and should have done is to have given your coworker credit at the time and inform stakeholders. Saying to your PM "hey look, we identified issue X, it's probably going to be a prod issue, but it's going to be really hard to fix and delay deployment significantly, so let's accept it will be an issue for release and we'll look into fixing it shortly after go-live" is a much better option than your PM coming to you after the fact about a production-breaking issue and yelling at you about why it's broken, and then compounded by the fact that there is evidence that you knew about the issue well in advance and told nobody.

Your decisions are not your coworker's problem, they're your problem. Own it and deal with it. Issues like this come up fairly often; there's no problem with introducing known issues, but there is an issue when those issues are known and not communicated so that appropriate people can make appropriate decisions. For example, had you raised this issue with your PM at the time, your PM may have said "oh, that really sucks, we should fix that before going live, how long do you need to push back the deadline to make this work?" and then you could have negotiated extra time that way.

Bottom line: Communicate, communicate, communicate. There's no wrong time to communicate.

Answer 9

I'm going to focus on one part of your post only:

(In hindsight, the test environment was not a 1:1 with prod).

This causes so many problems!

It's really important to stress to management that the non-prod environment(s) need to match prod as closely as possible.

if this is not the case, bugs will be plentiful!

I realize certain data needs to be obfuscated in non-prod, and that can be expensive and time-consuming, but if the test-environment isn't the same as prod, the tests become far less valuable, and bugs will ensue in prod.

PS: Please forgive your colleague.

Answer 10

On one hand, you could have made the most logical assumption that your coworker was attempting to help explain the situation but made a mistake; and posted a follow-up comment to your coworker's comment, correcting any misapprehension that anyone might have that issues X and Y are related.

On the other, you could have assumed that your coworker's comment was a deliberate attempt to undermine you, and as a result apparently had a meltdown that caused you to post this question.

You chose option two, and it isn't a good look for you. It makes you seem self-centred, immature, and unable to work in a team. I strongly suggest that you take this as a learning experience, and assume that the other members of your team are trying to help, not sabotage, you in future.