My colleague and I work together on a project. We generally get along well on a personal level, and he makes good contributions to the team. His opinions are often valuable and highlight things we might not have thought of.

Recently we've started butting heads. Basically, if he can't see why a certain decision is made or has an idea in his head, then he just won't let it go until every angle has been debated. It gets to the point where it's easier to give up and let him have his way just so we can get on with things. That's not to say we never compromise, but the times when he digs in are getting more frequent.

I've written two examples below, but I've observed similar behaviour in discussions that I haven't been involved in. [Edit: I've removed the examples because too many answers are focusing on the details of those and not the bolded questions. If you want to see what they were, check the edit history]

This is wasting a lot of time, especially so when it relates to things that are already done/decided. His responses get to the point where he sounds sulky - "do as you see fit", etc. - but even then he won't drop it. If we do it his way, it could mean throwing away other work or compromising on something already completed just for the sake of appeasement.

We work very closely together, so it's important to maintain a positive working relationship, but his stubbornness and taking things personally are making me avoid engaging him in case it turns into a long, draining argument. The most recent argument has left me in a bad mood for days and unable to focus on my work.

For various reasons, we don't have a clear management structure, so it's hard for me to bring it up with anyone who has authority without it looking like a big escalation. We both started our roles at the same time (less than a year ago) and are at the same level, but from our previous positions, he would have been quite a bit more senior to me. That said, the main part of our work is outside our areas of expertise, so we're both relatively new.

For the short term, what can I do to complete my work in situations where it looks like he's digging in? For the longer term, what can I do to discourage this behaviour without damaging the working relationship?

  • 29
    "we don't have a clear management structure, so it's hard for me to bring it up with anyone who has authority without it looking like a big escalation" I think you know the root cause here. Hierarchy is a necessary evil at times. Commented Apr 11, 2022 at 12:22
  • 24
    Your coworker can't reproduce the issue mentioned in the "second example". Can you help him to reproduce issue and clearly prove that the problem actually exists ? Commented Apr 11, 2022 at 17:25
  • 31
    A less experienced collegue and non-technical management not being unable to appreciate your concerns about their descisions can be very frustrating. If I built a framework and my collegue did something entirly different /parallel without even trying to work with me first and implement it the way it was supposed to work I would not be happy too. It is true that often we need to tweak a framework to make it support initially unforseen use cases, and it is entirely reasonable. Building a prallel system instead is less so, especially without a prior discussion. Commented Apr 11, 2022 at 22:58
  • 11
    "list of things I've been doing wrong" --> If items in the list are accurate, address them. If not, move on. Commented Apr 12, 2022 at 11:10
  • 16
    @JoeStrazzere It does take two to debate, but if it also takes two to move on, the other person can hold you hostage. If that is what is happening here - and it seems to be the case - then 'debate' is a polite euphemism.
    – sdenham
    Commented Apr 12, 2022 at 12:49

11 Answers 11


I have a similar perspective to sf02's answer where they say:

The only reason that you are wasting your time and having your morale affected is because you continue to engage with and debate this coworker.

It takes two to tango, so it is not just your coworker who has trouble letting things go. Most of us can very easily be pulled into a debate where we get caught up in responding to every point someone else makes to try to convince them our way is the best way and end up frustrated. As mentioned in a comment, it’s very difficult to convince someone else to change. It’s much more effective to change how we respond to what they do.

I do think there are some strategies you can use to make these discussions more positive instead of just cutting them off with some sort of "the decision is not up for debate" statement.

  1. Make a noticeable effort to understand their concern. Ask them questions about it. Repeat back to them what you think they're saying. Often when I end up frustrating people during an issue discussion, it's because I don't feel like they're really understanding my point. I fully admit it's more likely a problem with how I'm perceiving things than the person not actually understanding me, but a statement like "I see why you're concerned, but that's rare and we don't have the time." can end the discussion before everyone gets too frustrated.

  2. If you think the solution when you find a problem in someone's work is to throw it away, write your own version, and then be surprised they don't want to use your work, you are part of the problem. If you have any respect for that person at all, you would show them the problem and help them fix it, offering your advice, so it is a collaboration. Your anticipation of a frustrating drawn-out debate is not a reason to treat someone like that, and is just exacerbating the issue.

  3. Listen instead of arguing. It's OK if someone doesn't agree with a decision. It's not your job to make them like it. If you want a good relationship with someone, listen to their concerns. You can even agree with some of them without necessarily agreeing that the decision has to change. I think it is easy to turn a discussion into a debate when we are sure we know the "right" answer or we don't want things we thought were already decided to become undecided. In a discussion you aren't there to just refute everything someone else says. Try to have discussions where someone might make you see something you hadn't considered instead of debates where someone wins and someone loses and neither of you changed your mind about anything.

In my experience, when it comes to communication issues, it's almost always easier to change how I'm communicating than it is to convince someone else to change what they're doing. Except when someone is talking with their mouth full of food. Then they need to change ;)

  • 3
    Thanks for the comments. My question is never going to properly cover the full situation I'm working in without turning into a novel. We do have conversations where I apply 1 and 3 (maybe not always perfectly but I do try). I really would like to have seen him apply those to the other party in the last two incidents as well as others I wasn't involved in. But I admit, I'm finding it too easy to reflect that behaviour back at him. I probably would have approached 2. better if I wasn't already hesitant to talk...
    – Bamboo
    Commented Apr 12, 2022 at 1:54
  • 11
    @Bamboo: "I really would like to have seen him apply those to the other party..." Yep, that would be the ideal solution, but, unfortunately, we can't change the behavior of others. We can only choose how we behave.
    – Heinzi
    Commented Apr 12, 2022 at 12:14
  • 10
    @sdenham It is not predicated on the other person being reasonable. I'm saying that it's a good idea to let go of trying to convince the other person to accept whatever it is they are arguing against, and also, here are some strategies for adjusting your communication style to make discussions less likely to get frustrating. I don't have time right now, but I'll think about how I can make that clearer. If you stop engaging, the argument stops, no matter how unreasonable the other person is.
    – ColleenV
    Commented Apr 12, 2022 at 13:15
  • 3
    @sdenham I disagree. This is a good answer and works for the general cases as well. If people are argumentative, just stop. Stop presenting causal relationships that can be dissected. Stop presenting arguments and rationale. In short, stop arguing.
    – Stian
    Commented Apr 12, 2022 at 13:46
  • 3
    @sdenham No, it's not. From the examples given, the person arguing against the solution didn't seem to have to power to unilaterally implement it. You don't have to have everyone agree with a decision to implement it.
    – ColleenV
    Commented Apr 12, 2022 at 14:52

Completely missing from all the answers here is any consideration whatsoever of even the remote possibility that OP's solutions have been technically wrong, incomplete, or harmful.

It is entirely possible that OP is blundering about, messing things up, and his coworker is desperately trying to limit the damage that he is doing.

I can easily see an alternate question, posted by OP's coworker, to the effect of:

I have a coworker who makes mistakes, but gets non-technical management to sign off on them, and when I try to get them to see reason mic drops and says the boss said I could do it this way.

Since the original question says:

We generally get along well on a personal level, and he makes good contributions to the team. His opinions are often valuable and highlight things we might not have thought of.

...in OP's place I would ask myself, "Why is someone who is generally a good guy and whose competence I respect arguing so strongly on certain technical points? Is it possible he's just right?"

  • 8
    @Bamboo, reality isn't a democracy. Sturgeon's Law governs everything. If your coworker acts this way toward others, it could simply be that most of them are idiots. It's not unusual for projects or entire companies to be held together by a single person who knows what they're doing. Management has a fiduciary duty to seriously consider this possibility. Commented Apr 13, 2022 at 15:07
  • 4
    Amen. I would say to have a more senior 3rd party review the issues and make a recommendation. "Doing what the boss said", especially on technical matters, means you are headed for disaster. I've seen it many times. Bosses can describe the vision, but are usually clueless technically.
    – Bohemian
    Commented Apr 14, 2022 at 2:39
  • 1
    @TechInquisitor Sturgeon's Law governs everything - that's a bit of a long bow to draw. But if we're going to appeal to adages and the like, then I'll appeal to Occam's Razor: If one person has a problem with everyone, the simplest explanation is that person is the problem. The question doesn't give a full picture of my situation, but I guess everyone is going to project some of their own situation to fill in the gaps...
    – Bamboo
    Commented Apr 14, 2022 at 2:47
  • 4
    I don't think it's people projecting, so much as people can only answer based on what's in the question. As there are facts missing apparently, for reasons of brevity, you will inevitably get answers that don't consider those facts Commented Apr 14, 2022 at 6:24
  • 4
    @Bamboo I honestly am not trying to run you down with this answer, and it's definitely possible that your perspective as offered in the OP is completely right. But when I read the question and its existing answers, I didn't see this possibility even considered at all. So I offered this answer as a counterpoint to the ones that existed at the time, just to consider all possibilities.
    – tbrookside
    Commented Apr 14, 2022 at 10:40

Colleague just won't let things go. It wastes time and affects my morale

You need to let it go. The only reason that you are wasting your time and having your morale affected is because you continue to engage with and debate this coworker.

Next time an issue comes up, where you have made your decision, and your colleague objects and wants to start a debate you reply with something like:

The decision is final, if you have any issue with it you can reach out to the boss

This way, if there is a "big escalation" it would be due to your colleague and not you. Continue to do your work and don't engage in any unconstructive dialog with your coworker. Let your boss handle the disagreements.

  • 2
    As much as I'd like there to be a nicer way to handle it, I think you are right with the stone walling approach. His persistence is already taking it in a less than cordial direction
    – Bamboo
    Commented Apr 11, 2022 at 14:02
  • 15
    When a colleague is "stonewalling", that isn't your issue, that is your boss' issue. "Boss, X is taking up my time arguing over something that you settled." Seriously, don't argue with him. Raise the issue of him wasting your time with your boss. When someone else's behavior is affecting your performance, that is a management issue, not yours.
    – David R
    Commented Apr 11, 2022 at 14:46
  • 5
    Before I read your answer, I was thinking of a recording of a song from "Frozen" that you could play when he gets going...
    – gnasher729
    Commented Apr 11, 2022 at 14:49
  • 18
    "The decision is final" is not a good way of phrasing things. Commented Apr 11, 2022 at 22:45
  • 3
    Pretty great way to destroy a culture of collaboration if it ever existed, this answer.
    – ldog
    Commented Apr 14, 2022 at 5:45

It is significant that you are both getting up to around a year working at this place and on these systems. How much is the system causing these arguments?

The tactical communication strategies in the answer by @ColleenV are good. Use those. There may also be fundamental things pushing you into conflict arising from the state of the system you are both working on, and your mental models of how it works.

It takes a long time to learn software systems and for colleagues to have confidence in a new joiner's changes. It can sometimes take months to start getting productive. After a year, though, informed opinions about the strengths and weaknesses of the design are to be expected, especially from a developer with more previous experience.

I can't tell from your account who the better developer is. There's some suggestion you prefer to get value delivered quickly, while your colleague prefers to build frameworks and create abstractions. Both developer styles have failure modes, and all developers should try to improve their work by considering whether a given solution is a rushed hack or a premature generalization for a misunderstood future need.

It may be worth putting aside some time to build this shared design understanding. Rather than debating a decision already made, have a few casual whiteboard sessions over the course of a few weeks. Draw some informal diagrams of important parts of the system one of you doesn't understand as well. Make a list of the things you both like about the system, and the three things that cause the most daily pain. Come up with some concrete changes you can both agree on. If there is a technical owner of the system (and they are actually technical), try and get them in on one of the sessions.

In the best case, having built a more shared mental model of the system, also shared with technical management, you'll be able to make less emotional technical decisions, based on a common understanding. In the worst case, you'll have learnt more about the system and where your colleague's triggers are, will have practiced thinking about the future design of the system, and be better able to justify your decisions to others later on.

  • 2
    I like this idea a lot. It not only addresses what could be the source of the conflict, it can also reinforce that the relationship is one of mutual respect and collaboration. I think it would be worthwhile to figure out a way for the team to do this together, since it is not just Bamboo who is getting dragged into these debates.
    – ColleenV
    Commented Apr 12, 2022 at 12:28

Whether you like it or not, the workplace can be a competitive environment. Your coworker may be protecting their reputation by pushing back on your attempts to implement a procedure outside of the existing framework. There are two ways to view this. First, when a project decides to adopt a framework, it should be used in all cases where it can be used. Any time someone writes code that circumvents the chosen framework they are creating risk and additional support tails for the project that lead to higher costs. Second, if the framework fails to support a set of new requirements, that should be documented and a decision should be made about how the new requirements will be handled. This is typically the role of the product manager. It may be advantageous to spend time improving the framework to handle the new requirements.

Some developers write code for an organization and move on. Other developers write code to build a "code" empire within an organization and they never move on. Depending on the length of their "reign" it may be hard to unseat them.

Finally, since this person doesn't report to you, the fact that they are wasting time is not your problem, just like your morale isn't their problem.

  • This sounds like sensible advice in general, but its hard to apply it to my case because it feels like it assumes a business structure that just doesn't exist for me
    – Bamboo
    Commented Apr 11, 2022 at 14:04
  • 1
    I am not sure why this answer gets 3 downvotes at this point. Can someone please explain ? Thanks. Commented Apr 11, 2022 at 17:30
  • 1
    @Job_September_2020 - Tough crowd.
    – djhallx
    Commented Apr 11, 2022 at 21:14
  • Product managers deal with features, and not technical decisions down to the framework level.
    – Xavier J
    Commented Apr 11, 2022 at 22:16
  • 6
    @Job_September_2020 I don't think there's enough information in the question to assume that the OD (other developer) is being competitive. If the OD saw some genuine technical problem and was just trying to prevent catastrophe then their actions would probably be the same. Assuming that the OD is acting with good intentions (even if you disagree with them) and responding accordingly usually leads to the exact same tangible results and also the greatest personal happiness. Commented Apr 12, 2022 at 17:25

It sounds like you are doing technical implementation work, probably in software (web design? Internal app?). I somehow find myself vaguely in the role of your colleague (let's not say opponent or adversary) and thought I might be able to provide a few perspectives which may be missing from this discussion. But I'm reading between the lines here, and could be guessing completely wrong about your colleague's incentives and frame of mind.

  1. Speculation one: You have different perspectives on which compromises are acceptable. You want to get things done, your colleague wants to get things right. This can be hard to reconcile, but discussing the root problem could perhaps be helpful. Collecting a backlog of technical debt would at least bring visibility to the compromises you have agreed on, and provide a way to eventually quantify and perhaps escalate the accruing quality problems.

  2. Speculation two: Your colleague has a wider perspective on implementation or usability principles, and fears that the work you do will be unacceptable to the end users, even if your PHB has declared that clicking 18 times to do the most frequent operation is going to be acceptable for them. (Caricature warning, but I'm afraid this is often not far from the truth.) If your current process is not based on quickly iterating designs with real end users, perhaps think about moving towards that if you can.

    Similar arguments could apply to software robustness, reusability, compatibility, etc; your question does not really reveal which aspects you are disagreeing about. I'm hoping at least this example could stimulate you to think about underlying motivations.

  3. Speculation three: Your colleague is venting frustration over fundamentally unrelated problems, perhaps related to a "death march" project or an unhealthy organization. I really have no remedies for this, other than perhaps recommending that both of you look for a way to escape. Commiserating about the situation is probably only going to degrade morale further.


I think you can improve this situation by making decisions up front together, then work on your parts after decisions are made. This will remove the conflict and these kind of discussions generally lead to better decisions.

You could integrate such decision making into your workflow by talking with whomever will listen (might be the boss), so that it will be known that you do decision making together removing any potential confusion when you receive some work and refuse to start immediately.

  • How would this help with the scenario of "CEO gave an edict, and coworker refuses to comply"? Commented Apr 12, 2022 at 10:41
  • 1
    I couldn't see that in the question, is it in a comment @chronocidal ? Commented Apr 12, 2022 at 19:13
  • @mattfreake I paraphrased the first example OP posted (under the line break in the question), by simplifying to "CEO" instead of "our boss's boss's boss". They weren't being asked what they thought they should do, they were being told what they were going to do. Commented Apr 13, 2022 at 10:34
  • That is one instance. I don't think it could be helped much, but it seems there are many cases this mentality will help. Also if the boss knows that they work very closely together, might call them together to the meeting. Commented Apr 13, 2022 at 11:21

I can't yet upvote or comment but I agree with tbrookside's answer and feel this exchange needs more balance.

..he makes good contributions to the team. His opinions are often valuable and highlight things we might not have thought of.

Basically if he can't see why a certain decision is made [snip] he just won't let it go until every angle has been debated.

..from our previous positions he would have been quite a bit more senior to me.

I implemented what the boss approved. My colleague felt like it might have some rare negative impacts, and wanted to make some changes.

The picture you paint is of a Senior using the foresight granted by experience to protect the team/product from future pitfalls and high-interest technical debt, at the cost of their own time and perhaps their standing within the company.

Their interaction with management supports this. Communication is hard, and so much of what specialists do is both business critical and entirely opaque to higher-ups. Hence the need to "be difficult" now and then in order to protect against issues others cannot see.

Two relevant factoids:

  1. If you lack the experience needed to see a potential issue, you also lack the experience to see your own lack of experience.
  2. The correctness of an answer is not determined by the social or corporate standing of the person answering.

How do you expect your colleague to react when you do things that affect everyone in a way that conflicts with their judgement(1), then attempt to justify it by leaning on management(2)?

  • I appreciate the take, but you're making some big assumptions, probably my fault from editing down the question. I mentioned the seniority thing to give some context about the dynamic between us, but neglected to mention that we're both working in an area outside of our expertise. I've made a slight edit to clarify
    – Bamboo
    Commented Apr 14, 2022 at 3:00
  • 1
    @Bamboo experience is different to expertise. Experience allowed foresight about potential problems in a system even when you’re not an expert.
    – Tim
    Commented Apr 14, 2022 at 10:00

I agree with sf02's answer, I just wanted to add that it seems to me your colleague acts as if threatened. If you manage to avoid his "fragile" code altogether (let's assume you're right and you've not just removed code covering important edge cases), it may be that the coworker feels threatened by your ability - you're talking to the "boss 3 levels up" - so probably he feels he needs to justify himself (why didn't he choose the simple option?).

Personally, I'm always happy to see a lot of code go (my own or others'), but some people are not that secure and ready to accept that every developer, at some point, does something like that. The simplest ideas are the hardest to find sometimes!

How to deal with that depends - you don't seem to have a great working relationship. But it certainly cannot hurt to make an effort to acknowledge your coworker's contributions, and see where that goes!

Just my 2 ct, having had similar colleagues. Best of luck :)

  • 1
    It might not change the thrust of the answer, but I'll just point out that I said "our fragile code" not "his fragile code"
    – Bamboo
    Commented Apr 13, 2022 at 3:26
  • Apologies for misreading. Of course, this is a speculative answer, you'll have to reflect on the situation to see if it applies.
    – bytepusher
    Commented Apr 13, 2022 at 11:54

You dont know what to do. So begin with what you know to not do. Dont engage in debate with him.

See how much work you can do thats not related to him. It would be a lot or it would be little but it will get done, with time and energy saved.

Now there ofcourse is work that is related to him. Its already decided that whatever happen you arent going to engage in debate. Be a listener. Ask him solution. If he comes up with a solution, and its good enough, implement it; if its not good enough then point out one, just one flaw in it. Dont argue. Let him come with an improved solution. If he dont bring an improved solution, or he didnt come with any solution to begin with, just freeze dont do anything until he ask you for your solution. Then you give your solution.

If he still argue, say your solution have x, y, z flaws, then see if it actually have. If it have those or any one of those and they are worth correcting then correct them. If they are minor or non existent then after telling him what you think, freeze, dont do anything.

Its as much his job to get things done as its yours. So make him share the burden of responsibility. Do so by freezing. You too can keep him hostage.

Any organization thats good enough to work in wouldnt punish you for these freezings. It will punish you for unnecessary debate and for poor quality work, and for not reporting a problem as soon as it gets out of your power to solve. So dont continue talking if its not going any where and you have already made yourself clear; dont compromise by agreeing on bad solutions, and dont hide problems from whoever you report to if its clear you cannot solve them.


Just tell him that he has an attitude that isn't helping. That he is wasting time by discussing for hours things that have long been decided. That it is your job to do your job and not to convince him to let you do it.

He is either well-meaning and getting it completely wrong, or he is doing this intentionally. In both cases, you can't convince him. You can only put a stop to it. So if any discussion takes more than three minutes, tell him what you are going to do, that you won't waste your time, and if he disagrees, he can find a manager. Managers will let themselves been drawn into this only once.

  • 1
    "Managers will let themselves been drawn into this only once.". That is right. It is not a good idea to get managers to resolve the different work strategies between 2 workers every week because it will look bad for both workers as it seems the workers can't get along with each other. Commented Apr 11, 2022 at 17:33
  • 15
    "Just tell him that he has an attitude that isn't helping. That he is wasting time...". Please be careful when you do that as it may look like you are attacking him personally, and he will become emotional and retaliate. If it were me, I would not tell him that way though... Commented Apr 11, 2022 at 17:36
  • 6
    In general, pretending like you know what is in someone’s mind and that it is “problematic” is a terrible way to maintain a positive relationship with a coworker. Instead of a “bad attitude”, this colleague could be really passionate about making their software the best it can be and they are just going about it the wrong way.
    – ColleenV
    Commented Apr 12, 2022 at 12:36

You must log in to answer this question.

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