I am a software developer planning to leave my current job in December, unless something significant changes. This is entirely because of a single coworker within a small team, whom I think is harming the company and whose actions are making my job harder and at times unpleasant.

So, my question is, what is the professional way to divulge my reasons, if it's possible, so that it has a positive impact on the company, and which reasons should I divulge?

Here are the main categories for why I have decided to leave, with some examples (sorry it is so long, I'm hoping this is useful to others who have seen these behaviors):

  • Blame and offloading responsibility. Since I have started this colleague has sought to blame others, often when they were partially responsible. No-one else levels this blame at one another, and I feel this is harming all efforts to create psychological safety and an open engineering culture

Example 1: Colleague B made a configuration change that caused a bug. The configuration was for a service written by difficult colleague, whom had not documented the configuration. In my opinion this was a joint responsibility but no-one should be held accountable. However, difficult colleague brings this up we;; over a year after it occurred, in front of other colleagues, recently completely unprompted.

Example 2: Difficult colleague doesn't follow standard industry practice for code repository management (although hopefully this has changed after two years of asking). Difficult colleague made some changes in a repo he manages, colleague B made some unfinished changes and committed them. Difficult colleague publicly blamed colleague B for introducing unfinished code into a service he wanted to deploy. If the repo had been managed correctly, the unfinished code would not have had an impact.

  • Poor software development practices making change difficult. Difficult colleague adopts well-known anti-patterns in his code, is unwilling to change them, and also makes his services difficult to change.

Example 1: We have all adopted test-driven development. Difficult colleague is the only one not writing tests with the explanation that he lacks experience. I spent about four hours showing him how to write tests (with him disagreeing with everything I said). It transpires that one of the anti-patterns difficult colleague has adopted make it impossible to write tests in some places. We now have services that are critical to our software functioning that are a) hard to understand (lack of tests), b) hard to change (lack of tests), and c) hard to write tests for (anti-pattern).

In one case I chose to adopt a design that, whilst not ideal, was chosen solely to avoid making changes to a service he had largely written and had critical bugs in the past.

  • Business ethics/not following process.

    • Not following code review processes. Our company adopts the standard practice of code going through review before being committed to the master branch and deployed. Difficult colleague has been voicerous about people needing to raise PRs sooner than later. I recently came across a service he had written for me to use that had been written on the master branch with no code review process. I confronted the colleague calmly, and he agreed he shouldn't do that, and that he would fix it. The next day I ask when he'd put it in for review, and he spends the next twenty minutes telling me I'm being difficult. Eventually he gives in and spends a couple of minutes putting it up for review.

    I later find he has done the same thing elsewhere. I immediately asked our manager to make PRs mandatory on all repositories. I did not divulge the reason.

    • Deploying live code without monitoring. Difficult colleague has deployed some critical changes and not checked on them the same day, the next day, or even the next week. I accidentally came across critical data losses caused by his changes three months after they were made. It would have taken him minutes to have manually seen these errors, or a little longer to put in automated alerting.

    • Not reviewing code. Difficult colleague does not take the same time others take to review code. I will frequently see him accept 5+ PRs in quick succession shortly after they have been raised. It is impossible that he has read the code sufficiently, if at all, to understand the changes.

  • Unequal workload and effort. This has impacted obviously our capacity, but I also find us making design decisions because difficult colleague doesn't want to do X or Y (making someone do something more arduous instead).

Example 1: For the past six months difficult colleague has been tasked with developing an API. This API is something I would expect to see finished within a few weeks (I have worked with others developing something very similar). After six months I have not seen a single line of code or a design document. I looked to see if he had any outstanding code branches, he has none and he has directly written code onto the master branch without review (this is a different repo to the one in the code review example). This repo is also critical for security.

Example 2: We had a tight deliverable recently. Looking at who was assigned what, there were some additional unassigned tasks/services to build. Difficult colleague had a days' work assigned. Other colleagues had about four weeks. We were asked who was willing to do X, Y, and Z. After awkward silence difficult colleague did not volunteer for any of these, which were taken up by other members. During this deliverable difficult colleague did little beyond their one days' worth of work. Everyone else worked long hours and some weekends.

  • Strong opinions against standard practice/whilst lacking expertise. We have had very long discussions, a war of attrition, where he was typically on one side of the argument and one or more people on the other. Sometimes he is right (obviously), othertimes he isn't and he won't give in.

Example 1: when our new product was about to be released he argued heavily against putting logging in on core services, saying we didn't have the time. The argument took approximately one hour and got quite heated. We eventually put logging in, which took the person responsible about twenty minutes, and allowed us to discover and rectify critical issues post-release.

Example 2: I have more experience in event-driven systems. However, when I explain the functionality I think we need and the kind of products we should use, he simply says they don't exist, and they can't exist. I have used these products in the past. As a result, I feel that we've gone for solutions that aren't fit for purpose because he won't back down and although we could investigate a solution together, I lack time to investigate on my own.

Example 3: He will derail discussions by stating service X does not work in the way described by a colleague, despite that colleague being the one who has written it. Typically the conversation ends with him saying the service must be wrong then.

  • Argumentative/rude nature taking up time and energy, and personal attacks. I have been in many conversations where he will suddenly say of someone's code "it's complete bollocks" with no explanation. This riles the person up (not usually me) and derails the discussion. In other cases he will get personal, for example saying to a colleague "you only got hired because you're other colleague's friend", or when he started having a go at some of my lifestyle choices.

He explains it away saying he gets bored so he likes to get a reaction from people. But it has, in my opinion, harmed our work. Moreover, he has stated he hopes his behavior doesn't cause people to resign, whilst continuing with his behavior.

To be clear, with all of my colleagues and between colleagues I feel that we're able to argue different opinions without issue and as a result come to good solutions. It feels collaborative.

I don't want to tell my managers this before I leave, because I feel that would be holding them hostage and I'd expect them to sack the hostage-taker (myself). I also don't want to be directly responsible for getting someone sacked. Finally, maybe I'm the problem, and so I don't want to give an unbalanced view that could affect decision-making, I'm simply too biased.

At the same time, I have a very small financial interest in the company, and I otherwise enjoy the role, my other colleagues (I think the team is otherwise fantastic) and our product; hence, I want to be honest if it would help the company. However, in the past me and the colleague have had personal problems (largely because of his criticisms), which leaves me to believe my current bosses would put it down to my issues and not his.

  • 6
    "I don't want to be directly responsible for getting someone sacked." - Yet you are willing to let him be solely responsible for getting you sacked. - This is sloppy thinking. You owe him less than nothing. Oct 1, 2022 at 14:45
  • 1
    @BernhardDöbler what do you mean? If you can rephrase it or elaborate, would be interested.
    – user136932
    Oct 1, 2022 at 14:57
  • 1
    What are you aiming to achieve by giving reasons? What do you expect the outcome to be if you do? Oct 2, 2022 at 12:55
  • 1
    So many answers, so I just comment. You don't have to ... but I think you definitely should explain your reasons. This coworker or generally this situation might alienate many others because nobody has the guts to bring it up to a superior. Perhaps a harmless talk could change the situation. But if nobody does, instead everyone just quits - perhaps you land in the same situation again, where others too didn't dare to say something. Wouldn't that be selfish and gutless? You don't have to make a big drama, but some neutrally spoken comments shouldn't hurt especially if you are gone soon anyway.
    – puck
    Oct 3, 2022 at 10:19
  • 1
    @AaronF I think there's some truth in that. Part of it is I'm lying to myself, as you suggest. Another part is that getting rid of someone has repercussions for the rest of the team (people worried about their own job, for example), and then there's the possibility that I'm way off the mark and he's actually a good employee.
    – user136932
    Oct 4, 2022 at 8:42

6 Answers 6


Before you "up and quit(!)" please give your manager the very same "heads up" that you just gave us.

Present your concerns to him or her. Then, please expect that he or she might then request a little time to think it over.

And then, on your next meeting on this topic: shut up and listen. Don't say a word in your defense. Leave the meeting politely and, "think it over."

In your original post, you certainly seem to presume that you know how your managers will react. But, did you actually ask them? Why on earth do you expect that they would respond by "sacking" anyone – including you? Do you somehow think that managers are vengeful?

P.S.: It is quite obvious from your posting that "you have never yet actually been(!!) a software manager." (Ahem ...)

  • Thank you. Good point about lack of management experience, I'm doing too much mind-reading.
    – user136932
    Oct 3, 2022 at 8:27
  • Undoubtedly so. And let me also say that "software management" is definitely an acquired taste. Many people who try it ... hate it and go back to coding. Nevertheless, in this situation, before you pull the switch, I hope that you at least give your manager: "a fair chance, a mostly-closed mouth, and a wide-open ear." The management perspective on things really is different (and useful), and you simply don't see this unless you've been there. (Trust me on this.) Oct 3, 2022 at 19:21
  • "This is a workplace experience – which happens to us all – that you can actually learn from." Good luck. Oct 3, 2022 at 19:27

If you didn't complain about the behaviour to your manager, then don't bother.

Looks like you gave the company no chance at all to rectify matters.

You should never leave due to the behaviour of a coworker, but the behaviour of the coworker, along with the response of the company.

They are unlikely to investigate matters now that you're leaving.

  • Thank you. I didn't mention this, but I did describe my issues after one year by asking "how can I work with this person?". Their response was that the person was difficult, and often argued things that made no sense, but I should argue with him because it might be fruitful. Unfortunately, I feel emotionally drained after so many arguments. I obviously didn't mention the other issues, so you have a point.
    – user136932
    Oct 1, 2022 at 16:25
  • @AnonymousProfessional - You wait a year before you brought these issues to your management?
    – Donald
    Oct 1, 2022 at 20:40
  • Yes and no. Shortly after I started a manager mentioned this colleague was difficult. So I felt there was tacit and common knowledge of the situation. But you're right I did hold out, which was largely because I didn't want to be pushed out for kicking up a fuss.
    – user136932
    Oct 1, 2022 at 21:38
  • @AnonymousProfessional Your comments here (that management knew how he is and that you did try to address it with them) should be part of the question. In any case, this is all the more reason not to bother saying anything. They already know he’s a problem and they’re OK with it.
    – BSMP
    Oct 2, 2022 at 9:58

"...which reasons should I divulge?"

None. Nothing at all. Always use "it's-not-you-it's-me" approach.

Stick to the boilerplate response: "Moving on because I am offered better benefits and a more challenging roles where I believe I can grow personally and professionally, and the mission and visions are more aligned with my desired career path."

Based on your existing relationship, you can change the words a bit, but more or less, this is the way to go.


While I would have recommended that you try to get rid of that difficult colleague (by complaining to your manager or otherwise), once you decided to leave, just leave. If you came to me with these complaints when you have a new job, all I would do is ask you why you didn’t complain earlier.


which reasons should I divulge?

You don't have to mention any reason when you quit. Simply move on with your new career, and diplomatically wish your old company the best in order not to burn the bridge.

Leave that difficult colleague and your old company the way they are because, pretty soon, they will no longer be your concern, responsibility, or business.

You may have the good intention to help that difficult colleague and the company improve, which is a good thing. But, when you quit, many companies hardly take your inputs seriously because they think that you don't have any long term interest in the company any more.

Furthermore, some of your suggestions for improvement might even be mistakenly perceived as negative/unfair criticism or personal grudge against that difficult colleague on your last few days. In the end, your constructive inputs may not be perceived as helpful by the old company despite your good will to help them improve.


All of your answers would be perfectly suited for a 1:1 with your manager. Once they’ve been presented in writing, if there’s still not a resolve, you will have all the clarity you need.

You must log in to answer this question.