Question: I'm a senior developer in a mid-sized business. We are split into multiple sub-teams with specific roles for each. My allocated team's responsibility is for the day to day running of services and bug fixing issues that arise from our product.

I have recently had a bad case of burnout related to the current COVID situation. Amongst the several concerns that I have are that of an individual team member. This team member has a habit of making breaking changes, without much thought or consideration given to others in the team, let alone across sub-teams. It is almost the bane of my life, multiple system outages have been caused by this person, but they continue at an astonishing pace of development. This is obviously viewed by management as a "positive" thing as they're getting the work done.

The catch here is that each time there is an outage, the investigation follows. This involves multiple meetings, bug fixing (my team) and slowdown in our work while we put out the inevitable fires that have been started. Worst of all, it is really hard to get them to own up to their mistakes. Talking with them, it's never "their" code that's at fault. The individual even tried to blame the hardware ECC memory for memory corruption that originated from this individual's code.

I am all for people learning from mistakes, but we barely get to put out the last fire before the next one is started. Most recently, and while I have been under a lot of pressure to deliver, I went to get the final task of the day done. Lo and behold, they are at it again and a code commit broke my work.

I quite publicly flipped out on our team channels about it because I was pretty fed-up with the direct approach. This has got management attention, in that their manager got involved. After talking with management time and again, little seems to have changed with this individual.

How do I raise this to management’s attention, get them to act and, more importantly, help prevent this from continuing?

Answer: 
With respect to getting management to act it's helpful to quantify the problem in relevant terms (money is best, time is also acceptable).

For example:

> 
> Change 123 broke the system, resulting in X hours of downtime and costing
> us $Y in lost revenue.
> 
> 
> Change 456 created bugs that upset Big Customer (costing them $ etc.).
> Big Customer is now reconsidering their relationship with our company.
> 
> 
> Change 789 caused an outage which required Z hours of development
> time to fix. That time came from Important Project X. Important Project X is
> now delayed Z hours.
> 
> 
> 

The idea is to frame the issue as one impacting the business.

As such it's equally important when writing such a list to ignore things that aren't impacting the business (directly). It doesn't matter how fed-up you are (sorry), it doesn't really matter that you're having to work a lot (again, sorry). It also doesn't matter if this particular individual hasn't responded to your previous attempts at getting them in line. None of these are really business problems.

As to what your managers ought to do (and you should be ready with suggestions) it depends on what your company already has in place. If there are supposed to be code reviews prior to commit for example, but they're not happening, or they're not being done effectively, that could be addressed. If you don't have code reviews you could suggest starting them (of course they cost time/resources too so that has to be balanced). You could implement various testing regimens, or you could actually use the ones you do have (if you have some) etc etc.
It's *their manager's* responsibility to deal with **all** "personnel issues." You should speak to *your* manager, describing the situation, so that (s)he can speak to the other manager.

You should be fully prepared, of course, for them to also want to speak to *you,* and you, too, are obliged to do your part (as *they* see it) to achieve resolution. Be prepared to be told -- and, to accept -- that *you* may be completely or partially wrong. "Be professional."