#WorkplaceEtiquette #Communication #ProfessionalDevelopment
Hey everyone! 👋 Have you ever had a coworker who calls out bugs on public channels and is quite aggressive about it? 🐞🔥 I recently had an experience where a coworker tagged me multiple times in Slack, criticizing my work and even calling me a bad engineer publicly. 😳
Here’s the thing – the tickets she wrote had poor descriptions, and many requirements were missing. When I asked for clarification, she expected me to read her mind and include features that were never listed. 🤯
So, here’s my dilemma: should I push back against this behavior? If so, how can I do it in a professional and constructive way? 🤔
Possible solutions I’m considering:
– Clearly communicate the importance of detailed ticket descriptions for effective collaboration. 📝
– Request a meeting with the coworker to discuss expectations and improve communication. 🗣️
– Document instances of unclear requirements and their impact on project timelines. 📅
– Seek advice from a mentor or supervisor on how to handle the situation professionally. 🌟
What do you think? Any tips or similar experiences to share? Let’s navigate this together! 💬 #Teamwork #Professionalism
Go through her list of tickets. Make a list of the issues you have with them. Be very specific and diligent in documenting the issues you have with her tickets. Then take your issues to your manager, discuss it with them, and get their honest input. If they agree with you, let them handle it with the other employee (that’s not your job).
The key here is you want to be specific and diligent in documenting the issues you have with her tickets. You need to convey to your manager that you are receiving complaints that you don’t agree with but MOST IMPORTANTLY that you take these complaints seriously, so if the problem is in fact with you, you absolutely want to fix it, but you aren’t seeing where you have done something wrong.
That’s how I would handle it.
It might be tempting to push back and get the focus on the other party’s faults, but does that really help you? In general, it’s better to keep these things between the two of you (or involve your manager, but don’t do these things in public).
Push back at an earlier stage, if you can. As soon as you don’t you also bear responsibility for the vagueness of the ticket.
It sounds like there’s no standard that tickets need to meet before they are worked? My team has a “definition of ready” that tickets need to meet which usually involves that the description meets some standard and has some gherkin statements that describe the desired functionality in some structured terms.
If I were you I’d just start kicking back tickets that are too vague or sound like they’re going to result in an argument.
You don’t have to accept a ticket just because some loser assigned it to you.
Talk it out with the group as a whole
This happened to my senior who kept attacking my other senior and tagging @ someone whenever she finds a bug. Everyone else on the team fixes the bug and lightly mentions it when they spot one. But only her would tag someone, not fix it, and be aggressive about it. One time she brought it up to my manager about my ticket and i know she was wrong so i took the opportunity to tell my manager that she never checks my work functionally and just makes an assumption that im wrong. I proved to my manager she didnt know what she was talking about and my managers opinion of her went down. I also made sure the manager knows this was not the first time and that helped a lot! Document document document!
>However, when I dug into her criticism, what I had come to find out is she didn’t list any of the requirements she complained about on the tickets she wrote. In fact, many had no descriptions at all and maybe just a link to a figma doc. The best I’d ever get is a screenshot and *maybe* 2 sentences.
This should be a conversation you have with your manager during a 1:1. They should be able to rectify the lack of quality going into ticket creation.
>Each sprint I am kinda overloaded with tickets, around 20 per one week sprint.
If you are overloaded with work each week then you should push back and set proper expectations. Don’t assume everything goes perfectly when setting expectations either as there is always something that wasn’t thought of in a sprint.
​
>The tickets I am given often have have little to no description, and asking around leads to mixed responses based on who I ask. For example, the designer might say one thing, while a backend dev might say something entirely different
These don’t sound like tickets that are ready to work on. There should be standards of expected information before a ticket can be added in to a sprint.
​
>Today I woke up to something like 20 mentions in slack, it was all a coworker who was calling out bugs and tagging me, finishing with a fairly aggressive message saying more or less that I am doing a bad job and I am a bad engineer. She went so far as to say “nothing works” in the app. She really dug into me, and it was all public. I felt it was unnecessarily rude to do it this way
The way you describe it, it does sound overboard. This is something you should be talking about with your boss.
​
>However, when I dug into her criticism, what I had come to find out is she didn’t list any of the requirements she complained about on the tickets she wrote. In fact, many had no descriptions at all and maybe just a link to a figma doc. The best I’d ever get is a screenshot and maybe 2 sentences.
These tickets were not ready to be worked on. There should be agreed upon acceptance criteria in tickets so everybody knows what to expected. You should have pushed back by saying there is not enough information here. Come up with scenarios that are not defined as examples of how it’s not ready to be implemented.
​
>For example, I had one requirement to make a form which allowed a user to set a specific setting. I did exactly that, made a field that allowed them to set that setting and persist it. She said it was broken, and I asked how, presuming that it wasn’t setting the field when she reloaded the page and was some sort of regression. I tried it myself and it worked, so maybe it had to do with a validation message not showing. I asked her about it, and she said that she wanted it to be initialized to some value when a user is made. The value she wanted it set to was actually a fairly complex thing. This wasn’t listed anywhere in the ticket.
It sounds like you made assumptions with the ticket which was a small mistake on your part. If I had that ticket one of the first things I would ask is what should the default value be. Then there would be questions about validation and ranges, depending on what the setting is.
​
>I lightly mentioned that, and she responded “yeah but the previous app did that so you should have known”.
These are small things that you should be asking to understand the problem before starting implementing. No doubt she he made incorrect assumptions but a follow up is probably warranted here before starting the work.
​
>To me, if it’s not written as a requirement, I don’t feel it’s appropriate to make the assumption that I should add an extra feature that’s not listed just by inference. I could be wasting precious time
Lack of an assumption is still an assumption at a basic level. Since they didn’t tell you what to default the value to you just assumed they didn’t want a default value, set it to something random, or left it undefined.
​
>I don’t really wanna spread negativity but I also feel this is generally hurting my perception in the company. What should I do?
You should ask follow up questions before starting work to make sure you understand the task at hand. Don’t assume if something like a default value is not specified does not mean it was not wanted. Communicated with people and verify that is the case.
On the flip side when creating tickets you should make sure to include as much information as reasonable possible. Things like default values, ranges, validation are all part of that.
I usually get there by thinking about the testing I would write and seeing how I would break the feature. If there are test cases I can come up with that don’t have a defined result then I start asking questions.
I would just go into all the bug tickets and ask for: expected behavior, observed behavior, detailed steps to reproduce, and acceptance criteria. Then assign the ticket to the reporter.