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: 
You must make an ironclad rule that if a person commits code that breaks the build, the commit is *instantly* reverted and *that person's work is not completed*.

If you don't have the authority to make and enforce such a rule, then you must convince the party who does have that authority. Document completely the actual costs of breaking the build.

Until this rule is in place, act as if it were. When the build is broken, revert to the last good build. Demonstrate that the only difference between project software that works and project software that does not work is that one commit.

You should be making a lot of noise about this, to everyone from your colleagues to upper management.
I agree with others who've advocated using a CI system and tests. In my startup, we run tests against each pull request, and only those that pass can be merged. After the merge, tests must pass again before the latest merge is deployed to production. And if a pull request breaks production, it is *immediately* reverted. Then it's up to the developer to clean it up, get it through code review again (usually with new tests to demonstrate that the problem is fixed), and ensure it passes tests. We still have problems that take down production, but only for a matter of minutes at most. If in doubt, we revert first and ask questions later.