How to handle blame for issue not handled by seniors?

Question

I work as a junior software developer in a mediocore service cum product based company.

I was given an issue to fix urgently.
It took some time for me to analyse the problem; this was acceptable in the start phase, as the issue was very important.
Then I noticed some dependencies on other projects which were handled and modified by seniors.

After verifying things and final discussions with those seniors I fixed the issue, but in the final release it failed due to improper deployment and testing by the QA team.

I was questioned first in front of some of colleagues I looked into the problem and reported the mistake from the QA team. No one raised an objection and QA handled the problem silently.

After release, the client claimed that the fix was only half done and again the team leader questioned me. I replied that whatever issue we found and discussed at the time were covered.
I again looked into the issue, and was expected to resolve it quick as it was a big concern to the clients, but due to the old legacy system and slow tools it took some more time.

The team leader asked me if it would be resolved soon. I replied I would do my best and try to resolve it ASAP.

I again found some dependencies on other projects, for which I didn't have any idea how to fix. I told my senior colleague about it, but he told me to make it work.

I fixed the issue myself so that it should not occur again.

After all this work-around, with the final release, the team leader again told me I didn't do a proper deployment, but again this was also QA's error - I showed them what was wrong.

How can I handle things like this and behave in front of the entire team /seniors? Although I spoke very politely all the time, this kind of treatment is very dangerous for my future work/learnings.

Answer 1

Here would be my approach:

Try to work with the QA team. The way things are working is bad both for them and you. Can you discuss it with them and try to work together better? You want to come up with a solution before it has failed and you are blaming each other to management.

I would probably do this in terms of an offer to "help out" by participating in the QA of the change you made. Also, I would avoid blame in this discussion. Don't say "your QA was inadequate"; say "obviously this hasn't been working; how can we work together better to get this release out?"

Also be willing to listen if they think part of the issue is your fault.

If that doesn't work, raise concerns to management about the broken process. Highlight the fact that the way the changes are being released is hampering success.

Again, avoid blame and simply express your concern that things aren't working. It's not about you being right and the QA team being wrong; it's about the harm caused to the company by the process not working smoothly.

Answer 2

Unfortunately, it sounds like your workplace has a bit of a toxic culture... important tasks being placed on juniors with little support from seniors isn't too bad, but having management say things like "make it work." and always jumping straight to you when something goes wrong, just isn't on. Not with a junior.

My advice would be to start looking for another job. In the meantime, just stay calm when dealing with this sort of thing. Do your job as best you can, investigate the reasons for any failures and inform your manager of your findings.

Answer 3

I can tell you how this is done in a properly working team:

You are assigned a task. You find out how to do the task, then you do it. Depending on how difficult the task is, how advanced you are, whether you have a good day, and whether the solution might interfere with other people's tasks, you discuss things with them. You end up with code that you hope will work.

You give that code to someone who reviews it. The reviewer will either accept it, or tell you that changes are needed. You repeat until the reviewer accepts it. At that point if there are problems, it's not your fault (alone), any fault is shared between you and the reviewer.

A build of your code with the accepted changes is given to QA. They test it. If they find problems, you fix the problems and start all over. If they find problems, that is good, it proves that QA does their job properly. Eventually you end up with code that is reviewed and accepted by the reviewer, and tested and accepted by QA. If there are problems after that, the blame is shared between all three of you.

If this is not what is happening, you will always have problems. If your management doesn't change the process, that's their fault and they should take the blame. Apart from that, things go wrong sometimes. Shouting at people and demeaning them in front of others doesn't help one bit in that situation.

If things don't change, you may want to look for a better place.

Answer 4

It is obviously difficult for QA to properly perform their function on this "old, complicated, legacy system." The process is obviously in need of improvement, and the customer is directly involved, so there is "a lot of heat."

You indicate in your final paragraphs that the TL "asked you to show them what was wrong." So, obviously they know ... (of course they do!) ... that the process is broken, and they are specifically asking you for your insights and perspective.

No one, from the bottom to the very top, likes being in this sort of situation, especially "in front of the customer, who ultimately pays the bills that pay everyone else." But, it sounds to me like the team is working to identify the root causes of the problem and to work it out, albeit under conditions of intense pressure.

And so, I would simply suggest that you continue to remain focused on the [process ...] problem, given that "it presently sucks," and continue to do your part to make it, so to speak, "suck less." Indeed, "what is, in your professional opinion," the reason why QA isn't able to perform its intended role, and why deployments to production are going wrong?

Why did it "take longer than you expected? (Because, at the time, "everyone else" agreed with your expectation. Otherwise they would have corrected the project timeline. No one is "alone at fault," but the project was impacted. Again.)

Software development is a beast of a process, most especially with legacy systems. No one understands it fully. Even though you might feel "a bit crucified, now," no one's actually trying to stick you with it. They're trying to make the process better, and The Customer happy again. "Yes, it sucks to be there." But, we've all been there, no matter where we were on the hierarchy of the team or department in question. Focus on: "help us to 'fix it, forever.'" Keep your head up. Remain engaged.