I have been working for my current company for 7 months now and I am completing my two years in the industry in total. My company is a large enterprise, with relatively relaxed deadlines and flexible schedules.

We are a newly established team, most of us are juniors with experience ranging from new graduates, to two years experience at max. The only senior coworker, who is also the scrum master, won't bother to guide anyone and only minds his own business. Our manager is also an extremely hands off person.

Often when given work to produce, the new graduate coworkers retreat to their small "buddy teams", hoarding tasks, and work in a rush without planning, designing, consulting, or discussing anything with others. As a result, this dominates our development efforts due to their fast pace.

At this point, they produced very buggy code with no recognizable structure. The product is not scaling with even small loads. We now have a very mind-boggling local development setup, two different testing setups that are not working as intended, and they still keep telling us "we will fix it later".

At one point I tried to refactor one portion of the code since it was taking too long to build, and the manager was complaining about it. Even though coworkers knew about what I was doing, no one complained or opposed me at the beginning yet I came to hear that scrum master, who is the most senior coworker in our team, was mocking my attempts behind me to fix things as "waste of time", that "no one cared".

So I decided give up on refactoring altogether, it was not welcomed. At this time I managed to grab two new features to develop and completed them.

During our meetings with the manager, I expressed my concerns regarding all of this openly since day one. The manager often agrees with me, yet never offers a practical solution. He believes, with time it all will be alright.

He asked me why I was not providing the "fixes" or "improvements" to the problems I detect. He also asked me about the refactoring I was to do, since he was not approving the state the code was in, and I told him I was not able to follow through since I was all alone in doing that, that no one seems to care about quality besides me. I also mentioned the reaction I get from scrum master, that other colleague went for fixes and never informed me about it, so I focused on other duties.

So at this point, I feel like the manager thinks it is my responsibility to fix things since I am the one pointing out that problem. However, I find this approach unfair. I must say I don't think I am responsible for other's mistakes since they are not willing to learn from my "refactoring" and think it is "waste of time".

As you might realize, I am also fairly new in the workforce and have tons of soft and hard skills to learn. So here is my main dilemma:

What would happen if I avoid work related to this product and solely focus on other tasks from now on? Am I really responsible for this kind of work that is produced by coworkers via excluding me?

Edit: I should have made it clear that we are doing agile, scrum and kanban. As a result, there is no assignment of tasks, we volunteer for open tasks. Also, we all have the same manager whom I mentioned about in the post and have a horizontal hierarchy in our team, so there is no "boss", "team lead" or anything. We are expected to act collectively.

Edit 2: Shortened the post. Edit 3: Shortened the post further.

tl;dr: Coworkers are cowboy coding the product, not letting others contribute, the manager seems to expect me to provide the fix even though no one in the team seems to care besides me. Am I really responsible for fixing the work that I have barely contributed to since we are working as a team ?

  • 2
    Please consider shortening your post. It's quite a bit to read and if you do I expect you'll get much more engagement from people who come to it.
    – rath
    Commented Feb 25, 2019 at 9:40
  • OP, this is way way too long.
    – Fattie
    Commented Feb 25, 2019 at 12:43
  • 1
    "Nobody will guide us". This is totally normal in software. It's a question of "welcome to the world of software." This question is asked over and over on here. The answer is always "(1) life is tough in programming! (2) get to know your Porsche dealer!"
    – Fattie
    Commented Feb 25, 2019 at 12:44
  • @Fattie, which parts can I trim further ? I think if I shorten it further the it might result in misunderstanding. Commented Feb 25, 2019 at 12:55
  • 1
    Relevant: Cargo cult programming Commented Feb 25, 2019 at 14:17

4 Answers 4


Don't ruin your mental health on this. Yes, technically you are responsible for this since everyone on your team is. And if this was an issue that was limited to a small number of colleagues, my answer would be different. But this seems to be a team wide issue, and you alone won't fix this.

Is there other work that needs to be done ? Focus on that. You don't have to stress over a product you didn't work on, and when you tried to help someone out your work was thrown away and you even got negative reactions from your coworkers. Since it appears that you can work on what you want, choosing from a number of tasks, do that. If your manager asks you about this, you can be honest about this since they seem to be reasonable :

I've decided to focus my work on tasks outside of X project. Although I wanted to help improve the code, my contributions have been rejected and people have complained about my involvement. This felt like a huge waste of time, and I don't want to continue wasting my time when I could be more productive and produce valuable work for the company like in projects Y and Z.

You work in a team who doesn't care about quality, each member is only thinking of themselves. Don't become that, but act accordingly. Caring too much in that kind of environment will make you crazy. I'd also advice to start job searching and when interviewing at companies don't hesitate to ask them questions to make sure you're not ending up somewhere like this again.


If the tasks not disagree with your employment contract, you have to do, what your "authorizing officer" (translation software -.-, your boss, manager, scrum master -> the person who gives you your tasks) will assign to you.

But you can make clear, you need support to do your work, like cooperative coworkers, documentation of code, coding standards, agreements about architecture of software and so on.

No one can expect you build a house without an appropriate toolkit! Make it clear to your manager (and to yourself) what you really need, what you like to have and how to get it.

But if this workplace is not worth this effort (and here is your opinion the only one that counts), then you can search for a new one that fits more with your "what I want to work"-list :)

EDIT after comment:

If you as team are made responsible for goal fulfilling, then every team member is responsible, you too. Every time there are tasks nobody wants to take, but one have to. Maybe it is possible to make a "deal" with your coworkers: You take this unloved task (your coworker act like they do not love it too) for them, and they agree to support you with what you want (see "make it clear...").

In my opinion all team work base implicit on such deals, but sometimes they must be pronounced.

And to get it in context of your question: No, you are not responsible for the work of your coworkers, but you are responsible (with them) for your output.

  • I edited my post, we have no assigning body in our office, we receive some goals and then volunteer for tasks that would achieve those goals. Commented Feb 25, 2019 at 11:24
  • 3
    who checks if the goals are fulfilled? and who is made responsible if they will not? Commented Feb 25, 2019 at 11:33
  • During scrum of scrums, an overall product owner assigns these goals to our team's scrum master and product owner teammates. At the end of each sprint we as a team go over all the tasks and see whether they fit the "done" criterion or not. When things go south, we are blamed as a team not on individual basis, as company we reinforce "no blame" culture. So, as I mentioned in the post, it is collective. Commented Feb 25, 2019 at 11:41
  • 2
    This. You don't need to proactively kill yourself on others mistakes (especially if they don't fix theirs either) but you still need to do what your manager asks of you directly. In these case, explain clearly what refactoring will imply (in term of help you'll need from them and time it will take). At some point, your manager should understand that using one of his experienced dev to fix juniors errors is not the best way to employ you. Anyhow, if I were you, I would immediatly start looking for another job, you won't be happy were you are.
    – Jemox
    Commented Feb 26, 2019 at 12:27

Since this is an Agile scrum team, write a ticket in the backlog for anything you see that needs corrected. The 'team' as you have indicated will then either pick up those stories at planning or keep them in the backlog. That should satisfy your manager, indicate that you put them in the backlog and he needs to talk to the scrum master if they are not being brought in during planning.

They should then be brought in and people should take them IN PRIORITY ORDER. That is another thing you could raise at planning that people are cherry picking and not working things in priority order.

You should also be doing commitment meetings during planning. In my organization we threw a fist of five (1 to 5 ranking) about how confident we were in the plan. This is your opportunity to throw a 1 or 2 and indicate you feel the bug fixes are being relegated. The rule on first of five is all works stops if someone throws a 1 or 2 and the team has to revisit the plan until they get at least all 3s.

Lastly you should have a product owner that is accepting your stories. If not who is accepting this work as being 'done'. A 'definition of done' might need addressed. If you are doing agile/scrum are you having end of sprint retrospectives with opportunity to raise concerns and change patterns? If not maybe this is the conversation you need to have with your management that they are not really doing Agile/Scrum but Ad-Hoc.


  • This answer goes a little bit away from the "am I responsible" focus, but it shows scrum - custom - made ways to solve the situation as a whole + Commented Feb 26, 2019 at 20:45
  • We have a bit of custom team setup, PO and SM are also team members. During sprint review we create short reports or demo videos of completed tasks, and at the meeting we go over them one by one and approve that it is done. Coming to correcting things here, it is way beyond me. I neither have responsibility nor authority to change things. I have been open with my manager and team about my observations. No one cares, no one is willing to improve or listen. I am just trying to avoid problems from now on as long as it is legal and study for next thing. Commented Feb 27, 2019 at 7:38
  • 1
    It seems my comment about documenting the issues and getting them in the backlog is important from your managers perspective. Just put them in and inform him that you are documenting your concerns but it is really up to the PO/SM to determine their priority. In agile though you should have power and your team should be doing retrospectives. Next time your manager asks why you are not fixing them indicate the 'team' decides what to work on not you and you have raised your concerns, but it's really the 'team' that needs to fix these issues. Commented Feb 27, 2019 at 18:29

You're not the lead, so you're not responsible for team failures only to the part that you played in it (i.e. your code and impact on the team),no need to worry about that.

Copying in-house code was a smart thing to do btw.!

Why re-invent the wheel if the company already owns code that is suitable?!

Your scrum master was correct that you wasted time.

However if the copied code would cause issues or bugs in the final product, you indeed should try to improve it and give that as reasoning.

Your manager doesn't want you to mange or lead but he might hope that you could fix issues that others can't or won't.

If you can, that would surely raise your respect and standing with the boss otherwise your critique could be interpreted as whining.

Depending on the amount of work in the company it might not be possible to avoid that project.

  • 3
    "Why re-invent the wheel if the company already owns code that is suitable" It sounds like the person copied in a project when they probably just needed a snippet
    – Mars
    Commented Feb 25, 2019 at 10:22
  • @Mars it's legitimate (with its own pitfalls of course) to use a working, tried and tested project and build on top until you have a working prototype for your new project. Then start removing unneeded code. If carefully done with lots of testing it can result in a much stabler product in much shorter time than writing from scratch. Clearly time is a factor with this company or team as it's in any business. Commented Feb 25, 2019 at 11:11
  • Scrum master is not my boss, he is a teammate. Commented Feb 25, 2019 at 11:11
  • 1
    @oftencoffee that's ok to do. see my comment to Mars. That way he ensured you guys can work on an already working product and "all your team needs to do" is tailor it to the new project. Removing parts from the working software could render it useless and could interfere with, even harm that process of changing it into the new product. I'm not saying this is the best solution or one that I would necessarily chose but it is a viable concept nonetheless. Commented Feb 25, 2019 at 11:37
  • 2
    Why on Earth would this be downvoted ???????
    – Fattie
    Commented Feb 25, 2019 at 12:43

You must log in to answer this question.

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