Supportive Leadership / Toxic Boss

The Zoom meeting started the way the best ones do: cameras on, banter flowing, human connection happening before the business connection. The vibe was collaborative and light.

Then, the senior leader joined the call.

The shift in atmosphere wasn't gradual; it was visceral. Faces on the screen went stone cold. Laughter stopped mid-sentence. The psychological safety didn't just leave the virtual room; it was sucked out of the airlock.

There was no "hello." There was just an immediate, aggressive demand: "Where is the work I wanted to see?"

What followed over the next thirty minutes was a masterclass in dismantling a high-performing team through intimidation.

The Trade of Reality for Optics

A legitimate flag was raised early on. The scope of work being demanded was massive—far beyond initial estimates. A professional suggestion was made to create a new tracking board to manage the effort sustainably and ensure the team wasn't set up for failure.

The response was immediate dismissal. "I already promised the VPs we are doing it. They are expecting it."

In that moment, operational reality ceased to matter. Team capacity didn't matter. The only thing that mattered was the optical promise made up the chain. When leaders refuse to hear reality because they fear disappointing their own bosses, they guarantee burnout and poor quality.

Public Humiliation as a Tactic

The hardest part to watch was a very senior, incredibly hardworking engineer getting berated publicly over a weeks-old task.

This proud professional was spoken to like a delinquent middle schooler. The silence that followed the dressing-down lasted nearly a full minute while they tried to compose themselves. It was excruciating. And it sent a clear message to everyone else on the call: If this can happen to the best of us, it can happen to you. Stay quiet. Keep your head down.

The Power Play

When data was presented that disproved the leader's assumptions, it wasn't accepted as progress; it was treated as resistance. The goal shifted from understanding status to demanding submission.

The same question was asked repeatedly: "You will do it, no? I want to hear you say you will do it." It was a pure power play designed to break spirit. When frustration was finally shown in return, it was laughed off with a gaslighting comment: "Ha ha, I just like to repeat myself."

The Aftermath

When the meeting ended, the work didn't start. Instead, an entire team of expensive talent spent the next hour regulating their nervous systems, debriefing to validate their sanity, and recovering from the adrenaline spike.

---

Reflecting and Panic Attacks

I witnessed this specific dynamic last month, which triggered panic attacks in me. It serves as a permanent reminder of a crucial leadership truth:

You cannot scream respect into people. If you have to bully grown adults to get work done, you have already lost. You may get short-term compliance born of fear, but you are actively destroying the trust required for long-term success.

#Leadership #PsychologicalSafety #RemoteWork #Management #WorkCulture

Why you should not delete Tickets

I am old school. Back in the day, logging a ticket was not everybody’s job. Prioritizing and removing tickets from the queue was also handled by a coveted few. Limitations on data (storage) also contributed to further bottle neck ticket creation, prioritization and maintenance. Every ticket was precious.

 

Then came agile and coincidentally data (storage data) also became bigger and cheaper. Everyone was allowed to log a ticket for ideas, issues, needs and wants. No topic was taboo (as long as it was within the scope of a project of course)

 

Tickets gave an opportunity for every team member to use their voice. And this WAS very important in Agile, people over processes. I say WAS because since last 4 years I have seen a trend of deleting tickets for the silliest of reasons in the name of Agile and keeping the backlog lean!! Not just at one company or team but in multiple teams. I also happen to observe that the people who do this are new to IT.

 

Some of the justifications I heard were – 

1.     Duplicate (but they do not even take time to compare the alleged duplicate tickets side by side)
2.     Not Relevant anymore (even when there is history in the ticket)
3.     Not a real issue (even when there is history in the ticket)
4.     Not Reproducible Issue
5.     We can’t fix this Issue
6.     Requirement from the previous team member
7.     It is an old issue
8.     Placeholder tickets

 

What could you do instead of deleting a ticket?

1.     Duplicate 

a.     Compare the tickets side by side. Make sure they are duplicates

b.     Link tickets as duplicate

c.     Pick the ticket with the most detail to work on 

d.     The other ticket – Close it and assign it back to the Owner mentioning the duplicate ticket with the link to the duplicate ticket.

e.     This gives the owner of the ticket information that the issue is being taken care of. And they may learn from the chosen ticket as to what the Product Owner looks for as far as details go.

2.     Not Relevant anymore 

a.     Make sure it is absolutely not relevant.

b.     Comment about why it is not relevant

                                               i.     The direction of the product changed, and the old ideas are no longer relevant

                                             ii.     The idea is good, but it is not product or project related

c.     Assign it back to the Owner, and give them learn about the outcome

d.     Close or keep the ticket open. But assign another status Not relevant anymore

3.     Not a real issue

a.     Comment about why 

                                               i.     It is not an issue but a feature 

                                             ii.     Link a test case or a story

b.     Assign it back to the Owner

c.     Close it 

d.     Assign status Rejected / Working as intended

4.     Not Reproducible

a.     Comment that is it not reproducible

b.     Talk to the developers if the information in the ticket suffices, if not what other information is needed might help to resolve the sporadic issue.

c.     Assign it back to the Owner

d.     Assign status Not Reproducible

5.     We can’t fix this Issue

a.     Comment that this is legit issue, but it cannot be resolved

b.     Comment about why it cannot be resolved

                                               i.     Too minor to address and it could break other things.

                                             ii.     Business decided, since no one complained about this issue and it is minor, we will let it go.

                                            iii.     It is an edge case and won’t happen again

c.     Assign it back to the Owner

d.     Close the ticket

e.     Assign status Won’t Fix

6.     An old issue

a.     If it is still reproducible

                                               i.     Comment confirming the issue and move on

b.     Do not close it

c.     Do not remove it from the backlog

7.     Requirement from the previous team member

a.     If you do not understand it well, but if it has some or ample information

b.     Leave it in the backlog

c.     OR if there are too many issues like this

d.     Create a dummy project 

e.     Move all the tickets into the dummy project

8.     Placeholder tickets

a.     No information is available, it has been over a week or more since they were logged

b.     It is nice to respect peoples time to log ticket and update it, but a week is enough. 

c.     DELETE These without any guilt!!

d.     Plus make it part of your team agreement to delete lazy tickets.

 

What can a ticket teach you?

 If we look closely, every ticket is a learning opportunity about the team, the person, the thought process.

 

Incident 1

Once on a project there were high number of duplicates. After filtering tickets with duplicates, it came to attention that one team member created a majority of duplicates. Upon closer inspection at created by and crated when, it was very apparent that the new team member was logging similar tickets within 20 to 60 mins after an original Bug was logged. If the tickets from the new team member were of superior quality, that would have been an improvement, they were not, they were straight up copy pastes in some tickets. So, basically the new team member was faking work. 

If we were delete, delete, deleting duplicates we would have missed out on a fun revelation.

 

Incident 2 

I was given a project that had a bunch of already completed and to be worked on tickets (in hundreds). The same project also has at least a 100 of the current product’s tickets that were very relevant to me and my team. It was a pain in the neck to separate the shutdown products tickets from the new ones. I knew it would be a bigger issue once time for release came and assigning Fix version. 

I was also OCD for keeping only the tickets for my product in the project and showing correct numbers. But I am old school, so I created a new project and moved all the old tickets to the new project retaining all the information and artifacts the tickets had. About 8 months down the Business Analysist who wrote a majority of the tickets wanted some information from his old tickets and looked in the project (he still had access to the project). He did not find his tickets and assumed they were deleted. He was sad and frustrated. 

He expressed his frustration, I immediately understood who he was and gave him access to the other project where I moved the tickets to. Within hours he and his manager wrote a nice email mentioning that they would not have blamed me if I deleted the tickets, but they thank me for respecting their work and keeping it safe. 

They were able to take some of their ideas and documentation which saved them 2 sprints worth of work, which is nothing to sneeze about. 

 

Incident 3

QA logs bug. The bug is deleted. Then other team members accuse the QA of missing a bug / slacking at work. This is one main reason many QA members hate the practice of deleting any ticket. They lose traceability to their work. This did not happen to me fortunately. But it did happen to a whole team of testers in India, when their tickets were deleted. They had to retest everything all over again. No, the project did not get delayed, these days the team is expected to work overtime. 

Backing up before deleting a ticket is slightly better, but it does not give visibility to all.

Irrelevant tickets can also be separated by resolution status or a fix version and many more options. Look into options and talk to your peers.

 

Tickets take minutes, hours and even days to get it to perfection. Deleting this ticket without offering the owner an answer, traceability and especially an opportunity to learn, is saying YOU (human) are not important. It is demoralizing and creates an environment that cannot be trusted.

 

Bystander Effect

Have you ever seen a bug in an application but no one on the team seems to log the bug. You too fall in a dilemma - to log or not to log the bug.

When I asked around, about why someone would ignore to log a bug that is starring in their face,

The answers I got in the order of frequency -

1. I don't think this is our team's issue.
2. I don't think it is an important issue.
3. I think it is a one time issue.
4. Logging this bug will delay the sign off on this build.
5. I am sure some one else logged it.
6. This is a known issue we don't need to log it.
7. This is how it seems to function all the time.
8. I don't think this is a bug.
9. I don't think they can fix this issue.
10. Why should I log it when everyone else ignored it?

The reason for this kind of attitude seems to be same as the Bystander effect where individuals do not offer any means of help to a victim when other people are present. 

Now, what could be a reason for this kind of reaction?

1. Diffusion of responsibility!!
2. Looking to others for guidance in Ambiguous situations.

How could this issue be rectified?

I do not know how this issue is addressed in most IT teams, but this is how I tried to solve the issue. -

1. Don't ignore it, just because you don't understand it at the moment.
2. Don't be afraid to log the Bug. It does not matter who is responsible for testing it. It is our collective responsibility to make sure the product is bug free.
3. Bring it to your team members attention to verify your findings.
4. Bring it to your lead's attention if you are not able to get help.
5. Don't be afraid to speak out again and again. It is okay to ask questions all the time. You will only get answers and more information and exposure.
6. If you are afraid of embarrassment, assign it to me instead of the Dev lead. I will re-verify and go from there.
7. Look for the people who could know the answers to the issue, contact them appropriately.
8. Don't avoid exploring the product with various variables out of fear of being called unnecessary.
9. It is okay to make mistakes. Mistaking does not make you any less intelligent.
10. Pick a designated lead who would re-verify the issue before assigning it back to the Dev lead. If you are the team lead, assign it to yourself and ask questions before assigning it to the Dev lead.