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.


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?

  • 14
    I have a question... When you apologized to everyone about disrupting their work... Did you let them know that you had been told that your code was buggy AF by coworker X but proceeded to push it anyway because you "knew better?" Or did you say something that made it sound like you hadn't been told that your code was going to break things?
    – Questor
    Mar 22, 2023 at 16:27
  • 2
    Correct! Week 3 issue: resolved same-day. Week 4 issue: was raised by cowoker, I noted it in the JIRA ticket and made my reason why it shouldn't be addressed at that point in time (I couldn't pinpoint the source). My beef was my coworker screenshotting the message from Week 3 and posting in a public chat making it seem that I was ignoring all of my coworker's issues since Week 3!
    – Bluebird
    Mar 22, 2023 at 23:46
  • 3
    Before the edit I understood as Questor that coworker raised issue and you ignored it and it blew up. Now with edits it's a bit clearer it's not the case, but I guess this could be boiled down to "issue X appeared in production, coworker posted a private chat where he warned about issue Y as if it were related to the problem X", right?
    – LoremIpsum
    Mar 23, 2023 at 1:43
  • 1
    It the main point is about 2 issue X and Y separately, then you should perhaps talk to that coworker privately to explain the technical differences between the 2 issues to him so that he won't be confused about the 2 issues. Mar 23, 2023 at 4:28
  • 2
    This question could be shortened a lot by removing all of the extraneous detail. The salient parts are (a) you chatted "privately" 1:1 with a coworker A about problem X, (b) you contributed to a JIRA ticket about related problem Y, (c) coworker A posted a screenshot of your "private" chat where the rest of the team could see it.
    – shoover
    Mar 23, 2023 at 16:41

10 Answers 10


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).

  • 14
    This. People seem to be conflating one-on-one channels' privacy and company ownership. Yes, your company has access to all your emails and chats. It's a whole nother story if a coworker decides to put a private message (called "direct message" on various platforms for this exact reason) into a public channel, which is indeed childish ("told you so!") and unprofessional ("look, I told them so!").
    – CodeCaster
    Mar 23, 2023 at 9:09
  • @CodeCaster - most common DM app in software dev is Slack, and by default, no, your company does not have access to private messages. And in EU, pretty much no companies want to get it due to potential legal issues.
    – Davor
    Mar 23, 2023 at 12:35
  • @Davor it is definitely possible "Under limited circumstances, workspace owners may contact Slack and apply to export data from all channels and conversations, including private channels and direct messages. We will reject applications unless workspace owners show in each instance (a) valid legal process or (b) consent of members or (c) a requirement or right under applicable laws in order to export data." Limited, but possible, and in government perhaps even required.
    – CodeCaster
    Mar 23, 2023 at 12:58
  • 4
    @Davor my point was that you should never consider any work-related communications channel to be private, and that point remains valid. It is "private" in the sense as "I discussed this face to face with a coworker at the water cooler", but remember that the water cooler has a recording device built in.
    – CodeCaster
    Mar 23, 2023 at 12:59
  • 1
    This is the only sensible answer. In this context private doesn't mean secret, it means that there is a cultural expectation that DMs are not shared beyond the people involved. It is private and you have a reasonable expectation that what happens in DMs stays in DMs outside of exceptional circumstances. It's also true that the problem is self solving. Most people will look at someone sharing private messages and think poorly of the person doing it.
    – Tom
    Mar 23, 2023 at 22:29

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.

  • I updated the original question to include facts regarding posting discussions in a public setting. Would your answer be affected by the new details?
    – Bluebird
    Mar 22, 2023 at 23:31
  • According to the OP latest updates on the post and in the comment section, the situation is like this "issue X appeared in production and the OP fixed the issue X, but the coworker posted a private chat where he warned about issue Y as if it were related to the problem X", Mar 23, 2023 at 4:45
  • 20
    Not sure I agree with that first point. Sure, it's not "private" in that you should expect management could always get a hold of the messages should they want to but at the same time, you shouldn't expect that colleagues would go posting them everywhere. Mar 23, 2023 at 9:53
  • 6
    Private has several meanings, and two distinct ones come into play here. The conversation wasn’t private in as in “not connected with your work or official position” (sense #7), but it was a private conversation “involving a particular person or group of people” (sense 2), in that only the participants had access to the transcript – it was had in private. The asker takes issue that the contents were made public out of context, not that they were made public at all. Mar 23, 2023 at 16:56
  • 1
    I think the word private is a red herring. (in my opinion) it's not offensive that the images were posted because they're in a private chat. It's offensive because they're posted without context, in an effort to embarrass/undermine the OP. I think it would be equally offensive if the conversation had occurred in a public channel, or on the issue tracking system. Mar 24, 2023 at 12:15

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.

  • There was a seperate JIRA ticket where I did publicly disclose my reasoning and the coworker's concern. Once the issue hit production, I took ownership and addressed the issue in full. I had no problem with taking responsibility, but rather whether screenshotting private (even in a work environment) communication was for a lack of a better word - appropriate in a team setting. Based on your answer, it would appear that I was "hiding" my mistakes. But that was an oversight in retelling the story on my part. May you please revise your answer if my updates makes a difference?
    – Bluebird
    Mar 22, 2023 at 23:30
  • 8
    @Nelson, if it wasn't clear, I've already "owned up the mistake" by addressing the issue and making a public apology. My grievance is my coworker posting a message from Week 3 from a completely unrelated matter in Week 4, implying that I've ignored all of their concerns.
    – Bluebird
    Mar 23, 2023 at 4:21
  • 4
    According to the OP latest updates on the post and in the comment section, the situation is like this "issue X appeared in production and the OP fixed the issue X, but the coworker posted a private chat where he warned about issue Y as if it were related to the problem X", Mar 23, 2023 at 4:45
  • 22
    Are you forgetting to mention that publicly dunking on a coworker with "I told you so" and posting a screenshot of a private chat is a far greater professional mistake?
    – Davor
    Mar 23, 2023 at 12:28
  • 4
    @jwsc - this isn't about rights, it's about social and professional norms. If I have a 5 minute chat with a colleague, and then go to a public Slack channel and post "eww Steven stinks, man needs a shower", I should get fired, even if what I said is 100% true. In the same way, if I was managing the dude who posted that screenshot, I'd invite him to a private conversation where he would be told that next time he does that he won't be working under me at least.
    – Davor
    Mar 23, 2023 at 13:20

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.


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.

  • I appreciate the technical approach and comments here. Regarding #1: I can fully agree. Before I came to the team there wasn't any project or bug tracking software. Even though I tried to introduce Jira, adoption was lukewarm at best, especially since the old manager (who approved the process change) left and most IC stopped utilizing it extensively. I think its a situation where I can lead folks to that mindset, but its above my paygrade to enforce usage.
    – Bluebird
    Mar 24, 2023 at 3:08
  • #2 The extraneous detail that I didn't include was that I planned to bring the issue to a group-level conversation, but that meeting was postponed a day. but instead of waiting, I proceeded with the deadlines. So what happened was W3D3 Bug A was reported and addressed. W4D1, bug B was reported via Slack, I posted my responses in Jira, with the caveat that we discuss in detail on W4D3 morning and deployment in the afternoon. But the meeting on W4D3 morning was postponed to W4D4. I pushed to production and things started to fail.
    – Bluebird
    Mar 24, 2023 at 3:10
  • 1
    #3 The problem was that this was a on-prem (SQL Server) rebuild into cloud (Google Big Query). There was no way for a lack of a better word, to replicate the pipeline in a test environment. There was the also added caveat that the data was piped from the cloud back to on-prem to power existing products downstream.
    – Bluebird
    Mar 24, 2023 at 3:12
  • 1
    @Bluebird You mean test is running SQL Server and prod is on Big Query? Those don't even speak the same dialect of SQL. You might as well not have a test environment at that point. Mar 24, 2023 at 14:49
  • Welp here is the stack: Legacy Version: Emailed Spreadsheet Data -PowerShell-> SQL Server --> Tableau/Excel Reports. Cloud Version: Email Spreadsheet Data -Power Automate-> Share Point -Internal Tool-> Google Cloud Storage -Python Script-> Google Big Query -Internal Tool-> SQL Server --> Tableau/Excel Reports. -X-> Means the tool performing the action. Not ideal, but there wasn't another approved enterprise-grade tool allowed to be used afaik. The new bug was found from GBQ to SQL Server.
    – Bluebird
    Mar 25, 2023 at 16:28

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.

  • 3
    Yes - if you feel it's absolutely necessary to post something publicly, be super polite and helpful and just correct the facts. "Hi (colleague), thanks for raising this. Actually the issue you mention was fixed two weeks ago as we discussed previously; the one seen in production is a separate problem. If you have any further questions please feel free to drop by for a chat!"
    – psmears
    Mar 24, 2023 at 10:50

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.

  • 5
    I now truly appreciate "Also Test is never Prod."
    – Bluebird
    Mar 22, 2023 at 23:37
  • 1
    According to the OP latest updates on the post and in the comment section, the situation is like this "issue X appeared in production and the OP fixed the issue X, but the coworker posted a private chat where he warned about issue Y as if it were related to the problem X", Mar 23, 2023 at 4:44

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.

  • 2nd paragraph is the meat here. OP knew about predicted production issues and told nobody. This literally forced the co-worker to blast him. If you deploy production code with known issues, then let people know before deployment. All that stuff in the JIRA tickets should've all been open and made known to everyone (management, client, co-workers, support staff, etc.) OP was betting on nobody noticing, and he even lost that bet, bad.
    – Nelson
    Mar 23, 2023 at 2:01
  • @Nelson, According to the OP latest updates on the post and in the comment section, the situation is like this "issue X appeared in production and the OP fixed the issue X, but the coworker posted a private chat where he warned about issue Y as if it were related to the problem X", Mar 23, 2023 at 4:44
  • 2
    The response above is missing the point; the first issue was X, this was admitted as a mistake. Issue Y was unrelated. I repeat unrelated to the first issue X which was in the spotlight. Meaning a false impression was deliberately made by posting issue Y, creating a link in everyone's mind between issue X and Y when there was none. A slur on the Op's character which was undeserved. Mar 23, 2023 at 14:44
  • Though the original post could easily lead you to believe that there was only a single issue..
    – Questor
    Mar 23, 2023 at 17:45
  • I'm going to leave my answer as-is. It's not applicable to the revised question but I'm simply too lazy to make the enormous amounts of edits required to update it.
    – Ertai87
    Mar 25, 2023 at 5:05

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.

  • 3
    I appreciate the advice but what made you decide to add the "PS: Please forgive your colleague."?
    – Bluebird
    Mar 24, 2023 at 3:12
  • 1
    It's best to forgive. Probably, you both need to forgive each other. Mar 24, 2023 at 12:05

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.

  • 1
    I don't think it's fair to say the OP "had a meltdown". Yes, they did consider replying to that post to one-up the colleague, but then they decided not to do it. And coming here to ask a question can't be a negative thing, and I can't see how that would be the result of a "meltdown". On the contrary, it tells me that the OP knows how to keep their cool even under stress. Mar 25, 2023 at 2:18
  • You don't correct a "misapprehension" by posting a screen shot of a bilateral chat. You simply say "this issue X is not related to issue Y which we discussed and fixed".
    – LoremIpsum
    Mar 25, 2023 at 10:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .