I am assigned to work with a co-worker on a project. Before we even start, he is saying exactly every single way we should do every feature. Neither of us are assigned as the "product owner".

Often times, disputing any of his suggestions or proposing a different one is a huge uphill battle. This seems to be met any time I don't want to do something the exact same way he would do it, and is usually a long and tedious process.

this part edited for clarity

For example, say I have a challenging problem to solve. I will choose one way to solve it (many different ways may exist) and submit it for review. If this doesn't match up with how he would do it, this meets heavy resistance. I consider his approach, and if it works better I will adopt it, but if I know it won't, I try to demonstrate why I don't think it's a good decision, through either isolated experiments or outside sources. Still, he often will hold his ground and not approve it until it matches his approach.

I feel as though I am not allowed the same level of control when he chooses to do something though. For example, I will strongly disagree with one path he took, and want it changed. He will respond along the lines of "let's keep it this way for now", or something relatively dismissive. So that gives me two options: either escalate and stand my ground, or to give up and just accept it.

If I want to really strongly object to it and want to have a "say", I need to pull in our manager, who will be forced to choose a side and make us stick to it. Regardless of what side he chooses, this makes me feel a bit more comforted knowing that it was an impartial third party.

end edit

My manager has said he is okay with mediating these, but it feels unbelievably petty on my part. On top of that, it feels like it creates a sense of animosity between us, which is not healthy for the work environment.

Is there a better way to handle this?

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Mar 15, 2017 at 20:45
  • 2
    Your manager probably should have assigned one of you the official leader. I've seen leaderless groups work, but not when there are constant conflicts over direction. Mar 16, 2017 at 14:28

6 Answers 6


When he makes a suggestion or criticism of your pull request, explain once why you aren't going to change it to match his suggestion. It should be simple and clear. For example:

"That wouldn't significantly improve the code."

"The effort to make that change isn't justified by its value."

"The current method is simpler."

If he still refuses to accept the pull request, escalate to management. You can do it by email, for example: "Pull request X has been open for Y time, still waiting for Z's approval. Z has not given any sufficient rationale for rejecting the pull request."

Force him to be the one delaying and interfering, since that is what he is doing. Point out that his insistence on constant design changes or his refusal to timely approve pull requests just because they're not done the way he thinks is best is wasting your time.

Note that you are going to management simply to decide whether or not your code is acceptable as is and whether or not the pull request should be accepted. Either your code meets the applicable standards or it doesn't. If it does, it should be accepted. If it doesn't, he's right and you're wrong.

  • 14
    If it does, it should be accepted. If it doesn't, he's right and you're wrong. To me this is the important bit.
    – coteyr
    Mar 14, 2017 at 23:52
  • 8
    @coteyr And, hopefully after a few times of management having to arbitrate pull request disputes, whoever is off from what management expects will recalibrate their standards. The OP might be trying to push through truly crappy code. The other person may be a perfectionist or even flat out wrong. We don't know, and management should be deciding. Mar 15, 2017 at 0:01
  • 1
    Yes, let the manager manage.
    – coteyr
    Mar 15, 2017 at 0:19
  • 19
    One thing I often do along these lines is to acknowledge the value in the PR suggestion, but if it's not required try to get agreement on opening another improvement task in the backlog. This way you continue to make progress and have a nice set of improvements to implement if you ever have time to. Mar 15, 2017 at 0:27
  • @SandyChapman - this assumes that they are in fact objectively improvements though. It doesn't sound like the OP believes they are. Mar 16, 2017 at 8:33

I had the opportunity to work under a project manager who had an interesting approach to project ownership disputes: "When it's time to call the shots, it's better to have one average captain than two excellent ones."

It seems like project ownership is really important to your co-worker. Why not treat it as an asset instead of a liability?

Have your co-worker acknowledged as the project owner, with all the responsibilities that come with it. Have a meeting with both your manager and your co-worker. Go with something along the lines of "seems co-worker X here really likes to take ownership. So to simplify things, and give them proper ownership experience [if necessary], let them take this one - I'll be helping them along and defer to their decisions on platform, libraries, approaches and such. Next project is mine, though. Deal?"

Positive aspects of this approach:

  • You'll be considered a team player that accepts other teammate's enthusiasm and give them a chance to prove themselves, while eliminating a stress factor;
  • Being officially in the backseat, you'll be excused of design flaws (you may suggest approaches, but the final decision isn't yours);
  • Having both the manager and the co-worker accept your ownership for the next project gives you a solid footing to use the 'let's roll with my approach this time, Ok?' argument when it's your turn to lay down specs;
  • Implementing a solution under your co-worker's vision will provide you with a different point of view on how to approach project definitions.
  • 6
    Upvoted just for that first quote. :D
    – Wildcard
    Mar 15, 2017 at 2:41
  • 32
    This is correct, but it may backfire. The coworker will be seen by everyone as the leader and the poster as the follower. When promotions come around, the leader will be the new boss. Being submissive may help the project, but it may also harm your career.
    – David
    Mar 15, 2017 at 4:37
  • 35
    @David thus the reason for the 'next project is mine' bit - rather than being submissive, that's team play. Also, the individual project leads may give the manager a more precise view of who's best suited for the lead based on solid results and clear roles.
    – OnoSendai
    Mar 15, 2017 at 4:50
  • 12
    I like this answer, and almost any approach has some points of caution, but OP has to be careful, the next project might not come around for some time, and during that time perceptions of coworker and the OP might be set, and they will be hard to change. Also, the next project might have much smaller scope.
    – Akavall
    Mar 15, 2017 at 5:57
  • 16
    @OnoSendai I worry the 'next one is mine' part will be forgotten or intentionally ignored.
    – David
    Mar 15, 2017 at 14:30

I would pull in a manager and tell him that the constant arguments are impairing efficiency. This is something he has to sort out.

If it were me I would try to split the project. Trying to find a interface and give each one his own part to manage. Maybe you can suggest that.

  • 6
    -1 I don't agree to this suggestion. It's something I've seen a few times in different contexts and is not healthy for the project overall. Your one codebase is now two and each will have their own quirks and learning curves doubling the maintenance effort not just for these two but everyone else who works on this project over the years. Projects with multiple codebases need one overaching design philosophy to unify them, not two or more that will divide them.
    – Segfault
    Mar 15, 2017 at 18:11
  • Totally disagree. I rather to talk to him first and see what would be his response. instead of walking to manger and asking him for help.
    – comxyz
    Mar 16, 2017 at 1:33

Often times, disputing any of his suggestions or proposing a different one is a huge uphill battle.

Sometimes this is normal. It's actually valuable, in some cases. You should have this level of confidence too. If you make a decision, then you should be ready to back it up, all the way.

This seems to be met any time I don't want to do something the exact same way he would do it, and is usually a long and tedious process.

This may be a problem. It may not. Some times developers have a a hard time remembering "there are more than x ways to skin a foo". You may try tackling this issue with your manager.

For example, suppose I choose to use some library to accomplish some task. I will have to justify it to him, which is fine on its own, but there is unusually high resistance even if I can justify its usage.

That is a very good thing. A huge good thing. When I manage a team every single new library requires a HUGE discussion. The person advocating the usage of the library has to justify its usage. There has to be a serious justification. If you're going to force everyone on your team — and everyone that ever joins your team — to use this new dependency, it better be worth it. So maybe that's a bad example. But some level of "fight for what you want" is to be expected during the planning phases. If you're making these levels of calls during the "coding" phase then, bad on you. These should have been made, discussed, decided upon, etc. way before the first line of code (for the new feature) was written. Adding a dependency at coding time, to me, is an automatic reject of a pull request, followed by a meeting. Then an attempt to make sure next time, that we lay out the dependencies before we start writing code.

In general, I don't feel like I have my own autonomy for decision-making, which I feel should be granted;

You don't and that's OK. There is no I in team. Again, if these are implementation level issues they should be explained. If these are planning level issues, time to be ready to defend your way.

instead I feel like I am basically just his assistant.

Now this is a problem. You two may need to define better metrics for a pull request pass/fail. Under what conditions is a pass? Under what conditions is a fail? If it is a fail, are actionable items given?

One rule I always use is that if someone fails a pull request, they have to give actionable items to make the request passable.

Fail: Tests don't pass, fix code so tests pass Fail: Code is too complex, reduce complexity to acceptable levels
Fail: That logic belongs in the model not the controller move it to the model.
Fail: Don't use iterators like x, use real variable names, in this case call it "for entry in entries" not "for e in entries"

Then at least when looking at the failure message you have a place to start a conversation.

My manager has said he is okay with mediating these, but it feels unbelievably petty on my part.

The manager's job is to manage; LET THEM. If your manager gets tired of handling these requests, then he will make them stop. Your manager may very well prefer this level of oversight.

  • +1 mostly for the part about libraries. The OP sounds a little selfish - generally you keep the stack SMALL. As you said, every additional (particularly if redundant) library is a maintenance and standardisation issue. If needed - go for it. If not really needed, why do you even argue. This part and the claim of wanted autonomy (at the cost of standardization) are HUGH red flags.
    – TomTom
    Mar 15, 2017 at 8:23
  • 1
    +1 for "let the managers manage. If they get tired, they will solve it". I mean... worst case scenario, you annoy them so much that they fire you, in which case the problem would still be (arguably) solved.
    – xDaizu
    Mar 15, 2017 at 11:12
  • On the thing about the libraries, it's more that I never hear a reasonable reason not to use it. For example, if I were to copy and paste the code directly and format it a bit, it would be accepted. If I include it from a package, it's considered wrong. Usually the argument is "I have never seen this package before, must not be useful". That's where I consider it to be a problem. Some examples would be like a drag and drop library for more advanced behaviors, or 3d rendering libraries
    – Crow
    Mar 15, 2017 at 13:36
  • For a recent high profile example: qz.com/646467/…
    – coteyr
    Mar 15, 2017 at 13:39
  • 4
    Every Library is one that you have to commit to maintaining (or write new code to replace) if the original maintainers abandon it. It can also be a point of failure beyond your control. Even for something as big as jQuery, you "agree" to keep your app in line with their latest updates, else you induce security issues etc. Big or small there is always a "cost" when using an external library.
    – coteyr
    Mar 15, 2017 at 13:43

For example, suppose I choose to use some library to accomplish some task. I will have to justify it to him, which is fine on its own, but there is unusually high resistance even if I can justify its usage. In general, I don't feel like I have my own autonomy for decision-making, which I feel should be granted; instead I feel like I am basically just his assistant.

In a team/company, you do not have your autonomy for decision making; at least not for high-level decisions such as picking a new technology, a new library, deciding on the architecture, ...

When working on a project in a team, you need to be replaceable. You could get ill/hit by a bus at any time, and another coworker should be able to step up and continue from where you were at.

The more familiarity said coworker has with your work, the better, which is why it matters that:

  • you use the same 3rd party libraries as anyone else in the company,
  • you structure your project the same as any other project in the company,
  • ...

Of course, there is room for exploration. A new 3rd party library, a new structure, etc... can improve the statu quo, but they are disruptive, and therefore their benefits should largely offset their costs. This has to be a conscious decision on the part of the department/division/company. It's not yours to make, though you can champion it.

We have to approve each other's pull requests, therefore, if I do something he doesn't like, he has the option to reject it outright until I change it to meet his suggestions. If I have to get that feature through, I either have to stand my ground and spend a lot of time justifying it, or I have to just change it to what he suggests and move on with my life. kinda a rock and a hard place

If I may, I think that there is a working method issue here.

High-level design should be discussed prior to starting work; it's just a waste of time to work for a week on something, present it for approval, and have it rejected with the reason "Wait, have you considered the interaction with X? It'll never work!".

This means that before starting work, you need to agree as a team on a general direction. And if something comes up midway which requires a drastic change, you need to agree as a team on where to go from here.

Note: I've seen people argue for approving their PR because they had work a lot of it, despite the objections to its quality or design. It hurts to see your efforts rejected... which is why it's best to discuss things beforehand.

So, supposing that:

  • you have management approval for technologies, 3rd-party libraries and project design,
  • you have agreed beforehand on the general direction of the pull request.

Then the discussion on the pull request itself should be centered on:

  • polishing the edge cases,
  • cleaning up the implementation,
  • clarifying the obscure bits.

Once in a blue moon, you may receive a comment like "Oh crap, we forgot to account for case X". It happens. It's a team mistake.

This doesn't, of course, magically resolve your ownership issue. Your coworker may still be intractable during the early discussion about the general direction of the pull request.

In general, whether one has "ownership" or not doesn't matter, you want consensus.

Your first objective should therefore be to understand why your coworker is being difficult:

  • does he have a different vision?
  • is he idealist?
  • is he a control-freak?
  • is he not trusting your skills?
  • ...

and try to address the issue with him.

You need to align on the high-level vision for the project, gain his trust regarding your skills, ...

If all else fail, as a last resort1, you may want to involve your manager and have him divide the responsibilities. You mentioned you and he had different skill sets, so you should be able to split up the responsibilities in 3 areas: his area, your area and a common area. In your area, his opinion would be purely informative (and vice versa).

1 And I mean last, confrontation turn people sour.

  • If all else fail, as a last resort1, you may want to involve your manager and have him divide the responsibilities. I like this idea a lot, but I don't understand why is the last resort and not the first. It can easily be proposed in a not confrontational way [citation needed]
    – xDaizu
    Mar 15, 2017 at 11:08
  • @xDaizu: If you need a referee, it means you couldn't find an agreement. That's pretty bad. Adults should be able to agree, even if all they agree to is to divide the responsibilities by themselves. It's not so much how you ask for it, but the consequences of the failure to reach consensus that you have to live with. There's a high risk of burning bridges when you appeal to higher authority to counter someone. It'll poison your relationship with them. And we're talking teammate here. Mar 15, 2017 at 11:56

Is there a better way to handle this?

I wonder whether he thinks that each decision is binary:

  1. Right/correct (i.e. my way)
  2. Wrong (i.e. your way, not my way, I wouldn't have done it like that)

I think it's important to categorize decisions into at least three buckets rather than two:

  1. Agreeable (we both agree that this is good)
  2. Disagreeable or unacceptable (there's objective, identifiable harm associated with a proposal)
  3. Good enough or acceptable (e.g. I wouldn't have done it the way you're suggesting, but what you're suggesting is good enough, immediately adequate, and better than nothing)

One of my experiences of code reviews is when I was the formal gatekeeper (i.e. team leader or product owner), and I remember that my code review feedback had three categories:

  1. This is good, ready for check-in
  2. This is not quite ready yet, you must change this (I require you to change this) before check-in
  3. I see what you've done, it works; FYI I wouldn't have done it that way, I would have done it this other way; you may change this (before check-in, to do it the way I suggested) if you want to, but you don't have to.

Having that third category is kind of necessary if you want autonomous help.

Note that if there is "objective, identifiable harm associated with a proposal" then you both ought to be able to see and agree that harm exists. If there's still some disagreement, maybe it's about a trade-off, and maybe that is a topic you could bring to the product manager (e.g. "boss, should we use and depend on a 3rd-party component, or adopt more of a Not invented here policy?").

Alternatively is there another software developer nearby? I used to work with a small team of experienced peers. We'd talk with each other one-on-one to discuss and decide our interfaces. In the rare situation where two people couldn't or didn't agree on something, we'd bring another (i.e. a third) developer into the discussion (to find a consensus or a decision-by-a-majority).

You must log in to answer this question.

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