How to deal with a co-worker who assumes "unofficial" ownership of a project?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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 resort¹, 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).

¹ And I mean last, confrontation turn people sour.

Answer 6

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).